DEV Community

Cover image for Your One Dependency Is Actually 67 Packages
Moksh Gupta
Moksh Gupta

Posted on Originally published at devtoollab.com

Your One Dependency Is Actually 67 Packages

#devops #security #opensource #programming

Nobody audits a lockfile. You pick a handful of libraries deliberately, and everything underneath them shows up because a resolver said so, gets refreshed by a bot, and is never looked at again. The question supply chain security answers is what is actually down there, and whether it arrived the way you think it did.

I put a number on the first half of that on September 19, 2026. A fresh project with exactly one dependency, express@5.1.0, produced a CycloneDX bill of materials containing 67 components. The same process against a production Next.js 15 app with 112 direct production dependencies returned 762 library components, so the tree is nearly seven times larger than the part anyone chose. The longer version of this writeup, with every version and price, is on DevToolLab.

Supply chain security tools banner

Reproduce the 67 in Under a Minute

With Trivy 0.74.0 on your path, this is the whole thing:

mkdir sbom-demo && cd sbom-demo
npm init -y > /dev/null
npm install express@5.1.0 --package-lock-only --no-audit --no-fund
trivy fs --scanners vuln --format cyclonedx --output sbom.json package-lock.json
Enter fullscreen mode Exit fullscreen mode

Count what it wrote:

import json
bom = json.load(open("sbom.json"))
print(f"CycloneDX spec : {bom['specVersion']}")
print(f"components     : {len(bom['components'])}")
print(f"vulnerabilities: {len(bom.get('vulnerabilities', []))}")
Enter fullscreen mode Exit fullscreen mode

What came back on the day I ran it:

CycloneDX spec : 1.7
components     : 67
vulnerabilities: 0
Enter fullscreen mode Exit fullscreen mode

Zero vulnerabilities is the part worth reading carefully. It describes today, not next month, because disclosure almost always lands long after installation. The reason to keep the inventory is so that "are we affected" takes minutes rather than a week of grepping.

Three Jobs, Not One

The phrase "supply chain security" bundles together three problems that need separate tools, and treating them as one is why these projects stall.

Inventory means producing an SBOM listing every component in a build. Provenance means signing artifacts and attesting how they were produced, so a consumer can check the binary really came from the source it names. Detection means finding known vulnerabilities in the inventory, and separately catching packages that are malicious rather than just stale.

A scanner says nothing about whether your pipeline was tampered with. A signature says nothing about whether the thing you signed is full of compromised code.

The Free Stack Covers All Three

For inventory, Syft and Trivy both emit SPDX and CycloneDX and both carry an Apache 2.0 license. Syft, from Anchore, hit v1.52.0 on September 17, 2026 with 9,581 GitHub stars and does only cataloging, which makes it the cleaner pipeline component. Trivy, from Aqua Security, hit v0.74.0 on August 14, 2026 with 37,980 stars and folds scanning, misconfiguration checks and secret detection into the same binary. One tool in CI or one tool per job, that is the whole decision.

For detection, Grype reached v0.119.0 on September 17, 2026 and reads a Syft SBOM directly. Google's OSV-Scanner reached v2.6.0 on September 14, 2026 and pulls from the OSV database, where records are keyed to exact affected version ranges per ecosystem instead of vendor CPE strings. That difference shows up as noticeably fewer false positives. Both are Apache 2.0, and running both is not unreasonable.

For provenance, Sigstore's Cosign reached v3.1.3 on August 6, 2026. Its useful trick is keyless signing: short-lived certificates bound to an OIDC identity such as a GitHub Actions workflow, with the signature written to a public transparency log, so there is no long-lived private key for anyone to lose.

One thing to check if you are reading older comparisons: SLSA v1.2 is the current approved specification as of September 2026, and v1.1 is marked Retired. It adds a Source Track alongside the Build Track, which most published roundups predate.

The SLSA specification site showing Version 1.2 with status Approved and the Build Track, Source Track and Cross Track sections

Finally, storage. OWASP's Dependency-Track reached 5.1.0 on August 27, 2026 and ingests a CycloneDX SBOM from every build, then re-evaluates what it already holds as new advisories land. A CI scan answers "is this build clean right now". Dependency-Track answers "which of the forty services we shipped last quarter ship this package", which is the question an incident actually starts with, and one a folder of SBOM files cannot answer.

What the Paid Tools Are Selling

Reachability analysis, malicious-package detection, hardened base images and a support contract. The original article breaks the pricing down properly, but the shape is this.

Snyk publishes per-seat pricing: Free at $0 per month, Team from $25 per month, and Ignite from $1,260 per year, all per contributing developer, with Enterprise quoted. Chainguard sells the opposite approach, shipping hardened images so you have fewer CVEs to triage rather than better triage. Up to five images are free, and its Catalog tier with 2,000-plus images starts at $19,000 for a team of 10, built in SLSA L3 infrastructure under a contractual CVE remediation SLA. Both checked on their own pricing pages on September 19, 2026.

The Snyk plans page showing Free at $0 per month, Team at $25 per month and Ignite at $1,260 per year, each per contributing developer

Socket is the third approach, judging a package by what its code actually does rather than matching it to a CVE list, which is the only one of the three that flags a malicious release on day zero. I could not verify its current pricing: socket.dev returned HTTP 403 to every non-browser client I tried, so I have left the number out rather than guess at it.

Side by Side

Tool Job License Version (Sep 19, 2026) Cost
Syft SBOM generation Apache 2.0 v1.52.0 Free
Trivy SBOM plus scanning Apache 2.0 v0.74.0 Free
Grype Vulnerability scanning Apache 2.0 v0.119.0 Free
OSV-Scanner Vulnerability scanning Apache 2.0 v2.6.0 Free
Cosign Signing and attestation Apache 2.0 v3.1.3 Free
Dependency-Track SBOM management Apache 2.0 5.1.0 Free, self-hosted
Snyk Scanning plus reachability Commercial n/a $0 to $1,260/yr per developer
Chainguard Hardened base images Commercial n/a 5 images free; Catalog from $19,000
Socket Malicious package detection Commercial n/a Not publicly verifiable

Where to Start

Run Trivy in CI. One binary, an SBOM and a vulnerability report, no purchase order. That is the honest answer for most teams, and if a customer is only asking for an SBOM then Syft alone finishes the job.

Add Dependency-Track once you are running more than a handful of services, because per-build scanning stops answering the question you will actually be asked. Add Cosign and publish provenance if other people consume what you ship. Look at behavioral analysis if malicious packages rather than outdated ones are what worry you, since CVE matching structurally cannot catch those. Price Chainguard against the hours your team currently spends patching base images, not against zero.

Two things worth having open while you do any of this: a SHA256 file checksum for confirming a release artifact matches the digest its project published, and npm package info for looking at maintainers and release history before a package becomes one more node in the tree.

Conclusion

Everything load-bearing here is free and actively maintained. Syft, Trivy, Grype, OSV-Scanner, Cosign and Dependency-Track are all Apache 2.0 and all shipped a release within about five weeks of September 19, 2026. Between them you get an inventory, a scan, a signature and a history.

Paid tools buy less noise, day-zero malicious detection, hardened images and someone to call. None of that is the first step. Generate one SBOM, look at how many packages you did not know you were shipping, and decide from that number.

References

Top comments (0)