rootninja

“Life is too short to defend broken code”, cool quote by Dan Kaminsky in the article, Kaminsky Issues Developer Tool to Kill Injection Bugs.

It’s about meeting the developers half-way.

And that’s mentioned, but it can’t be stressed enough. I just worry this might be used as an excuse for not writing secure code.

Offloading the “burden” from developers isn’t a replacement for testing, code review, and education.

Vulnerabilities continue to plague new software development even with today’s heavy focus on writing secure code. Telling developers to stop worrying about security isn’t a step in the right direction.

Perhaps the best solution is a multifaceted approach.

Developers should continue to attempt to write clean, secure, and bug free code from the inside-out while project managers, security experts, and collaborators involved in development continue efforts to protect the project from the outside-in.

“Security is a process, not a product.”

-Bruce Schneier

The magic button.

Surprise! There isn’t one.

Standing rules for avoiding bad code such as always using snprintf( ) in place of sprintf( ) is a piece of cake, no lie! Unless you’re encouraging buffer overflows from user input, why not enforce it?

Managers should plan the development cycle, create rules for writing code, enforce peer code reviews, incremental builds, unit testing, testing, testing, and more testing.

If you tell developers they don’t have to worry about insecure code because a framework will save them you may as well tell them they can avoid exercise and eat all the twinkies they like because there’s a magic pill for that too.