July 29, 2008

Coding Books with Secure Programming Flaws

I'm in London for a very short business trip. I'm spending as much time flying to and from this island as on the ground. In the past two weeks I had several meetings with prospects and existing customers. Overall, Application Data Security is on top of the CIO/CSO/CISO to-do list. In one location, the IT and security teams were asking for my assistance educating the CIO which is reluctant to invest in security. "Let the developers code first and deal with security later" he said.

I wish that I could have used the following in this meeting:

The results winners of the 'find the vulnerability in the programming language textbook" contest were announced. The good news is that security researchers and analysts all over the world were able to detect secure coding flaws found in popular books on programming. The bad news is that many secure coding flaws are found in popular books on programming. Those books are used in universities and training courses all over the world.

This experiment, along with SAN's secure coding assessment  tells us that as an industry, we have a long way to go towards completion of the SDLC vision. Organizations should use extra caution and always devote the necessary resources for application security. 
| | Comments (1) | TrackBacks (0)
  • Digg it!
  • Add to Del.Icio.Us
  • Add to Technorati
  • Stumble It!
  • NewsVine
  • Slashdot
  • Google Bookmarks
  • YahooMyWeb
  • Live
  • Add this post to Reddit

0 TrackBacks

Listed below are links to blogs that reference this entry: Coding Books with Secure Programming Flaws.

TrackBack URL for this entry: http://blog.imperva.com/mt/mt-tb.cgi/58

1 Comments

I couldn't agree more.

I think that fundamentally the security industry is barking up the wrong tree by trying to layer more and more security applications 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 become lazier, because they're thinking, 'Oh, the firewall will catch it.'

Just as you cannot build a solid house on poor foundations, you can't make an insecure code base secure by adding more layers.

Ivan Ristic's blog also made a comment recently about 'defect-free code is vulnerability free code'. It's good to see I'm not the only person thinking that way.

Leave a comment