To choose an SCA tool, run two or three candidates on your real repositories and score them against a fixed checklist: ecosystem coverage, accuracy, noise, reachability, license policy, SBOM output, CI fit, deployment model, fix guidance, reporting, cost unit and support. Scores from your own code beat any feature list.
Safeguard publishes this guide and sells a competing product, so we describe other tools only from their own documentation.
Key takeaways
- Test on your repositories, with your lockfiles, for at least a week.
- Count findings a developer would act on, not total findings.
- Ask vendors to state limits in writing: languages, dependency depth, data sources.
- Write down the cost unit and project it at double your headcount.
What should an SCA tool do?
At minimum it must inventory your direct and indirect dependencies and match them to known vulnerabilities. Beyond that, buyers differ. Some need reachability to cut noise, some need license policy, and some need an SBOM for customers or regulators.
Decide your top three needs before you look at any product. The checklist below turns each into a test.
The 12 point checklist
| # | Criterion | What to ask | How to test it |
|---|---|---|---|
| 1 | Ecosystem coverage | Does it read every manifest and lockfile we use? | List your package managers; run the tool and confirm each project appears |
| 2 | Direct and indirect dependencies | Does it resolve transitive packages? | Pick a known transitive package and check it is reported with its path |
| 3 | Vulnerability data | Which sources feed it, and how fresh are they? | Compare findings with another tool on the same repository |
| 4 | Accuracy | How many findings are wrong or duplicated? | Review a sample of 20 findings by hand |
| 5 | Noise and prioritization | Does it rank by exploit data, KEV or reachability? | Count findings a developer would act on |
| 6 | Reachability | Which languages and dependency depths, and what does each label mean? | Read the label definitions and test a known unused package |
| 7 | License policy | Can it enforce an allow or deny list and handle unknown licenses? | Add a banned license to a test project |
| 8 | SBOM | Can it generate and import CycloneDX and SPDX? | Export one and open it in a second tool |
| 9 | CI and developer workflow | Does it fail builds, comment on pull requests, work in the IDE? | Wire it into one pipeline and one editor |
| 10 | Deployment and data handling | Does source leave our machines? Can it run offline? | Read where analysis runs; test a local run |
| 11 | Reporting and exceptions | Can we record accepted risk with an owner and date? | Create an exception and find it again |
| 12 | Cost and limits | What is the unit, and what are the caps? | Project cost at double headcount; read the free tier limits |
How do I test accuracy and noise?
Use one repository you know well. Run each candidate and take three numbers: total findings, findings a developer would act on, and findings you know to be wrong. Tools that report fewer findings are not automatically better. A scanner that misses a lockfile looks quiet.
Cross check with an open source baseline such as OSV-Scanner or Trivy, since differences between tools often come from different data sources. OSV-Scanner uses the OSV database, and Trivy lists vendor advisories for OS packages and sources such as the GitHub Advisory Database for languages.
How do I judge reachability claims?
Ask four questions. Which languages and package managers? Does it cover transitive dependencies? What does "no path found" or "unreachable" mean? Is it included in the plan you would buy?
Vendors answer differently. Snyk documents reachability for Java, JavaScript and TypeScript, and Python as generally available, with C# in early access, and says no path found does not mean unexploitable. Semgrep documents rules for critical and high severity CVEs in supported languages and says transitive dependencies do not get reachability analysis, with limited exceptions. Semgrep's pricing page lists reachability on its Free edition, while Snyk's plans page does not mention it. Read the pages again on the day you buy.
How do I judge license and SBOM features?
Give each tool a small project with one banned license and one unknown license, and see what it does. Then export an SBOM and import it into another tool. OSV-Scanner enforces SPDX allowlists, Trivy classifies licenses by category, and ORT and ScanCode export CycloneDX and SPDX. Our license compliance guide goes deeper.
How do I judge cost?
Find the unit first. Semgrep's pricing page lists Free for up to 10 contributors, then $30 per contributor per month on Teams as of 19 October 2026. Snyk's plans page lists a Team plan from $25 per month for up to 10 developers and does not state the Open Source test limit on the Free plan. Units differ, so compare at your headcount now and at double. Open source tools carry no license fee but cost engineering time for triage, policy and reporting.
Where does Safeguard fit?
Safeguard offers reachability analysis, SBOM generation and import, a CLI and local runner that keeps source on your machine, IDE extensions for VS Code, JetBrains and Cursor via Open VSX, and an MCP server. Start with the free in-browser scan, which checks a manifest or SBOM of up to 100 dependencies with no login, and browse Gold for packages, CVEs with CISA KEV status and malicious packages. Score us on the same checklist as every other tool.
Frequently asked questions
How many SCA tools should I trial?
Two or three, plus an open source baseline. More than that makes comparison hard and delays a decision.
How long should a trial run?
At least a week on real repositories, so that new advisories and pull requests exercise the tool.
Is a free SCA tool enough?
It can be, when you only need known vulnerability matches. Add a commercial tool when you need reachability, central reporting or evidence for customers.
What is the most common mistake when buying SCA?
Comparing feature lists instead of results on your own code. Total finding counts also mislead, because a tool that skips a lockfile looks clean.
Should SCA be part of a bigger platform?
It can be if you want one workflow for several scan types. Judge the SCA module on its own, then judge the integration.
What should be in a vendor contract about SCA?
Ask for supported languages, data sources and limits in writing, plus the pricing unit and what happens when you exceed a cap.
Sources
- OSV-Scanner documentation
- OSV-Scanner license scanning
- Trivy vulnerability scanning
- Trivy license scanning
- Snyk reachability analysis
- Snyk plans
- Semgrep Supply Chain overview
- Semgrep pricing
- ScanCode Toolkit
- OSS Review Toolkit
- Safeguard free scan
Last reviewed: 19 October 2026.
