Why I don’t do code audits
That doesn’t mean they aren’t useful
I’ve written before about why I think security culture is important. In that article, I mentioned that some of my clients are surprised that I don’t audit their product code. Here are three reasons why:
- Attackers think bigger
Potential flaws in your product software aren’t the only opportunity for threat actors. They’ll attack easier targets such as your developer tools or build servers. These provide incredible levels of access and are less likely to be secured and monitored. Focusing your security program on how your organization operates, instead of just your code, will help you to catch these other risk factors. - The unknown unknowns
Researchers do their best to understand how your product works and look for potential issues in a very short period of time. It doesn’t matter how many issues they do find, there’s still the risk from anything they don’t find. Monitoring for anomalous events can be a better way to detect unexpected behavior, undetected issues, and help you to sleep at night. - Software is never done
Your product is a living thing — constantly evolving to the needs of your customers and your business. As soon as you receive the results of an audit, the next commit can invalidate it. Even if you drop everything else and resolve every reported issue, a new issue or regression can quickly be introduced. Think of your security program as a process that needs to grow and adapt with your product, instead of a checkbox.
I can’t write about them here, but I can share stories with you related to each of these over a beer.
None of the reasons listed above should be misconstrued — auditing your code for potential vulnerabilities is still a worthwhile exercise. These days there are even automated solutions available which might be more cost-effective than hiring researchers. If you‘re in the market, feel free to reach out and I’d be happy to provide some recommendations. The point is, I prefer a more holistic approach that focuses on a broader range of areas that will better protect my clients. Code audits are important, but as a part of a thoughtful security program.
There are often a handful of issues that create the greatest risk to an organization. Conducting a lightweight threat modeling exercise with your teams will help you to discover them faster. It’s a fun thought experiment that teams are eager to participate in. Running exercises like this regularly is one part of building a healthy security culture, spreading awareness, and improving your security.
Eric Higgins started Brindle Consulting to provide organizations with a better approach to building their security programs.
Thanks to my friend Andy Chu for reviewing this post. He’s working on a new Unix shell called Oil.
