How to Maximize the Value from Your SAST Tool

It stands to reason that if you’ve implemented a Static Application Security Testing (SAST) tool, you’ll want to reap the full value of the investment. But to accurately assess ROI, you need metrics that can evaluate factors such as overall results, KPI compliance, and timeframe. Only then can you estimate whether you’re making a real improvement to the security of your code base, and from that, assess the monetary value of these results. Let’s take a look at some tactics to optimize the value you get from SAST tools.

Know what to measure

There are two main factors to consider to achieve effective measurement: what new security findings you encounter, and how you handle the backlog of legacy security issues.

New findings

The increasing speed, frequency, and volume of software and application development inevitably creates more code. With new code comes new issues. Ideally, you want to avoid any new vulnerabilities, or at least minimize them. It’s what some people call “stop the bleeding.”

Realistically, you can’t stop vulnerabilities completely, but you can set a KPI based on the number of new findings, and measure your performance against this metric. Achieving this goal starts with knowing which of your development teams introduces more vulnerabilities. From there, you can implement security training with them, to improve awareness of potential vulnerabilities and better prepare the team to address them before flaws are introduced into your code.

It’s important to monitor the KPI to assess value and see what you get out of your SAST tool and enable you to make the right decisions about the way teams are working. Preferably, developers should be part of this process to make the screening and fixing of code as seamless as possible within the development life cycle. 

In order to manage this process and enable developers to easily review security issues and fix them, it’s preferable to run the scans integrated with your repo to get immediate feedback with every commit and rescan to ensure that fixes really reduce the risk. Then, developers will be able to see issues immediately, as they do code commits. They’ll be able to incrementally see when they have introduced new security vulnerabilities, understand them, and fix them quickly. Get the right tools for your developers and they can code with confidence, knowing their code is secure. Unfortunately, many traditional SAST tools don’t enable you to do this easily, so finding the right tool is a key consideration.

Addressing the backlog

What about vulnerabilities that may already lie in your code base? Addressing this backlog requires a different process, since it involves code that was written some time ago. That means your current developers are probably not familiar with this code, or they do not feel responsible for it. So, your tool should have the means to fully review the code to see all of its data flows, and ideally, provide your developers with the necessary means to fix it. Then you can set goals for them, such as a reduction of vulnerabilities in the backlog of X percent over a certain time.

A good recommendation is to appoint a security champion to lead the process, because it might be that your legacy code was developed by someone that is no longer at the organization. So, you want to have experts within your organization that know a big part of your legacy code and can fix it. We know that not all organizations have security champions within the engineering team. Some use team leaders or other experienced developers in this role, but it’s best when your security champion is from engineering, because in that case the champion has the necessary knowledge to do an efficient triage process.

The ideal type of tool

Whether you’re dealing with new code or a backlog, you can use the same tool because in both cases you need to perform triage. However, the way you use the tool will vary. 

On the backlog side, champions need to see the vulnerabilities and the entire code, including all the data flows and how they work, so that it’s easy to understand exactly where the issues are. Ideally, the tool should also give these champions the capability to see the code fixes or recommendations for code fixes and see everything within the code. Automatic remediation accelerates this, and when it’s working and trusted, it improves SAST capabilities and enables these champions to detect, identify, and fix their code seamlessly and quickly. This is a measurable response, too, because it’s all about the code fixes that you can generate out of the tool that you use. You can count the number of code fixes that you are doing over time and you can measure the time it takes to remediate a vulnerability.

When it comes to new findings, the issues are often in your code repository and are connected to specific developers or teams. In this scenario, the tool does an incremental scan to find and identify only new and never-before-seen vulnerabilities. Preferably, you want to identify very clearly just a small number of genuine (true positive) vulnerabilities to show to developers and ask them to fix, because if you show them a large number of false positives, they will not have time to handle it, they may neglect to do so, and your security will deteriorate.

Importantly here, the process is handled by the developers that know the code. They want to see only the new vulnerabilities, and they want to fix them immediately before everything is integrated later on, as part of the pipeline, to the code of other developers. This is making a shift left, by fixing vulnerabilities as early as possible in the software development lifecycle (SDLC).

Customization and other considerations

To make your SAST tool more effective, it should be customizable so that you can define KPIs that are specific to your organization’s needs. For example, you might want to define an acceptable reduction of the backlog by a certain percentage. Every organization has different goals in this respect. So, adding customizable KPIs to your tool’s UI is certainly something to look out for and consider.

Ideally, you would also seek to include risk scoring and focus on the important priorities that arise from it. In principle, the risk score is another good KPI to monitor. You might find vulnerabilities that really don’t expose you to more risk, because nobody uses that particular code in your organization. So devoting time and talent to remediating it could be a waste of valuable resources. However, a note of caution here. Risk score remains a challenge in the market, because there’s no commonly agreed way to calculate it.

Meeting the value challenge

The key to success is to not only implement comprehensive monitoring, but also link it to integrated processes designed to maximize the ROI from your SAST tool. 

However, many organizations struggle to make this shift. Until now, security solutions were just something that the security manager bought to check the compliance box. Security ran the scans and tried to engage with developers to fix some of the problems, but in most cases the developers or engineers wanted the security team to handle that. Moreover, traditional SAST tools offered limited functionality and focused on quantity rather than quality. Many did not prioritize the findings except by severity, which isn’t always sufficiently accurate as a prioritization criterion. The result: many false positives, which developers are often reluctant to address. 

What this means is that getting full value from SAST tools requires not only a shift away from earlier, limited SAST products themselves, but also a mindset shift away from the old-school, siloed security processes.

Fortunately, we are seeing the slow movement of SAST and security tools from the security teams to the engineering and development teams. If used in the right way and with the right processes, SAST can ultimately help your engineers and developers improve processes and improve their code. With that in mind, there’s an imperative for security tools like SAST scanners to become more developer-friendly, more responsive, and more agile. We are seeing the need for better UIs that are not just for experts, and that give more value to organizations. I think that’s what is happening right now. It’s a new beginning for security, SAST, and the benefits that it offers to organizations and users alike.

Secure proprietary code 10x faster

See Mend SAST