The best open source SCA tools in 2026 are OSV-Scanner for accuracy, Trivy for breadth, and Grype when you already generate Syft SBOMs — while OWASP Dependency-Check has fallen behind everywhere except Java shops with NVD-specific requirements. That is the conclusion; the rest of this post is the evidence, because most of what ranks for this query is an SCA tools list assembled from marketing pages, not something anyone actually ran. If you are evaluating SCA open source options before deciding whether a commercial platform is worth the spend, these five are the realistic 2026 shortlist to bake off first.
The test bed and the method
Everything below was run in April 2026 against the same repository: a production monorepo with 84 pnpm workspaces, 11 Go services, 6 Python services on uv, and two Maven modules we have been meaning to kill since 2023. Total resolved dependencies: 4,312 across all lockfiles.
Ground truth: we manually verified 41 dependencies with genuinely applicable published CVEs (checked against the advisory, the affected version ranges, and our lockfile versions — not just "the scanner said so"). Every tool ran in a clean container on the same 8-core runner, databases freshly updated, and we measured recall against the 41, false positives, and wall-clock time.
One method note: we counted a false positive as a report where either the version range did not apply or the package identification was wrong. Disputed severity did not count against a tool.
The results table
| Tool | Version | Found (of 41) | False positives | Scan time |
|---|---|---|---|---|
| OSV-Scanner | 2.0.1 | 39 | 1 | 48s |
| Trivy | 0.61 | 38 | 3 | 1m 12s |
| Grype (with Syft) | 0.90 | 37 | 6 | 1m 55s |
| dep-scan | 6.0 | 35 | 4 | 3m 05s |
| Dependency-Check | 12.1 | 31 | 22 | 11m 40s |
OSV-Scanner: the accuracy pick
Google's OSV-Scanner won on precision and it is not close. The reason is structural: OSV.dev advisories carry ecosystem-native version ranges (npm semver, PEP 440, Go pseudo-versions), so matching is exact instead of fuzzy. The one false positive was an npm advisory with a bad range upstream, since corrected.
osv-scanner scan source -r --lockfile pnpm-lock.yaml .
Version 2 brought the guided remediation subcommand (osv-scanner fix), which computed a working non-breaking upgrade set for 24 of our 31 npm findings. The gaps: container image scanning is still thinner than Trivy's, and it will not scan an already-built artifact as thoroughly as it scans lockfiles. The two misses in our set were both bundled dependencies invisible to lockfile analysis — a limitation shared by every lockfile-based tool, to be fair, and the reason we covered vendored code separately in our cargo audit vs cargo deny comparison.
Trivy: the breadth pick
Trivy found one fewer of our seeded CVEs but does dramatically more jobs: filesystem scanning, container images, IaC misconfiguration, secrets, licenses, and SBOM generation, in one static binary. If your CI budget allows exactly one open source tool, this is the defensible default.
trivy fs --scanners vuln,secret --format sarif -o trivy.sarif .
The three false positives were all in Python — Trivy matched advisories against packages installed in a test fixture virtualenv we should have excluded. Operationally, .trivyignore files with expiry dates (exp:2026-09-01) are the feature that keeps suppression lists from rotting, and more teams should use them.
Grype and Syft: the SBOM-native pick
Anchore's pair splits the problem correctly: Syft produces the SBOM, Grype matches it. If you already archive per-release SBOMs — which you should for attestation reasons alone — Grype scans the artifact you already have instead of re-resolving the world:
syft . -o cyclonedx-json > sbom.cdx.json
grype sbom:sbom.cdx.json --fail-on high
The cost is precision. Six false positives, mostly from CPE-based fallback matching on Java artifacts where Grype guessed the wrong product. Setting GRYPE_MATCH_JAVA_USE_CPES=false removed four of them at the risk of missing advisories that only exist in NVD. The architecture is the right one; the matching still needs babysitting in JVM ecosystems.
dep-scan and Dependency-Check: the long tail
OWASP dep-scan (now under the CycloneDX umbrella) is quietly good — reachability hints, VDR output, decent accuracy — but the documentation assumes you already know why you want it, and it found four fewer than OSV-Scanner while taking three times as long.
OWASP Dependency-Check remains the tool auditors have heard of, and the numbers explain why engineers wince: 22 false positives, nearly all from CPE fuzzy matching (commons-text matched against the wrong Apache product, twice), and an 11-minute scan dominated by NVD data sync even with an API key. It still earns a place in Java-only estates with a hard NVD requirement. Everywhere else, retire it.
Where a commercial platform actually differs
Honest version: for detection on lockfiles, the open source tools above are now within a few percentage points of any commercial scanner, ours included. What you buy from a platform like Safeguard's SCA is everything around detection — reachability analysis to cut the 80 percent of findings your code never calls, cross-repo policy, ownership routing, fix PRs, and audit-ready reporting. If those words do not describe a pain you have this quarter, run OSV-Scanner and Trivy and keep your money; our comparison with Snyk applies the same framing to the commercial field.
What we actually run now
Final setup after the bake-off: OSV-Scanner on every PR (fast, precise, low-noise gate), Trivy nightly across filesystem, containers, and IaC (breadth), and Syft SBOMs archived per release with Grype rescanning released artifacts weekly so new CVEs surface against what is actually deployed, not what is on main. Three tools, all free, roughly 25 minutes of total daily compute — a working setup earned from a bake-off, not just picked off an SCA tools list.
Frequently asked questions
Is one open source SCA tool enough?
For PR gating, yes — pick OSV-Scanner or Trivy and keep the gate fast. The pairing matters for the second job: rescanning released artifacts when new advisories publish, which requires archived SBOMs and a scheduled scan rather than a PR trigger. Most breaches trace to the known-vulnerable-but-already-shipped window, not the PR that introduced the package.
How did you count false positives fairly?
A finding counted as false only when the affected version range did not include our pinned version or the package was misidentified, verified by hand against the advisory. Severity disagreements and unreachable-but-real vulnerabilities counted as true positives, since plain SCA tools do not claim reachability.
Why is OWASP Dependency-Check so much noisier?
It matches primarily through CPE identifiers against NVD, and CPEs are a naming scheme with no reliable link to package ecosystems, so fuzzy matching guesses wrong regularly. Tools built on OSV.dev or ecosystem advisories match on package coordinates and exact version ranges, which removes most of the guessing.
Do these tools handle monorepos with multiple ecosystems?
All five scan multiple lockfile types in one invocation; the differences are in attribution and speed. OSV-Scanner and Trivy walked all 103 manifests in our repo without configuration, while Dependency-Check needed per-module exclusions to finish in reasonable time.