"... give us something constructive. Tell us some things organizations should know above the level of specific bugs. What should developers know? Where do I start learning?"
Where do I start...
1) You work in a busines where the man that cuts your cheque at the end of the month does not speak technical :- learn to speak his "business speak" and put your technical issues in that language then he will listen and not go off to sleep when you walk through his door.
Also it will stand you in good stead when you get promoted or go out on your own so it's a good investment of your time.
2) I disagree with the point where he says bugs : design 50:50, He has left out use of poor tools used badly (GIGO) and a few others.
However sticking to his two I would say that 90% are due to poor design in several areas. Primarily "input" "exceptions" "APIs" "documentation".
Most programers by habit push all input validation as far to the "left" as they can primarily because the do not know how to deal with exceptions properly or at all...
And most code cutters realy don't know how to break their code up and design clean well structured interfaces.
I should not need to see any of your source code to write other parts of the program, either as part of the "initial code cut", or for "bug maintanence" or "upgrading".
If your APIs are designed properly and documented properly and your code handles exceptions properly then,
I should be able to write my code and test it to the API and drop it in and have it work.
3) Testing :- Most code shops do not test properly or at a level where they have an real degree of certainty on "functionality" let alone "security". This is due in part to my above two points...
4) Metrics :- here I very much agree with the article writer if your only metric is number of bugs squashed then you realy are in trouble.
The problem is that most metrics you see are for audit and are about as usefull as a choclate teapot to architects analysts and programers.
This is a real problem as the industry as a whole does not have consensis on what should be measured or how and most support tools metrics are for accounting and audit (at best).
5) Tools :- get them, learn how to use them properly, use them, and pester the company that supplied them to get features you need (unless you tell them then their marketing dept are just going to guess).
You would not belive the number of times I have seen very expensive tools become "shelfware" simply because nobody has the time...
6) Programing Languages :- the author is correct they suck, but not just from the security aspect (though the ANSI C spec has a lot to be blaimed for on that score).
Most studies show that the strongest indicator of bugs in a program are related to the number of lines of code written by a programer irespective of the language used... So pick a language that is appropriately high level to the job you are doing that way you will have less lines of code written by programers, and they will get more done in the same period of time with less bugs.
Also being able to work in more than one programing language will help turn you from being a code cutter into a programer.
C++ et al suck because they try to be all things to all men and like the jack of all trades they fail to be a master of any. Worse they all have C in their past either directly or by methodology so have inherited some real bad traits.
7) Be an Engineer :- "software engineering" is a term I loath and despise.
Few software analysts, architects, designers, programers or code cutters use anything even remotly close to engineering principles or methodology.
Code Re-use and Patterns have been the mantra for some time which is about the same level as old style artisans making cart wheels and early steam engine builders. They make cart wheels the way they do due to evolution not science, in that they got to the design through things breaking and bolting a bit on untill forced by the laws of nature to come up with a new slightly different design. Those that worked went forward those that dident are lost in the mists of time.
However with software there are no laws of nature to force a new design. So every time something breaks a patch is bolted on and when that breakes that gets a patch and that in turn gets a patch...
Know the difference between a bolt and a bridge. A big problem with code reuse is code cutters design one bridge and cut it down to size for the river they are crossing or make it bigger. The next river the same, the bridge they use only ever gets bigger and the cutting more obvious. They do this Instead of making bolts etc and building the right bridge for the river they are crossing.
8) Learn by others :- this is a real problem. Everybody learns by experiance and knowledge. A clasic example was the Windows MFC, it was overly complex badly designed and documented, using it was a pig of a job until you learnt the "secrets".
However programers treated it as a "rite of passage" in that they figured they had had to do the tasks of Hercules to get where they where and the hard won knowledge gave them a "competative edge" so they where not going to pass it on to others...
"Competative edge" "secret knowledge" call it what you want is self defeating it condems you and everybody else to the same Tasks of Hercules but without his abilities. Think how many times you have felt "If only I knew..." well the chances are somebody else has been in exactly the same position or one very close.
Know the difference between "war stories", "parables" and "history files". War stories have heros and villains but only one purpose to make the person telling them look the hero. Parables make general points and are supposed to make you learn but are generaly so vague to be of little practical use. History files however if written correctly contain the hows the whys and facts both good and bad of the problem and are of very practical use both as an aid to memory but as a body of knowledge for others.
Therefor if you have found a way of doing something don't keep it to yourself document it warts and all and let others learn from your hard won knowledge, and ask them to let you know if they found it usefull or have improved on it etc. Most won't but some will so you and they have benifited.
9) Education is a life long process :- take the time to read books journals and blogs and as I was once told, as a programer "learn a new language every year".
But importantly realy learn the fundementals they are transferable skills knowing the secret tricks of a tool or language is only useful for a short time, and confuses others (think the obsficated C contest ;)
Also there is no "one way" to do a particular job the broader your range of skills the more insight you will have as to how best to do the job.
I was once told,
If all you know is how to blow glass skillfully you are not going to be a lot of use in the carpenters shop. Likewise knowing how to use a hammer and chisel is not going to help you to much in the glass shop. However it will get you started in the masons shop. Knowing how to carve both wood and stone gives you more insight and oportunities.
And if somebody needs a bridge building the knowledge and ability to use both wood and stone will set you well above jobing carpenters and masons and with a little knowledge of engineering fundimentals you can be a bridge architect and designer.
There are a whole load of other points I could make but hopefully the above will help.