Software security myth #5: It’s all about finding bugs in your code
Q: Can I secure my apps by finding bugs in my code? A: Finding bugs in code is great, but unless you fix what you find, application security won’t improve.
Are bugs a big deal in the software security conversation? Absolutely. Implementation bugs in code account for at least half of the overall software security problem. Finding bugs in code and fixing them is an essential software security initiative (SSI) practice.
This brings us to the fifth myth of software security best practices.
The 50/50 divide
If bugs are only half the problem, what’s the other half entail? The other half involves a different kind of software defect that occurs at the design level: flaws.
For a great set of flaws and how to avoid them, see the work of the IEEE Center for Secure Design.
The division of design flaws and bugs is about 50/50. Both need to be secured to ensure your software’s well-being. You can institute the best code review program on the planet, with the strongest tools known to humanity, but it’s unlikely that you will be able to find and fix flaws this way.
As the domain of threat modeling and architecture analysis, flaws must be found and resolved by experienced people. These activities have resisted practical automation so far in the software security evolution. As a new and continuously evolving field, software security measures have historically been identified as security needs and trends arose.
Finding a problem is different than fixing a problem
While finding bugs in code is great, and there are variety of methods for finding bugs (including penetration testing and the use of software security tools), unless you fix what you find, security doesn’t improve. Finding issues is only the beginning. Sadly, it’s incredibly common for firms to find issues without taking any measures to fix those issues. Part of the problem is that technology developed to find bugs often lacks helpful remediation recommendations for fixing the issues. For example, static analysis tools find thousands of different bugs, but in no way fix them.
So, once bugs are found, how should they be prioritized? Which should be fixed first? Focusing on only 10 bugs—as in the OWASP Top 10—is a blind approach. If a bridge were in great disrepair, would you only fix the most common types of repairs seen in old bridges? Hope not! Similarly, overfocusing on 10 bugs is setting your firm up for trouble.
Broaden your horizons. Focus on finding bugs in code—not limiting your search to only 10—and, most importantly, fixing them! It’s also important to make sure you train your developers not to make new bugs every day; otherwise, you’re setting up a hamster wheel of pain. And remember, bugs are only half of the equation. Make sure to also focus attention on flaws occurring at the design level.
Where do I start?
Want to know what other organizations are up to with regard to security? The BSIMM was designed to measure and understand real world software security initiatives. Quantifying the practices of organizations throughout a variety of industries, we can describe the common ground shared by many as well as the variations that make each unique. Learn how to get involved in the BSIMM study.
