One of the important things in a Security Development Lifecycle (SDL) is to feed back information about vulnerabilities to developers.
This post relates that practice to the Agile practice of No Bugs.
The Security Incident Response
Even though we work hard to ship our software without security vulnerabilities, we never succeed 100%.
When an incident is reported (hopefully responsibly), we execute our security response plan. We must be careful to fix the issue without introducing new problems.
Next, we should also look for similar issues to the one reported. It’s not unlikely that there are issues in other parts of the application that are similar to the reported one. We should find and fix those as part of the same security update.
Finally, we should do a root cause analysis to determine why this weakness slipped through the cracks in the first place. Armed with that knowledge, we can adapt our process to make sure that similar issues will not occur in the future.
From Security To Quality
The process outlined above works well for making our software ever more secure.
But security weaknesses are essentially just bugs. Security issues may have more severe consequences than regular bugs, but most regular bugs are expensive to fix once the software is deployed as well.
So it actually makes sense to treat all bugs, security or otherwise, the same way.
As the saying goes, an ounce of prevention is worth a pound of cure. Just as we need to build security in, we also need to build quality in general in.
Building Quality In Using Agile Methods
This has been known in the Agile and Lean communities for a long time. For instance, James Shore wrote about it in his excellent book The Art Of Agile Development and Elisabeth Hendrickson thinks that there should be so little bugs that they don’t need triaging.
Some people object to the Zero Defects mentality, claiming that it’s unrealistic.
There is, however, clear evidence of much lower defect rates for Agile development teams. Many Lean implementations also report successes in their quest for Zero Defects.
So there is at least anecdotal evidence that a very significant reduction of defects is possible.
This will require change, of course. Testers need to change and so do developers. And then everybody on the team needs to speak the same language and work together as a single team instead of in silos.
If we do this well, we’ll become bug exterminators that delight our customers with software that actually works.
Reference: Building Both Security and Quality In from our JCG partner Remon Sinnema at the Secure Software Development blog.
