How to pick the right SAST tool

Like pretty much any security tool, picking a SAST (static application security testing) tool isn’t a matter of “What’s the best?” but rather “What’s the best for me?” Whether you already have a tool that needs replacing or you’re starting from greenfield, it’s helpful to understand the market so you can narrow down your choices.

Although the process of statically analyzing source code has been around as long as computers have existed, the market for SAST as a security tool didn’t emerge until the 1990s. Today the tools we know as SAST generally fall into two buckets (“generally” because there’s always some nuance), which we’ll call “traditional” and “modern.” Neither approach is superior — it’s about making a choice that aligns best with your business needs. In some cases, that could even mean having one of each.

Traditional SAST

When to choose: You need the best coverage possible, regardless of impact on developer experience.

We call this category “traditional” because it represents the first generation of tools that tried to solve the problem of vulnerabilities in first-party code. It’s also sometimes called “deep SAST” because the defining characteristic is that it performs comprehensive scans and can unearth a wide variety of results. This might be the right approach when you need the best coverage possible, regardless of impact on developer experience, such as in safety-critical and high-value systems that release at infrequent intervals. For example, you probably need better coverage for a missile defense system than for an e-commerce site.

But there is a clear trade-off in getting better coverage. These tools tend to be difficult to run and customize, and separating noise from actionable results requires more effort. Some drawbacks to consider:

The tools usually take a long time to run and can be difficult to run in CI (continuous integration).

Scans are often resource-intensive (compute power) and time-intensive.

They generate a lot of false positives, so you need staff to manually triage results before handing off to developers.

They may require significant tuning and customization to fit into your environment.

For devops teams practicing continuous delivery (CD) and releasing multiple times a day, these drawbacks may be a non-starter. Also, AppSec programs often run very lean, so you might not have the resources to manually triage findings.

Modern SAST

When to choose: You prioritize developer experience and are willing to customize rules to get a good experience.

Like other security testing tools, SAST products have shifted in recent years to prioritize developer-oriented approaches. This second generation of tools, also called “fast SAST,” are highly customizable and provide more focused results (i.e. fewer false positives). They’re easier to introduce in a CI pipeline, which many organizations consider a requirement for developer-friendly security. When integrated into CI, a modern SAST tool can minimize friction with development teams and make it possible to review rule violations inside standard workflows. The last thing any security team wants in a continuous delivery environment is for engineering to turn off SAST scanning because it is too noisy or takes too long. Choose this option if you prioritize developer experience and you are willing to customize rules to get a good experience.

Because modern SAST tools prioritize developer experience, they are built to minimize false positives. This is accomplished through SAST rules, which define how the tool scans for security vulnerabilities. These rules specify what code patterns to look for and what actions to take when a pattern is found.

The tradeoff for modern SAST is subtle, but nonetheless remains: These tools require a deeper technical understanding of your security testing goals. This is because you need to make sure you have the required coverage through rules. No rule? No findings. When selecting a tool in this category, be sure there are rules (proprietary or community) that meet your use cases, including language support, or your staff can write their own rules.

Traditional SASTModern SASTPros– Best coverage possible– Fast, CI/CD compatible– Highly customizable, tailored rules– Fewer false positives, focused results– Developer-oriented, seamless integrationCons– Slow, not ideal for agile workflows– Limited customization options– High rate of false positives– Requires separate tools or processes– Rule-dependent, may require expertise– Requires ensuring rules meet specific use cases (e.g., language support)

Now, it’s time to pick the right kind of scan. Let’s assume for a moment that you’ve decided you want to use a modern SAST because you care about:

Developer adoption and ease of integration with SDLC (software development life cycle)

And fast scans generating high-priority findings.

When implementing SAST in a CD environment, there are two primary approaches: supervisory scanning and CI scanning. Each serves a different purpose in helping organizations secure their code base while keeping development processes smooth. Again, it’s about picking the method that’s right for you.

Supervisory scanning

When to choose: You want comprehensive insight into all potential vulnerabilities or coding errors that might exist.

Supervisory scanning (a term coined by Endor Labs) is scheduled at regular intervals and is designed to identify as many potential security risks as possible across the entire application. Typically, this process runs asynchronously as a batch job, meaning it operates independently of the developer’s day-to-day coding activities. Developers usually don’t interact directly with the results. Instead, the security team reviews and triages the findings.

Key aspects of supervisory scanning:

A focus on breadth: It aims to identify all types of potential vulnerabilities, providing broad coverage.

Triage is performed by security teams: The security team prioritizes and addresses issues.

Holistic risk assessment: It offers a comprehensive view of application risk.

Batch process: This scanning is done asynchronously, without direct developer involvement.

Applicability: Can be used with both first- and second-generation SAST tools.

CI and PR scanning

When to choose: You want to catch vulnerabilities before they enter production.

CI scanning and PR (pull request) scanning, on the other hand, are designed to catch vulnerabilities early, preventing them from being introduced into the code base during the development process. This approach fits seamlessly into the CI/CD pipeline, allowing teams to fix security issues as they arise. While these techniques work the same in practice, there’s a benefit to choosing PR scans: You can use the scan to break or warn the PR, so vulnerable code is never checked in.

A word of caution: Many CI scanning approaches fail because developers think they’re too noisy. SAST tools can become shelfware if this happens. Combining CI scanning with modern, rules-based SAST provides significantly higher probability of success.

Key aspects of CI and PR scanning:

A focus on depth rather than breadth: It uses high-confidence, targeted rules to identify vulnerabilities.

It’s managed by development teams: The development team addresses issues as part of their regular workflow.

Prevents new vulnerabilities: It stops specific classes of vulnerabilities from entering the code base during development.

Requires second-generation SAST tools: To be effective, the tool needs to be fast and targeted so that it can operate on every commit and every pull request quickly and in a way that limits the attention a developer needs to pay to it.

Should you bundle SAST with other security tools?

Regardless of whether you choose a modern or traditional SAST, there’s another consideration… to bundle or not to bundle. SAST vendors commonly bundle other application security testing (AST) tools including software composition analysis (SCA), container scanning, and secret detection. For vendors, this makes sense — why sell you one thing if they can sell two, three, or more. But does it make sense for you?

In most cases, bundling is also good for consumers. But let’s go beyond the obvious (it can be cheaper). Bundling SAST with other ASTs can be hugely beneficial for productivity — assuming you have similar objectives for all your tools (e.g., developer productivity) — because it can create a more integrated and streamlined AppSec program. To figure out if the bundle will save you time, start with your technical requirements for each tool. Once you’ve narrowed down your list, look for tools that provide a united interface for the AppSec team that consolidates or de-duplicates findings. Not only will that make your team more efficient, it can also help you avoid investing in tools like application security posture management (ASPM) that are designed to consolidate alerts when your tools don’t play well together. Finally, find out how much effort it takes to add each AST. AppSec teams often lack robust access to CI, so most organizations will want an easy installation experience where they don’t have to install each tool separately. Ideally, this should be as non-disruptive as possible to both the AppSec and development teams.

Bundling might not be for you if your technical requirements can’t be adequately met by a single vendor. For example, you might need a traditional SAST tool but can’t handle a noisy SCA. It’s tempting to go with a cheaper bundle but that can lead to shelfware, so beware.

Three conversations to have with your team

Picking the right SAST tool really is about what’s right for your organization. You can get started by posing three questions to your team, and think through your answers both in terms of security and business KPIs:

Traditional vs. modern: What matters more, the best coverage possible or a killer developer experience?

Supervisory vs. CI or PR scans: Do we care more about finding all potential issues, or preventing issues from entering production?

Bundling vs. standalone: Must all our application security testing tools be best-of-breed or are some more important than others?

Start there, and you’ll be on your way to better protecting your applications from security incidents.

Jenn Gile is director of product marketing at Endor Labs. She writes on topics including open source, zero trust, Layer 7 traffic management, compliance, and WebAssembly. She is the author of NGINX’s ebook Taking Kubernetes from Test to Production and Endor Labs’ Implementing Software Supply Chain Security. With a background in learning and development, Jenn prioritizes education-based marketing programs that provide intrinsic value to the community.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.