Software Integrity


Software security myth #5: It’s all about finding bugs in your code

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 and fixing those bugs is an essential software security initiative (SSI) practice.

This brings us to the 5th myth of software security. Want to catch up on the previous myths? Start from the beginning by exploring the first myth.

The seven software security myths are common misconceptions about software security best practices. These myths explore how software security initiatives should work, and aren’t simply about how to secure a particular application. So, let’s examine why bugs are only part of the security problem.

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.

The Building Security In Maturity Model (BSIMM) is working to change the reactive approach to software security to a proactive one.

Finding a problem is different than fixing a problem

While finding bugs in your code is great, and there are variety of methods for finding bugs (including penetration testing and the use of 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 dis-repair, would you only fix the most common types of repairs seen in old bridges? Hope not! Similarly, over-focusing on 10 bugs is setting your firm up for trouble.

Broaden your horizons. Find the bugs—not limiting your search to only 10—and most importantly fix the bugs! 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 regards 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.

See Myth #6


Myth #5: It's All About Finding Bugs In Your Code
Myth #5: It’s All About Finding Bugs In Your Code