Why do we need a new approach to SAST?
Many companies provide legacy static application security testing (SAST) tools or engines, but their usefulness has not kept pace with the needs of an application-driven world. In order to succeed, businesses need a modern approach to SAST that will greatly improve it’s value in the software development lifecycle. In this blog, I look at the problems with traditional SAST tools, why there needs to be a change of approach in the SAST market, and what the future holds for SAST.
The problem with traditional SAST tools
Most organizations use traditional SAST tools for compliance purposes, which means that most are configured to cast a wide net in when scanning for issues. As a result, the competition has typically revolved around which product generates the most findings and produces the longest lists of them.
The problem with this is that, SAST tools report a large number of security findings that may not be relevant or are false positives — and they don’t prioritize them. As a result, developers and DevOps teams waste considerable time and resources fixing vulnerabilities that don’t need to be fixed. Worse, the glut of false positives may cause your teams to miss or neglect something that poses a genuine threat. Therefore, prospective users may consider SAST too blunt an instrument to be sufficiently effective.
What do modern SAST tools do better?
In contrast, next-gen SAST tools focus on prioritization and precision. They aim to identify far higher percentages of true positives, so users can be more confident that what their tools show them are real threats worth mitigating.
These modern SAST tools do two things better than their traditional counterparts. Firstly, they don’t need complex configuration, which helps security managers manage security workflows more flexibly. Even more important, they are more precise. While the number of findings that they identify are lower, they are more likely to be genuine issues. While more traditional tools identify more vulnerabilities, many of these results are inaccurate or irrelevant. They simply don’t provide the precision of a modern SAST engine.
The second benefit is speed. Modern tools can reduce the scan speed dramatically (x3 x4 x5) but the most important thing here is they can provide near real-time (in 10 min – 15min) feedback to developers committing their code, which lets them quickly review, analyze, and fix security findings. When you’re trying to fight the infiltration of malicious code, this speed could be crucial.
A current compromise: coverage vs value
Traditional SAST tools have been in the market longer and have developed more comprehensive support for a wider variety of coding languages and Common Weakness Enumerations (CWEs). The more modern tools are catching up, but it may take some time, so while this situation persists, coverage may be more limited in newer SAST solutions. However, if the primary considerations when choosing a tool are speed and precision, then modern SAST tools will provide higher value and a better ROI. I believe that the modern SAST engines will win out against traditional tools because while these tools have generated many findings, few people are acting on them. For SAST to be really effective and genuinely add value, this situation can’t continue.
The importance of security policies
Establishing and defining flexible security rules and policies is key to maximizing the effectiveness of a modern SAST tool. With a multiplicity of languages, processes, components, and dependencies, there are many things to look out for.
First, establish what you’re looking for. Are you looking for specific CWEs, or certain sources and patterns? They will all dictate what your rules and policies should be. While modern SAST tools provide a predefined configuration with relevant rules that support specific languages, the capability to customize your policies and tools is also important, even at the user interface level of your applications. Then you can define or uncheck which CWEs and other items you wish to track.
This capability is particularly important for compliance with security standards, where several considerations apply:
- Control. Security managers need the control to manage these rules and new and additional rules to be enforced on the relevant applications within the organization. This translates to a need for flexibility in defining security workflows.
- Definition. They need to define their policy or rules and alerts, and when to trigger or report alerts.
- Actionability. Reports and insights to be actionable so that when an alert is triggered, actions immediately follow, such as sending notifications and generating reports.
The solution is to choose and use a SAST engine that can balance precision and recall or accuracy and coverage, configured out-of-the-box for high precision. Only engines such as these can be used in an effective way as part of engineering processes and immediately report findings to developers so that they can fix security issues. Furthermore, a SAST engine should be easily integrated into engineering processes. A good way to do so is through your code repository in a way that every code commit or product release by a developer immediately triggers a SAST scan that enables him/her to review and fix security findings within their code.
The future of SAST
I anticipate that, in the near future, the use and adoption of SAST tools will increase by both AppSec managers (who generate reports today) and engineering. Within engineering, they will be used by managers, security champions, and most importantly, developers, for fixing security issues in their code. AppSec managers will need more flexibility with security rules, defining policies for applications or organizations, and later monitoring alerts.
Engineering will need better visibility to their organization so that they will be able to monitor volumes of new findings, the organization backlog, and volumes of code fixes, which is the real ROI. Developers need to get accurate and prioritized lists of security findings in their preferred development environment, with suggestions for code fixes that enable them to analyze code quickly, fix the code, commit and re-scan, with accurate feedback to reassure them that they fixed problems and reduced the security risk.
With these needs in mind, I think that ideally, there will be an application or a user interface especially for security managers, to make these processes simpler and more self-service. The interface would have different KPIs from those for engineering managers. They would be focused on defining security policies. It will help give them the flexibility to assign security policies to specific applications, thereby enabling them to enforce what SAST scans they perform for different applications. Then they’ll want to see some kind of dashboard or KPIs that don’t count the number of vulnerabilities or code fixes but instead show the number of times their policies do not meet their requirements. After that, they can drill down to see exactly where the breaches are, and what they can do to remediate them.
I imagine security managers to be individuals who want to see a large screen that shows a map of all the applications in their organization and get alerts about those applications that don’t meet their security policies so that they can home in on only addressing the issues with those applications. This benefits from a good user interface. Currently, most of the tools in the SAST market just present these managers with thick reports containing thousands of findings, undifferentiated for severity based on their organizations’ context. This is no longer good enough because done well, SAST can achieve much more than just complete a compliance exercise like this. However, what’s needed for it to do more is for there to be a change in approach, technology, and usage. It needs SAST to be a modern, flexible, customizable tool with a user-friendly interface and actionable insights. We are on the way to achieving this, and making the security of our code, our software, and our applications more responsive and robust with a new generation of SAST.