Choosing an SCA tool without being fooled
You now know how an SCA tool rebuilds the dependency tree and sorts alerts. What remains is choosing one. A demo can stop at a tidy project, four red alerts and a nice falling curve.
Here is how to see what is behind them.
This article builds on SCA: from inventory to priority, but stands on its own.
SCA tools, one minute each
These tools do not all play the same role. Three roles complement each other: find (scanning), track (SBOM management), propose a fix (updates). One tool can fill several roles. A non-exhaustive selection, without a ranking. Profiles checked on 8 October 2026; each name links to its official source. Capabilities depend on version, plan and supported ecosystems.
| Tool | Role | Relies on, or looks for | Good to know |
|---|---|---|---|
| OWASP Dependency-Check | OWASP dependency scanner. | NVD data feeds, with CPE identification. Also uses third-party services for some ecosystems. | Integrates with Maven, Gradle, Ant, Jenkins, GitHub Actions and Azure DevOps. |
| OWASP Dependency-Track | Component analysis platform built on the bill of materials, to follow supply-chain risk. | Bills of materials in CycloneDX format, compared with public advisory databases. | Offers deployment with Docker containers. |
| Trivy | Versatile scanner for container images, file systems, Git repositories, virtual machines and Kubernetes. | Vulnerabilities, misconfigurations, secrets, licenses, and generates bills of materials. | Available checks depend on the scan target. |
| OSV-Scanner | Scanner built on the open OSV.dev database. | lockfilelockfile: a file that pins the exact version of every installed block formats and container images, according to ecosystem support. | Call analysis covers only certain languages and analysis modes. |
| Dependabot | Built into GitHub: alerts on vulnerable dependencies, fix proposals, version updates. | The repository's dependency graph and GitHub's advisory database. | Once updates are enabled, opens pull requestspull requests: a proposed code change, reviewed before it is merged automatically. |
| Snyk Open Source | Commercial dependency analysis product, from the editor to the continuous integrationcontinuous integration: checks that run automatically on every code change pipeline. | Its own vulnerability database, fed by its research teams. | Advertises a risk score that combines several factors, and fix proposals by pull request. |
Judging an SCA tool on your project
With comparable coverage, prioritization helps triage; also check for missed flaws. To judge on your project, five questions, the evidence to demand, and the test to run yourself:
Use the same code snapshot, lockfiles and shipped artifact. Record tool versions, configuration, exclusions, advisory database dates and time limits. Separate production, development and tests. Keep raw reports, timings, errors and unanalysed areas: an incomplete scan is not a clean result.
| Question | Evidence to ask for | Test on your repository |
|---|---|---|
| Where do your advisories come from? | The databases used (NVD, OSV, GitHub's database, distribution advisories), how fresh they are, and the source of each alert. | Compare component/version and advisory pairs, resolving CVE and GHSA aliases. Check each difference against the source advisory, including known vulnerable cases both tools miss. |
| How do you find indirect dependencies? | Reading lockfiles, what is shipped, container images and bundled copies. | A test project with a vulnerable version as a direct dependency, an indirect dependency and a bundled copy, then a fixed version. Adapt the cases to your ecosystems. |
| What do you say about reachability? | The languages covered, the call path shown, and what the tool says when it does not know. | Test three cases: a vulnerable function that is called, one that is not, and an analysis that cannot reach a conclusion. Require evidence and scope for each verdict, keeping “unknown” distinct from “unreachable”. |
| How do you prioritize? | Known exploitation (KEV), exploitation probability (EPSS), exposure and business context. VEX documents impact on a product; risk acceptance remains a separate decision. | Change version or configuration and check that the exception and its justification are reassessed without hiding a newly applicable risk. |
| Do you go all the way to the fix? | The proposed update, the check that nothing breaks, tracking until it is in service. | Measure, on a real case, the time from the alert to the version in service. |
A five-day trial that ends with a decision
A useful trial project is neither “hello world” nor your entire estate. Pick a representative service, its shipped image and a small set of cases with known expected results. Adapt this schedule to your team; it is not a guaranteed deadline.
- Day 1, agree on the contract. List essential ecosystems, artifacts to scan, acceptable CI time and data allowed to leave. Decide on disqualifying defects before the trial, such as an incomplete scan presented as clean.
- Day 2, establish the inventory. Compare what each tool actually identified against the expected contents. A dependency missing from the inventory cannot produce a good alert. Record components without reliable versions and unsupported formats too.
- Day 3, explain the differences. Run two candidates on the same scope. For each difference, separate identification, advisory, affected versions, filtering and deduplication. Keep an “unresolved” category: agreement between two scanners is not proof.
- Day 4, ship a real fix. Give an alert to a developer who did not attend the demo. Can they find the parent dependency to update, understand the fix, run tests and get the corrected artifact checked? Time the human work too.
- Day 5, rerun and decide. Rerun after an update and a context change. Export and reimport inventory and decisions. Produce one page: requirements met, blind spots, operating cost, an owner for each limitation and a reasoned choice.
Measure the first scan separately from later ones: database downloads and caches can change the duration substantially. A median across several comparable runs is more useful than the fastest demo run.
Six cases that separate the tools
These are trial recipes, not results measured by Tamis. Keep each input, expected result, justification and actual output.
| Case | What it reveals | Expected evidence |
|---|---|---|
| The hidden dependency | Your package A depends on B, whose version is vulnerable. | B identified with its version, the path from A and an update option. The tool must not invent a resolved version from a version range. |
| The bundled copy | A library sits inside a shipped archive without appearing in the root manifest. | The copy and location are found, or the analysis limit is explicit. Include a Java archive assembled with its dependencies if you ship these. |
| The backported fix | The distribution fixed a package without adopting the latest upstream version. | The verdict uses that distribution's advisory and package version. An old upstream number alone does not prove vulnerability. |
| The test package | A vulnerable dependency is used for tests but absent from the production artifact. | The two scopes remain distinct. Absence from production does not erase possible risk to development machines or CI. |
| The unknown path | The function is called, not called, or outside the analysis capabilities. | Three justified verdicts. Missing function data and unsupported languages must not become proof of unreachability. |
| The unavailable database | The scanner cannot load advisories, or runs out of time. | Visible failure or degraded coverage, cache freshness if used, and explicit CI behaviour. Zero results must not become “no vulnerabilities”. |
The backport case is documented in Trivy's data source selection: for OS packages, the origin of a fix matters as much as the upstream version number.
120 alerts versus 80: who wins?
A fictional example, unrelated to the tools listed. Two scanners analyse the same artifact. A shows 120 rows, B shows 80. Neither wins yet: a row may be an advisory alias, another location or a duplicate.
After reconciliation, A and B report 75 and 70 distinct component/version and advisory pairs. That count still does not measure recall. You then inspect ten known vulnerable cases: A finds nine, B six. B looks quieter because it misses more cases in this set. On five fixed cases, A produces two incorrect alerts, B none: A therefore needs more triage too.
The useful result is “9 out of 10 cases found, 2 incorrect alerts on 5 fixed cases”, alongside the cases and limitations. These small numbers help locate disagreements; they do not establish an accuracy rate for all your projects. Add the time needed to understand and fix an alert: commercial comparisons rarely show that part of the cost.
Choose the workflow, not just the scanner
Need to block new vulnerable dependencies? Start with coverage of your formats, understandable CI results and updates the team can actually integrate. An open pull request is not yet a shipped fix.
Need to know which shipped products a new advisory affects? Check versioned SBOM retention, reanalysis, source freshness and team ownership. Rescanning the main branch does not describe an older release still in service.
Short of time for triage? Measure decision time on real alerts, with paths, sources and exceptions. A second database can add useful detections, but also duplicate advisories and maintenance. Add a tool only when its observed contribution justifies that work.
For cost, add any subscription, compute and storage, integration upkeep, triage and updates. Ask what is billed and what happens when you add repositories, contributors or scans. A per-seat price alone does not tell you the cost of the whole workflow.
Before you sign
Require a trial on your project, alert provenance and usable exports: CycloneDX or SPDX for the SBOM, a named VEX format for impact statements, and an export of triage decisions with their author, justification and expiry date. Test importing these into your target tool, then check total cost, transmitted data, retention and offline operation if you need it. Record the limitations you observe before choosing.
Wrapping up
A clean demo does not tell you how the tool will behave on your project. Compare the inventories first, then the cases whose answer you know, then the time to decide real alerts. Keep the tool that says where each alert comes from, shows what it could not analyze and keeps your decisions, with their proof.
Words in this article · 4 words
- CVE
- The unique number given to a known flaw, such as CVE-2021-44228.
- SBOM
- The list of a piece of software's components, with their versions.
- CycloneDX, SPDX
- The two standard SBOM formats.
- VEX
- A dated statement about a vulnerability's impact on an identified product: affected, not affected, fixed or under investigation. See the OpenVEX specification.
To revisit the basics: SCA explained simply. And for the code the team writes: Choosing a SAST tool without being fooled.
Start here: SCA: from inventory to priority