Andrew Briney's Secure coding? Bah! article struck a chord, as it should have been titled "Secure coding? Absolutely!" Given that the software industry as a whole has never made a concerted effort to write better code, it's far too early to throw in the towel.
Many are convinced that because we can't have perfect code, we shouldn't even try for good code. It's nonsense to give up on writing better code, especially when we appear to have plenty of time to invent new technologies that don't solve our problems.
Briney said, "Risk reduction is all about reducing vulnerabilities, mitigating threats and lowering event costs." However, most customers have almost no information on the security-worthiness of the products they buy, and some risks can't be mitigated. The single best thing the industry can do to mitigate users' risk is to write better software.
Software development must improve because software has become part of our critical infrastructure. As such, software development should be held to the same standards as other facets of critical infrastructure. Imagine if civil engineers built bridges with the same inattention to fundamental engineering practices as many software developers. Would it be acceptable to hear:
- "I can't be bothered to figure out how to make the bridge secure. I'm only interested in using the latest cool building materials and having a sexy facade."
- "Time to market is crucial. If I can't get my bridge up this month, my competitor will."
- "It's not my fault if the bridge fails. I didn't expect so many heavy trucks on it."
There are no perfect bridges, but engineers are keenly aware of the ramifications of poor engineering practice. If they were as unschooled in secure design practice as the average software developer, we would have collapsing bridges and severe loss of life.
Briney said, "But it's even faster and cheaper to build crappy software to get the project rolled out immediately, please your boss and help the company make its quarterly number." Actually, it isn't. Much of secure coding practice is just good coding practice. Observing a good development process actually gets better quality products out the door faster.
"Secure programming is an oxymoron because none of the parties who could make it happen on a broad scale are properly 'incentivized,'" Briney said. There are many things that can and have happened to refute this. For one, customers can demand more secure software. The Department of Defense has made a good start by requiring formal, third-party security evaluations for products used in national security systems. This requirement may be extended to other agencies.
Security evaluations don't result in perfect software, but they do force vendors to follow a secure development process. Oracle has invested more than $17 million in security evaluations throughout the last 12 years, and I can categorically state that it has resulted in better products and more "security awareness" among our developers. Avoidance of even one significant security fault would more than pay for the cost of an evaluation.
More than 50% of security faults are a result of buffer overflows. If we, as an industry, merely stamped out buffer overflows in the next two years, we would reduce security faults by half and would significantly decrease our customers' risk exposure. Checking boundary conditions is measurable, achievable and something that every developer should have learned in their first programming class. If they didn't, they shouldn't be working in the industry.
In summary, my response to Briney's editorial is "Secure coding? Yes, absolutely."
About the author
Mary Ann Davidson is CSO at Oracle.
FOR MORE INFORMATION ON THIS TOPIC…
- Read Andy Briney's column, Secure coding? Bah!.
- Read Chris Wysopal's response, Secure software: The source of the problem is the solution, to Andy Briney's column.
- Read this Q&A with Microsoft's Steve Ballmer for an update on the company's Secure Computing Initiative.