Let’s state the obvious: application security is evolving quickly. What used to be essentially a ‘solved problem,’ or at least a manageable one, has been heavily disrupted by the revolution of DevOps. This includes accelerated deployment frequency, the rise of continuous integration pipelines and the increased use of open-source components (on which you have little to no control at all). All these elements have been weighting for the rethinking of the AppSec model. This is becoming even more evident as DevSecOps is bringing AppSec into DevOps.
At the heart of this transformation are the tools that people, developers and security engineers alike are meant to use daily. Therefore, the following question is more relevant than ever: what are the key factors to look at when considering one of the many offerings out there?
To get started, why not look at a definition of SAST? By looking more closely at the definition of static application security, we should be able to derive the criteria from judging if a given tool will live up to our expectations:
“SAST is an automated review of source code, with the goal of identifying missing or incorrectly implemented security controls and providing timely feedback on remediation to developers.”
Let’s focus on the three key points in this definition:
Automation
The most significant advantage of static analysis is that it can be automated and thus placed almost everywhere. Source code can be reviewed early and often. You can use SAST in your IDE, in your CI pipeline and asynchronously on your repositories to understand the security posture of your application. This gives you flexibility regarding how you want to run your SAST tool.
Still, no matter your strategy or what kind of tool you are going to elect, SAST has to be automated. Sure, manual code reviews can find security defects and serve a whole class of functions on their own, but they aren’t able to scale. A key feature of SAST is that it can review vast amounts of code and get excellent coverage, which is tough to replicate in other forms of security assessments.
Security vendors never run out of arguments when they are pitching their SAST solution: the tools are always more powerful and cover a wider range of vulnerabilities, from application logic (classes, routines, functions), settings (config files) and dependencies (libraries, binaries).
But there is a catch: while automation is critical, it is hardly the only principle to consider. Without actionable feedback, scanning reports will be useless. So there comes our second ‘A.’
Actionable Feedback
If we want developers to adopt a SAST tool, we must keep an eye on the signal-to-noise ratio: we want alerts to be raised (with blocking) only when a “true” incident is detected. Otherwise, you risk making your teams fall into the trap of alert fatigue. According to a 2020 report from the Neustar International Security Council (NISC), over one-quarter of security alerts fielded within organizations are false positives. Because this phenomenon is so widespread, it is fair to say that selecting a solution with a low rate of false positives will make or break the success of a SAST tool adoption.
However, don’t be lured into the false promise of achieving zero false positives! If a secret detection tool does not report any false positives, the chances are high that it is silently skipping real vulnerabilities (read more).
Once you are confident with the quality of the signal, you still need to understand what the expected outcomes are. Don’t overestimate technical specifications, and try to assess how a specific tool will improve/complexify your existing processes. Tools are meant to empower people, not the contrary. SAST offerings come with a wide range of functionalities that help with incident remediation and provide an excellent way to educate developers without changing their toolset (IDEs, CI pipelines, etc.) to teach them about security. In addition, SAST also does an excellent job at providing timely feedback, which helps retention.
Never forget the golden rule: your security posture does not improve when you find a defect. It improves when you fix it.
Adaptability
You probably know that your developers haven’t written 70% to 80% of the code you are running in production. That’s not even considering the various APIs we’re relying on to build our digital services. Therefore, a single SAST tool’s perimeter is never enough to cover the whole attack surface, given that the developers don’t control most of the (direct or transitive) dependencies their code runs on.
So what’s the point? Well, precisely, a SAST tool is only as useful as long as you can use it in conjunction with other tools and at different levels. Given the increasing complexity of software building pipelines, you should be able to place your own guardrails at multiple places to cover the largest attack surface possible.
Take the case of secrets detection: a reasonable strategy to implement a “zero secrets-in-code” policy would be to build a layered defense all across the development cycle, including:
- Monitoring all the repositories in realtime with native VCS integration to “stop the bleeding.”
- Enabling pre-receive checks to harden central repositories against leaks.
- Shifting left by promoting the habit of pre-commit scanning.
- On the longer-term, remediating historical incidents.
So, to be effective, SAST must cooperate closely with the security tools used to validate and police these other parts of the application. Those other tools include software composition analysis (SCA), DAST (dynamic application security testing) and much more. The adaptability factor is key to creating a custom, genuine representation of a single application security profile.
Conclusion
Unlike other security processes, static application security testing is a very good candidate for scaling in a cloud environment. We would be foolish not to leverage the knowledge of how our applications work to find security defects. Source code tells you more about a system than any single piece of artifact. Analyzing this artifact will also tell you more about the system’s security posture. When considering a SAST tool that is able to fit in a DevSecOps context, you should be especially careful of three aspects: automation, actionable feedback and adaptability.
We believe this is a good rule of thumb to lay a solid foundation to support an effective, accurate and holistic security program.
