How to boost SAST performance?

When creating an AppSec program, static application security testing (SAST) is the one that first comes to mind and is relatively easier to implement.

Easy integration with the pipelines and a wide variety of open-source alternatives make SAST tools a go-to solution for jumpstarting DevSecOps practices.

SAST is an established technology that has been around for over 20 years and is a proven method to discover security vulnerabilities in the development stage.

However, downplaying its efficiency has also been a common trend due to the high number of false positives it generates.

In this blog post, we will be sharing five tips that can help you boost the performance of your SAST tools and achieve healthier DevSecOps processes.

1. Fine-tune the rules

The most common mistake with SAST tools is running scans using the default rule sets of the vendor without proper configuration.

AppSec vendors design default rule sets to catch as many fish in the pond as possible.

This approach often leads to lengthy scans and a high rate of false positives, which is not in line with the speed expectations of DevOps.

The right approach is to narrow down the scope and configure rule sets to search for vulnerabilities that could only be relevant to the scanned application.

Deciding on the specific vulnerabilities to search for obviously requires some threat modeling practice to know the nature of the application.

It is a good idea to create security policies that automatically break the builds if any of these vulnerabilities are discovered on the pipeline side.

Some of the most tech-savvy organizations use incredibly targeted rule sets. This approach allows them to maintain a high true positive rate and run automated workflows on the discovered vulnerabilities without worrying about the friction that the false positives can create.

At the end of the day, DevSecOps is not only about kicking off SAST scans in an automated fashion in the pipelines. The preferable way of running SAST should be, running laser-focused scans with narrower rule sets within the pipelines and using broader rule sets for scheduled scans where time pressure is lower.

2. Automation and Positioning

Automation is an indispensable part of modern AppSec programs. However, positioning automation at the right stage with the right tools and rule sets is an artwork.

Even though running SAST scans in each code commit sounds like a good idea, it is a long shot in practice. Developers start complaining, and the scanners get overloaded before AppSec teams realize that it is not a sustainable approach.

The branch structure used in the organization can be a good starting point for deciding on the timing of automated SAST scans. The code review stage in each pull or merge request is ideal for running SAST scans along with other quality tests.

Making SAST scans an integral part of the code review process helps test the code in the earlier stages of the SDLC and increases the security awareness of the development teams.

Picking a tool that offers PR/MR decoration capabilities, running SAST scans in each PR with a limited ruleset, and evaluating vulnerabilities in each PR review are practical tips for creating and scaling an AppSec program.

3. Developer feedback

Developers are key figures for a sustainable AppSec program as they are responsible for fixing the vulnerabilities. To have them work in harmony with the security teams is one of the biggest challenges involved in AppSec as security is often seen as a blocker for development operations.

SAST tool findings are suitable for working closely with development teams as they directly point to the code itself.

However, attention is required not to turn developers off by forcing them to work in a way they are not used to.

The more developer-friendly our output is, the less friction between AppSec and development teams will likely occur.

In fact, security vulnerabilities are no different than other bugs in software. Therefore it makes sense to assign security vulnerabilities to developers on the issue trackers they use daily for quality bugs.

Automating the issue assignment process is tricky as it might lead to an intense backlash from developers if vulnerabilities are not properly filtered out before assignment, and they need to deal with lots of false positives.

That is why we recommend starting the automation for a limited set of vulnerabilities in the beginning and expanding the scope over time.

4. Adaptability

It might not be reasonable to apply the same pipeline or DevSecOps process for each application in the organization.

Depending on the requirements of each application, SAST tests need to be configured accordingly.

The tech stack used in applications, the capabilities of the SAST tool or even the size of the development team are all factors that might lead to changes in how the SAST tools are positioned within the AppSec program.

It is always a good idea to be active in AppSec communities to discuss your use cases or to liaise with the support teams of commercial tools. In AppSec there is rarely a one-size-fits-all solution and exchanging ideas can go a long way in deciding on the optimal structure.

5. Setting the expectations

SAST is a robust, established technology, but it is certainly not a silver bullet that can prevent all AppSec-related issues.

Therefore we need to set the right expectations before investing in a SAST solution. SAST tools are mainly used for scanning the applications frequently to catch low-hanging fruit types of vulnerabilities before they hit the production stage.

For complex or multi-stage vulnerabilities or business logic flaws, SAST tools will probably be a disappointment as discovering these vulnerabilities require a different approach and methodology.

Since SAST tools aim to discover patterns or anti-patterns created by developers, and these anti-patterns can vary between programming languages and frameworks, tools that allow the creation of custom rules are preferable.

Last but not least, the severities of vulnerabilities discovered by SAST tools are mostly categorized based on the ease of exploitability rather than their potential impact.

It would be a mistake to simply focus on high or critical severity vulnerabilities without assessing the characteristics of each vulnerability.

Setting the right expectations will prevent future disappointments and also help to get the most out of the selected tools.