Quality > Quantity: How to Get the Most Out of SAST
Static Application Security Testing (SAST) has a bit of a bad reputation. SAST tools can produce an overwhelming number of alerts and security teams, having often come from networking backgrounds, don’t always fully understand the alerts that they are passing on to developers for fixes. This can cause the relationships between the teams to sour, as developers often perceive this work as pointless and holding them back from working on their primary responsibilities like new features.
It doesn’t have to be that way. In this blog, I want to pass on some simple advice that I’ve seen work well for improving security posture while maintaining warm relations between security and developers.
How does SAST work?
SAST works based on coding rules to find common flaws and weaknesses that may lead to vulnerabilities. These flaws are typically defined by the Common Weakness Enumeration (CWE) framework. The flaws themselves are not vulnerabilities, but they are evidence of poor code quality. Think of SAST like a spelling or grammar check that detects where code is believed to be written poorly. The key word there is “believed”; the flaw may or may not be something that will ever be a problem, and the only way to know is to look into it. Although SAST tools are built for the purpose of detecting weaknesses that lead to security issues, they can usually also address code quality beyond security concerns to some degree.
Solid strategies for addressing SAST alerts without overwhelming developers
There’s no way around it, even the best SAST tools in existence create a lot of alerts. Maybe more than with any other kind of tool, how you address SAST alerts must include a consideration of how you will do so with diplomacy. I’ve written about this before, and I cannot stress enough how quickly you will lose developers’ trust and cooperation by haphazardly issuing tickets based on alerts from security tools. If you want to scan wide, go ahead. Just leave your developers out of it. Remember, not all alerts are created equal, and not all alerts are vulnerabilities.
Here are two great strategies for addressing SAST alerts that I’ve seen used in the field with success:
Stop the bleeding
With this approach, you get a baseline of SAST alerts at the start — but you do not address them. Instead, your goal is to not add any new weaknesses or code quality issues. You will only have developers address new alerts as they come in. Then, over time, you work down your backlog, perhaps using the second strategy.
The trickle
With this approach, you take one kind of CWE (SQL injection, cross-site scripting, and deserialization of untrusted data are common first picks) and address only those alerts. When those are done, you address the next CWE, working through the most critical kinds of CWEs first.
A word of warning from someone who has been there: make sure your developers know the plan ahead of time. If you don’t let them know that next month they’ll be getting a whole new set of alerts to address, you may inadvertently hurt morale.
Picking a good SAST tool
Finding a tool that decreases the number of alerts while increasing the quality of those alerts will help you immensely.
Look for a tool that does the following:
Can be customized to your needs
Like spell and grammar check can be set to recognize, say, “Quakenbush”, as a legitimate proper noun, a good SAST tool can be customized to your projects so you end up with higher quality alerts.
Has data flow consolidation
Many SAST tools will make an alert for every data flow, even when that means hundreds of alerts generated for just a few pieces of code that need addressing. Having an impressively large number of alerts can be good when you’re making the case for more resources for your security team, but that benefit is quickly diminished when developers are tasked with actually addressing them.
Encourages developer training
Some SAST tools are integrated with education programs like Secure Code Warrior or other just-in-time training for your developers. No tool or configuration will reduce alerts like your devs writing secure, high quality code in the first place.
High-quality alerts in disguise
One last piece of advice: pay attention to context, especially application context. SAST has no knowledge of runtime or deployment environments, so it’s up to you to decide if an alert is an actual vulnerability. Sometimes, what you might think of as a low-quality alert that doesn’t matter can have huge implications down the line. For instance, a path traversal CWE in a command line tool may not be a real security vulnerability, but it is still a code quality issue. And if that command line is ever deployed as a part of a cloud application, now it is a real potential security vulnerability.
In parting
The purpose of any application security tool should be to actually improve your application security. Make sure you wield them wisely. Asking developers to fix things that aren’t important has no positive impact on your security posture, and will likely have a negative impact in the long run, as developers begin ignoring the security team and their own duty to code securely.
