Have you ever gotten a "critical vulnerability in dependency" alert and when you look at it, it's something like “XML parser vulnerability in some buried transitive library that you actually use for parsing JSON and therefore aren’t affected by at all?”
We’re excited to launch Semgrep Supply Chain, a high-signal dependency scanner that cuts through the noise of false positives. Let’s be honest: those of us that use a Software Composition Analysis (SCA) tool are already ignoring > 90% of its alerts. By combining Semgrep’s first party code analysis with dependency analysis, Semgrep Supply Chain prioritizes the 2% of vulnerabilities that are reachable from your code.
Application security teams are in a tough spot: staffing is short, tools are noisy, and political capital is scarce. Organizations need security improvements, but that work cannot reduce velocity. When AppSec engineers and developers work together to fix a vulnerability, it must be a real issue with real consequences if left unattended. Cry wolf too many times, and people stop listening. So vulnerabilities must be triaged to filter out false positives before making their way to the engineering backlog.
Our research[1] shows that >98% of vulnerabilities are unreachable and the vulnerable dependencies are being used safely. Existing SCA tools don’t filter out that noise; in fact, they run up the score, alerting users of every package with a vulnerability as though it were a massive security event. It’s an open secret that these false positives make existing tools practically unusable.
A 98% false positive rate is a pretty large haystack in which to find the needle. As a result, we’ve found that many security teams fall into one of two camps:
Some teams decide that running a real SCA program isn’t high enough value. But since it’s a compliance requirement, someone turns on a tool to show the auditor and check the compliance box.
Other teams, often at companies with sensitive or valuable data, decide that the risk is unacceptable, that the needle is too dangerous. The security support rotation becomes a slog of never ending toil, manually triaging the infinite pile of vulnerabilities in order to find the rare impactful issue.
This is a terrible choice, one that we think security teams should not have to make.
Ask a security team if they’re in favor of vulnerability scanning tools and they will agree. Ask them if those tools meaningfully and practically improve security, and you will get a few laughs.
To combat this problem, we are introducing Semgrep Supply Chain, a high signal vulnerability scanner that leverages the Semgrep engine’s first party code analysis to identify dangerous usage of vulnerable packages - we call this reachability analysis.
How it works
Semgrep Supply Chain scans lockfiles in order to answer the question “are you using a package at a version known to be vulnerable?” It then uses the Semgrep engine’s first party code analysis capabilities to search for code that reaches the vulnerability in the package.
This analysis is powered by rules produced by our security research team. When new vulnerabilities are disclosed, they investigate and produce rules that find dangerous uses of the vulnerable package. Our team curates these rules so that they are run with the next scan for all Semgrep Supply Chain customers.
Semgrep Supply Chain still shows you unreachable vulnerabilities. We want you to have full visibility into the state of your supply chain. And in a perfect world, you might even get around to fixing them. But if you’re like most security teams, trying to get out from under the deluge of vulnerabilities, you should prioritize the reachable vulnerabilities and ignore the rest.
An example: Lodash
Lodash is a great example of why first party code analysis is crucial for a vulnerability management tool. It’s a hugely popular library of JavaScript utility functions.
Lodash has a known vulnerability below version 14.17.21 that makes prototype pollution possible if untrusted data is passed into merge, mergeDeep, or a few other functions. However, lodash also has over 200 other functions that are totally safe to use with untrusted input, even at the vulnerable version.
That means that engineers can use a “vulnerable” version of lodash completely safely, since the vulnerability is benign unless some code calls the vulnerable function. Sure, in a perfect world, it’s good to upgrade to a version past the vulnerability. But we live in a messy world, where upgrades often come with breaking changes, and security teams must prioritize vulnerabilities that are a real danger to the organization today. In this world, pragmatic security teams use reachable analysis to focus on real issues and prioritize critical fixes.
Supported languages
At launch, Semgrep Supply Chain has general availability (GA) support for Go, JavaScript/TypeScript, Python, and Ruby, with beta support for Java, and more on the way!
Wrapping up
Through reachability analysis, Semgrep Supply Chain can take you from hundreds or thousands of alerts, to tens of high quality findings. It cuts through the noise, reduces the toil of manual triage, and helps you stay focused on high impact work.
Want to scan your dependencies with Semgrep Supply Chain? Contact us to get started.
[1] We’ll be sharing more details about this work later in October. Stay tuned!
