Wednesday, February 28, 2007
Why Secure Coding Practices will never happen...
I am a big fan of Secure Coding Practices and believe that all enterprise architects should take the time to familiarize themselves with their goals as it can provide immense benefits to the enterprise, yet I also believe that its potential success is constrained...
Generally speaking, many enterprises are buying more software than they are building themselves which tends to result in an imbalance of power. Doc Searls in his blog talks about Vendor Relationship Management as a method to bring back balance but in terms of secure coding practices it may not be economically viable to do the job right.
Us IT types are great at using analogies with a frequent term being the notion of a warranty period. In all reality, this is more about generous after-sales support and not really about avoiding defects in products at development time. If one ever studied the economics of the auto industry, you would notice that car dealers make more money on after purchase services than they do in selling vehicles. I believe the same thing occurs in software.
I previously blogged about the cost of sales in terms of a closed source model where in all reality enterprise architects complain about the cost of software at procurement time without understanding the total costs over the long haul. If a vendor makes money by forced upgrades and in telling enterprises that they must upgrade by a certain date or lose support, then why would they write software correct in the first place? When it comes to software, more bugs means more support and an opportunity for sales folks to sell upgrades.
Maybe the problem is that enterprises keep getting it twisted when it comes to having incompatible goals where out of three choices of cheap, time to market and high quality, and they only get the choice of two, the last one always suffers. I am of the belief that in order for secure coding practices to stick, enterprise architects need to educate the business community on how to create requirements around security. I suspect that within most enterprises, other than receiving a statement such as I want my software to be secure and we should use existing products, that no more thought has went into this important topic.
Likewise, enterprise architects would be well-served by engaging the process weenies who are in love with metrics and getting them to figure out a way to quantify that the real issue is not that we are not spending enough money on software, but that we are not developing software in an appropriate manner.
| | View blog reactionsGenerally speaking, many enterprises are buying more software than they are building themselves which tends to result in an imbalance of power. Doc Searls in his blog talks about Vendor Relationship Management as a method to bring back balance but in terms of secure coding practices it may not be economically viable to do the job right.
Us IT types are great at using analogies with a frequent term being the notion of a warranty period. In all reality, this is more about generous after-sales support and not really about avoiding defects in products at development time. If one ever studied the economics of the auto industry, you would notice that car dealers make more money on after purchase services than they do in selling vehicles. I believe the same thing occurs in software.
I previously blogged about the cost of sales in terms of a closed source model where in all reality enterprise architects complain about the cost of software at procurement time without understanding the total costs over the long haul. If a vendor makes money by forced upgrades and in telling enterprises that they must upgrade by a certain date or lose support, then why would they write software correct in the first place? When it comes to software, more bugs means more support and an opportunity for sales folks to sell upgrades.
Maybe the problem is that enterprises keep getting it twisted when it comes to having incompatible goals where out of three choices of cheap, time to market and high quality, and they only get the choice of two, the last one always suffers. I am of the belief that in order for secure coding practices to stick, enterprise architects need to educate the business community on how to create requirements around security. I suspect that within most enterprises, other than receiving a statement such as I want my software to be secure and we should use existing products, that no more thought has went into this important topic.
Likewise, enterprise architects would be well-served by engaging the process weenies who are in love with metrics and getting them to figure out a way to quantify that the real issue is not that we are not spending enough money on software, but that we are not developing software in an appropriate manner.
