I have finished reading a nice article from Dark Reading about secure development or, said otherwise, taking security into account when developing software.
Two major problems are brought forward:
your average developer doesn’t have the right mindset for understanding security which doesn’t play well with his artistic skills.
security awareness and training programs are a failure. Besides the budget constraints, developers would never chose security over meeting their deadlines.
I can see the logic behind the (partial?) failure of security awareness and training programs. Think about Time to Market, competitiveness, frequent evolution of technologies and needs and you’ll get the idea. In this context, adding a security brick to an already unsteady building which is way behind the defined deadlines is unrealistic. According to Caleb Sima, CEO of Armorize, a secure development software vendor:
“If I’m a developer, as soon as I’ve been assigned a project, I’m already behind. If there’s a faster way to do something, they’re going to take it, because for them speed is more important than security.”
So what options do we have?
According to Fortify, another secure development software vendor, many development companies add a security specialist to their development team. This person is in charge of bridging the gaps between the security and development teams but also helps identifying and correcting the vulnerabilities.
This approach has however some serious limitations as the security specialist might not identify all vulnerabilities given the diversity of projects and programming languages. But more importantly, she might become a bottleneck in the team as everyone is waiting for her feedback before moving forward and/or rushing to her with urgent requests given the deadlines.
To solve this problem, some organizations opt for secure development frameworks such as BSIMM but these are pretty heavy to implement and they require a formalized development process.
According to many of the interviewed experts, one solution consists of using vulnerability identification tools that nicely integrate with the IDEs and automatically identify vulnerabilities as code is written. While the experts here are heavily biased given that they work for companies that provide such tools, I think the point is valid nonetheless.
Given the time and budget constraints that most (if not all) software development projects have to take into account, such tools might really help a lot as they act as your off-the-shelf debugger or code quality checker and integrate nicely into the existing toolchain, specially if their output is not some security mumbo jumbo.
This approach is indeed limited to code validation/checking. Some important phases of the development process such as use cases or design are not covered but if you think that you can easily take security into account during those stages, be my guest.
This is a step in the right direction and a pragmatic one that take into account developer needs and constraints instead of the other way around.
