Defect-free code is vulnerability-free code
I've come to realise that our efforts to improve the state of security through focus on the software development life cycle (SDLC) are flawed. Although we may see some improvement in the short term (a span of a few years), such an effort is a waste of time as it cannot solve the problem. If you think it can then you are looking at the wrong problem. (Borrowing Mark Curphey's favourite line.) Underneath all our security issues lies our inability to write defect-free code. Solve that and we've solved the security issues. Focus on the security alone and we won't solve anything.


I couldn't agree more.
Many companies are now installing stateful packet inspecting firewalls in an attempt to make their applications secure. I really think that the security industry is going the wrong way by trying to layer security devices on top of poor code, simply because we have the immediate problem of insecure code and an excess of CPU cycles to dedicate to catching attacks. Underneath it all, coders are becoming lazier, thinking, 'Oh, the firewall will catch it.'
ImperViews, another blog from people making application-layer security devices, made a comment recently about coding books used to instruct in universities themselves having secure programming flaws. How are we ever supposed to address the flaws in production code when it's being taught to programmers from the beginning?
Posted by: Craig Rickel | July 31, 2008 at 11:41 PM
After reading and reviewing technical books for years, I can tell you that most programming books, and even many security ones, have insecure code in them. I have long ago given up on trying to report such issues (except in the cases where I was acting as a formal reviewer, of course). But fixing the books is not going to solve anything either. The bottom line is that programming is too complex for our small brains. We should remove ourselves from the process. The problem, of course, is that no one knows how to do that.
Speaking of web application firewalls: they are operational tools, a technology people needs to gain visibility into what is happening, and react to the realities of today. Programmers are not to blame, by the way. We (the collective user base of all software) have created the problem for ourselves by accepting applications that are full of security issues, defects and are, on top of that, difficult to use. There is very little reason for any software vendor to think of security much in the current business climate because security has little impact on the success of their business.
Posted by: Ivan Ristić | August 01, 2008 at 11:41 AM