Open-Source SCA Tools in 2026: Trivy, Grype and OSV-Scanner Tested, Plus OpenCVE to Watch New CVEs

What does an SCA tool check?

An SCA tool, for software composition analysis, lists the open-source packages your project uses, including the ones your dependencies pull in, and matches each exact version against advisory databases such as GitHub's and OSV. It reports known vulnerabilities, the fixed version when one exists, and with some tools the licence of each package.

The list is longer than the manifest suggests. On 5 November 2026 our own website repository declared 39 packages in its package.json, 17 dependencies and 22 dev dependencies, and its pnpm-lock.yaml listed 965. The lockfile is what gets installed, so a scanner that reads only the manifest misses the other 926.

SCA does not read the code your team writes. That is the job of SAST, and the two answer different questions: SAST asks whether your code has a flaw, SCA asks whether a package you ship has a published one. Neither sees a malicious package that has no advisory yet, which is how slopsquatting, the attack on package names an AI model invents, gets through.

Which open-source SCA tools are maintained in 2026?

Trivy, Grype, OSV-Scanner, Dependency-Check, Dependency-Track and pip-audit all shipped a release in 2026 and none is archived, according to GitHub on 5 November 2026. All six are Apache-2.0. They differ in what they read and where their data comes from, and Dependency-Track is a platform that stores results, not a scanner you run in CI.

OSV-Scanner is Google's front end to OSV.dev, a database in one open format that gathers the GitHub Advisory Database, the PyPI and Go vulnerability databases, RustSec and others. Trivy scans repositories, container images and infrastructure code with one binary. Grype scans container images, filesystems and SBOMs, and reads the package lists that Anchore's other tool, Syft, builds. Dependency-Check and Dependency-Track are OWASP Flagship projects. pip-audit is maintained under the Python Packaging Authority.

Two tools often filed under SCA update dependencies without scanning them in the same sense. Dependabot, whose core library is MIT-licensed, opens pull requests that update dependencies, and Renovate, licensed AGPL-3.0, does the same across a wide range of languages and platforms. They keep versions current, and neither keeps a record of what you shipped.

What did each tool find in one repository?

In a test CybeDefend ran on 5 November 2026, five SCA tools scanned one repository with outdated dependencies in four ecosystems, and together reported 109 distinct vulnerabilities in 21 packages. OSV-Scanner found 109, Trivy 105, Grype 104. npm audit found the same 43 npm vulnerabilities as the others, and pip-audit the same 21 in the four pinned Python packages.

We built a small repository that looks like a shop's backend, with one service per ecosystem and versions pinned in 2020 and 2021 on purpose:

• a Node.js API with express 4.17.1, lodash 4.17.20 and axios 0.21.1, and a lockfile of 53 packages resolved on the day;
• a Python worker whose requirements.txt pins requests 2.25.0, urllib3 1.26.4, PyYAML 5.3.1 and Jinja2 2.11.2;
• a Java billing service whose pom.xml declares log4j-core 2.14.1 and commons-text 1.9;
• a Go gateway on a November 2021 version of golang.org/x/net and on golang.org/x/text 0.3.7, whose code calls the HTML parser of the first and one width function of the second.

Each tool ran with its defaults. We merged the findings across CVE, GHSA, Go and PyPA identifiers, using each tool's aliases and OSV's, so that one vulnerability reported under two names counts once.

Times for Trivy and Grype are second runs; the first run of each spent most of its time downloading a vulnerability database, 132 MiB for Trivy, and took 19.2 s and 101.7 s. OSV-Scanner queries osv.dev online by default.

Three differences explain the gaps:

• A requirements.txt without a lockfile lists four packages, and nothing below them. OSV-Scanner resolved what requests itself depends on and found three more advisories in idna and certifi. Trivy, Grype and pip-audit read the four pinned lines and stopped there.
• On the Java side, log4j-core needs log4j-api, and commons-text needs commons-lang3. Trivy and OSV-Scanner resolved both and found one advisory in each; Grype read the two declared packages only.
• In Go, Trivy did not list CVE-2023-44487, the HTTP/2 Rapid Reset flaw, against golang.org/x/net, where Grype and OSV-Scanner did.

On npm the four tools agreed on all 43, and 13 of those sit in six undeclared packages that express pulls in: qs, body-parser, path-to-regexp, cookie, send and serve-static. Log4Shell, CVE-2021-44228, was found by Trivy, Grype and OSV-Scanner, and Grype's JSON also carried its EPSS score of 0.99999 and its CISA Known Exploited Vulnerabilities entry. Severity labels did not always agree: for the same findings Trivy marked four critical and Grype five.

Trivy vs Grype vs OSV-Scanner: which should you run?

Pick OSV-Scanner for Go services and for Maven or Python projects without lockfiles, where it resolved what the others missed. Pick Trivy if you want one binary for dependencies, container images, IaC and licences. Pick Grype if you already produce SBOMs with Syft or want EPSS and KEV data next to each finding.

The three agree when the input is a lockfile, as our npm results show, so the choice depends on what else you scan and what you do with the output:

• Trivy fits a team that wants one scanner in CI for several layers. The same command scans a repository, an image or a Terraform folder, and --scanners license adds licences. Its database downloads once and is cached, which is why our second run took one second.
• Grype fits a team that already builds SBOMs. Scan the SBOM once at build time and again later without rebuilding, and sort by the EPSS and KEV data its JSON carries.
• OSV-Scanner fits a team that cares about precision. It resolved transitive dependencies for Maven, and in our run for Python, its Go call analysis is on by default, and its fix command suggests upgrades for npm and Maven projects.

npm audit and pip-audit stay useful as a developer's first check before a commit, since they need nothing installed, but each covers one ecosystem.

Does an SCA tool tell you whether a vulnerability is reachable?

Only OSV-Scanner did in our test, and only for Go. Its call analysis, on by default, marked 12 of the 31 Go vulnerabilities as called by our code and 18 as not called; one could not be analysed. Its default table listed 13 vulnerabilities for the Go gateway out of 31, and nothing at all for golang.org/x/text.

The calls matched what our code does. The gateway uses the HTML parser of x/net, so advisories in the parser and renderer showed as called, while the HTTP/2 advisories of the same module, a code path the gateway never touches, did not. The three x/text advisories sit in functions the gateway does not call. OSV-Scanner uses Go's own govulncheck library for this, and --all-vulns brings the hidden findings back. Its Rust call analysis is marked experimental and runs your dependencies' build scripts.

For npm, Python and Java no open-source tool in our test went that far, and every finding counts the same whether your code calls the vulnerable function or not. That is the gap reachability fills, and it is the same sorting problem we describe in why a scanner reports 1,200 vulnerabilities when only 12 are real. CybeDefend's SCA works at that level: it marks each package used, potentially used or unused, so the ones your code really calls come first. How CybeDefend handles SCA shows the sorting.

Is OWASP Dependency-Check still worth running?

Dependency-Check 13.0.0 is maintained and an OWASP Flagship project, but in our run it stopped at its first database update with "Invalid API Key" and produced no result. Its README says users are "highly" encouraged to get an NVD API key, and without one updates are "extremely slow". Plan for a key and a cached database before you adopt it.

It remains a sound choice for Java and .NET builds, where it reads the compiled JARs and assemblies, and its Maven and Gradle plugins run inside the build. Two things weigh on it in 2026. It matches packages through CPE identifiers from the NVD, which is why the key matters so much, and Sonatype's OSS Index, another of its data sources, has required credentials since September 2025. Without them, the README says, Dependency-Check "will automatically disable the OSS Index analyzer".

What do SCA tools miss?

SCA tools miss three things: malicious packages with no advisory yet, vulnerabilities in code you copied without a package manager, and anything in a dependency that no lockfile or manifest describes. They also report known issues only, so a package published yesterday with a backdoor scores clean until someone files an advisory.

Coding agents add a fourth gap, which is timing. Claude Code, Cursor or Codex can add a dependency in the middle of a task, and the scan in CI runs after the agent has moved on, sometimes after the pull request is open. An agent that can read the project's findings while it works can pick the fixed version from the start, which is what we describe in giving coding agents live access to every finding. VibeDefend hands the project's dependency findings to the agent through MCP while it writes, whether that is Claude Code, Cursor, Codex, Devin Desktop or GitHub Copilot, so the agent can move to the fixed version in the same session. How VibeDefend works shows the loop.

Between two scans: watching new CVEs with OpenCVE

An SCA scan is a snapshot. It lists the known vulnerabilities in your dependencies on the day it runs, and a CVE published the next morning on a package you ship stays out of sight until the next scan, unless a platform such as Dependency-Track keeps checking the SBOMs you stored there. SCA also sees only what you build: no lockfile lists the VPN appliance or the database server your team runs next to your code.

That watch is the job of OpenCVE. You subscribe to the vendors and products you care about, such as Fortinet or WordPress, and OpenCVE alerts you by email, Slack or webhook as soon as a CVE touching them is published or updated. There is no agent to deploy and nothing to scan. It pulls from MITRE, NVD, CISA KEV, Red Hat and Vulnrichment, among others, and puts CVSS, EPSS and KEV side by side for each CVE, so you can tell a flaw attackers already exploit from one that only scores high. It runs as a cloud service with a free plan, or self-hosted with its Community edition, whose code is on GitHub under the Business Source License.

OpenCVE is not an SCA scanner, since it reads no lockfile and scans no repository, and that is why the two work together: your SCA tool tells you which packages you use, and OpenCVE tells you the day a new CVE lands on one of the products you follow.

How do you run SCA in CI and keep one list?

Run the scanner on every pull request against the lockfiles, write SARIF for the code host and an SBOM for the record, and fail the build only on findings that are critical or high and have a fix. Store the SBOM of each release, because a new advisory often concerns a version you shipped months ago.

A minimal setup with the tools from our test:

# On every pull request: lockfiles, SARIF for code scanning
osv-scanner scan source -r --format sarif --output-file osv.sarif .
trivy fs --scanners vuln --severity CRITICAL,HIGH --ignore-unfixed --exit-code 1 .

# On every release: keep the SBOM, scan it again later
trivy fs --format cyclonedx --output sbom.cdx.json .
grype sbom:sbom.cdx.json

Dependency-Track takes the CycloneDX file and keeps watching the components of every version of every application it holds, which answers the question an auditor asks: which release contained the vulnerable version, and when was it fixed. For teams preparing SOC 2 or ISO 27001, that history matters more than the scan itself.

A second scanner adds findings and duplicates at once. Our run produced 451 entries in five JSON files with five schemas for 109 distinct vulnerabilities, the same merging problem we hit with six open-source secret scanners on one seeded repository. CybeDefend Open Source is built for that step. It runs the scanners you choose, any tool that writes SARIF, and puts what they find in one deduplicated queue, free and on your servers. It is launching soon, and the waitlist is open.

Frequently asked questions

What is the best open-source SCA tool in 2026?

In our test of 5 November 2026, OSV-Scanner 2.7.0 found all 109 distinct vulnerabilities in a repository with outdated npm, Python, Maven and Go dependencies, Trivy 0.76.1 found 105 and Grype 0.121.0 found 104. OSV-Scanner resolved more transitive dependencies; Trivy covers more layers in one binary.

Is Trivy an SCA tool?

Yes. Trivy scans lockfiles and manifests for known vulnerabilities in open-source packages, which is software composition analysis, and it also scans container images, infrastructure code, secrets and licences. It is Apache-2.0 and maintained by Aqua Security. In our test it found 105 of 109 vulnerabilities and resolved Maven transitive dependencies.

What is the difference between Trivy and Grype?

Both are Apache-2.0 scanners that read repositories, SBOMs and container images. Trivy also scans IaC, secrets and licences and resolved Maven transitive dependencies in our test, finding 105 vulnerabilities. Grype, built on Syft's package lists, found 104, missed the Maven transitive packages, and adds EPSS scores and CISA KEV entries to its JSON.

Does OWASP Dependency-Check need an NVD API key?

Its README calls a key highly recommended and says updates without one are extremely slow. In our run of version 13.0.0 on 5 November 2026, the first NVD update stopped with "Invalid API Key" and no scan could run. Request a key from the NVD and cache the database between CI runs.

What is the difference between SCA and SAST?

SAST reads the code your team writes and looks for vulnerable patterns, such as an injection. SCA reads your manifests and lockfiles and reports the published vulnerabilities in the open-source packages you use, including the ones your dependencies pull in. A project needs both: our own website's lockfile lists 965 packages for 39 declared ones.

Are npm audit and pip-audit enough?

They are a good first check, since they need nothing installed and found the same npm and Python vulnerabilities as the larger tools on the packages they read. Each covers one ecosystem, neither writes SARIF, and pip-audit run on a requirements file without a lockfile audits only the lines it lists.

What is reachability in SCA?

Reachability tells you whether your code calls the vulnerable function of a dependency or only imports the package. In our test OSV-Scanner's Go call analysis marked 18 of 31 Go vulnerabilities as not called and hid them from its default table. For npm, Python and Java, none of the open-source tools we ran made that distinction.

Does an SCA tool alert me when a new CVE is published?

Not between two scans. A scanner reports what is known on the day it runs, so run it in CI on every change and on a schedule, daily for instance, to catch the advisories published since. To be told the day a CVE lands on a product you use, add a CVE monitoring service such as OpenCVE, which alerts you by email, Slack or webhook when a CVE touching a vendor or product you follow is published or updated.