A small team can cover the basics with free options sorted by job: an inventory from lockfiles, known vulnerability checks, a pull request dependency review, signature verification and a project health check. Pick one option per job and avoid overlap, since two tools doing the same job just doubles your alerts.
Think in jobs, not products
Lists of tools go stale and tempt you to install five. Start from the job. For each one below, a free option exists in documented, public form. This post names documentation, not winners, and the right choice depends on your stack and hosting.
| Job | Free option to look at | What it gives you |
|---|---|---|
| Inventory | Dependency graph on your code host, or an open SBOM format tool | A list of packages from manifests and lockfiles |
| Known vulnerabilities | Package manager audit command, or OSV-Scanner | Matches your list to advisory data |
| Pull request check | Dependency review | Shows what a change adds or updates |
| Package integrity | Registry signature verification | Confirms packages match registry signatures |
| Project health | OpenSSF Scorecard | Checks risky practices in a project |
What each one actually says about itself
The npm documentation says the audit command submits a description of your dependencies to your registry and asks for a report of known vulnerabilities. It also says the audit level option changes the failure threshold only and does not filter the report. That matters in CI, where you may want to fail only on high severity.
OSV-Scanner describes itself as an officially supported frontend to the OSV database that connects a project's dependencies with the vulnerabilities that affect them. It runs as a command line tool, including in pipelines.
The OpenSSF Scorecard site says you can run it on your own code with a GitHub Action or on anyone's project from the command line, and gives an install time of under ten minutes. Use it on your own repositories, and on a package you are about to adopt.
For standards, CycloneDX and SPDX are both open formats for describing software components. Pick whichever your customers or tools ask for. You can generate either from a lockfile, as covered in generating CycloneDX and SPDX from an npm lockfile.
Limits to know before you rely on them
Free checks match names and versions to advisory data. They do not tell you whether your code calls the vulnerable function. They also cover the ecosystems they support, so check yours is on the list. A clean result means the matcher found nothing it knows about, not that the software is safe.
Maintenance is the hidden cost. Each added tool needs a person to read its output. If nobody owns it, switch it off rather than let alerts pile up. For ownership, see who owns supply chain security without a security team.
A sensible starting set
Use the dependency graph or a lockfile based inventory, one vulnerability matcher, dependency review on pull requests and a Scorecard run on new packages. That is four jobs and about a day of setup.
Safeguard covers SBOM and dependency scanning with reachability analysis, and offers a free scan at https://gold.safeguard.sh/scan if you want a quick comparison against your current setup.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do free tools replace a paid platform?
They cover the basics. Paid platforms usually add reachability, cross repository views, policy and support. Decide based on the gaps you actually feel.
Which SBOM format should we choose?
Choose the one your customers or tools request. Both CycloneDX and SPDX are open standards, and most tooling can convert between them.
Sources
- npm Docs, npm-audit
- OSV-Scanner
- OpenSSF Scorecard
- CycloneDX, Specification overview
- SPDX, About
- GitHub Docs, Dependency graph
- GitHub Docs, Dependency review
Last reviewed: 19 October 2026.
