Ranked by accuracy against known dependency ground truth, the best SBOM generators in 2026 are cdxgen for JavaScript and JVM projects, Syft for multi-ecosystem breadth and container images, Trivy as a fast third, and Microsoft's sbom-tool only where SPDX output and build-time integration are hard requirements. An SBOM is only as useful as it is complete — every component the generator misses is a CVE you will not be warned about — and the completeness spread between tools is much wider than their marketing suggests.
How we measured accuracy
Ground truth came from four reference applications where we know exactly what is inside, because we built the resolution ourselves and verified by hand:
- node-app: pnpm workspace, 1,214 resolved packages including 3 bundled dependencies
- py-app: uv-managed Python service, 187 packages, 2 vendored libraries
- go-app: Go service, 96 modules
- java-app: Maven build, 143 artifacts including shaded jars
Each tool generated an SBOM from source where supported and from the built container image where relevant, in January 2026. We scored recall (components found / actually present), precision (found components that actually exist — hallucinated or duplicated entries count against), and metadata quality (valid purl, version, and license per component). Recall is the headline number because a missing component is silent, while a spurious one at least fails loudly downstream.
The rankings
| Rank | Tool | Version | Avg recall | Avg precision | License accuracy |
|---|---|---|---|---|---|
| 1 | cdxgen | 11.1 | 97% | 96% | 91% |
| 2 | Syft | 1.19 | 94% | 98% | 88% |
| 3 | Trivy | 0.59 | 91% | 97% | 84% |
| 4 | sbom-tool | 3.1 | 82% | 99% | 79% |
| 5 | GitHub SBOM export | API | 76% | 95% | 81% |
Averages hide the per-ecosystem story, which is where the actual decision lives.
cdxgen: highest recall, highest configuration burden
CycloneDX's cdxgen hit 99 percent recall on node-app and 98 percent on java-app — it found the bundled npm dependencies and looked inside shaded jars, which nothing else fully managed. It achieves that by actually invoking build tooling when available (mvn dependency:tree, lockfile parsing with workspace resolution) rather than only inspecting files:
cdxgen -t js -o bom.json --spec-version 1.6 .
FETCH_LICENSE=true cdxgen -t java -o bom.json .
The cost is environment sensitivity. In a bare container without Maven, java-app recall dropped to 71 percent — worse than Syft — because the build-integration path was unavailable and it fell back to file scanning. cdxgen is the accuracy winner only if you run it where the build runs. Its CycloneDX 1.6 output is also the richest we saw; if you care about the newer spec features, our CycloneDX 1.7 review covers what is coming next.
Syft: the best default, especially for images
Anchore's Syft was within a few points of cdxgen on source scans and clearly ahead on container images, where its layer-aware cataloging picked up OS packages (apk, dpkg, rpm) alongside application dependencies in one pass:
syft registry:myapp:1.4.2 -o cyclonedx-json@1.6 > image.cdx.json
syft dir:. --source-name myapp -o spdx-json > source.spdx.json
Its misses were consistent and predictable: bundled and vendored code that never appears in a lockfile (2 of 3 bundled npm packages missed, both vendored Python libraries missed). Precision was the best of the scanners — 98 percent, with no hallucinated components and duplicates only where the same package genuinely appears in multiple layers. Syft is what we recommend as the default generator: least configuration, most consistent, native output in both CycloneDX and SPDX.
Trivy and sbom-tool: fine, with caveats
Trivy's SBOM generation rides on the same catalogers as its vulnerability scanning, and it shows: fast, solid on lockfile ecosystems and images, 91 percent average recall with the same vendored-code blind spots as Syft plus weaker JVM coverage (86 percent on java-app — shaded jars again). If Trivy is already your scanner, its SBOMs are good enough to standardize on. One flag worth knowing: --format cyclonedx at image scan time costs almost nothing over the scan you were running anyway.
Microsoft's sbom-tool is a different animal — it is designed to run inside your build with explicit inputs (-b build drop, -bc build components), producing SPDX 2.2 with strong integrity hashes and near-perfect precision. Its 82 percent recall reflects that it documents what the build tells it about, not what exploration finds; transitive resolution outside supported ecosystems is thin. Choose it when a customer contract says SPDX and your builds are already structured around it, not as a general-purpose generator.
GitHub's dependency-graph SBOM export (one API call, zero setup) is the floor: fine for a quick inventory of manifest-declared dependencies, blind to anything resolution-time or vendored, and its 76 percent recall makes it a supplement rather than a system of record.
What "accuracy" misses: the operational layer
A generator choice is table stakes; three practices determine whether the SBOMs are worth anything a year later:
- Generate at build time, per release, and archive. An SBOM regenerated from main today does not describe the artifact you shipped in March. The archive is what you query when the next xz-style advisory drops.
- One SBOM per artifact, merged views downstream. Generate per-image and per-package, then let tooling aggregate — hand-merged mega-SBOMs rot instantly. This lifecycle piece — storage, diffing releases, querying across hundreds of artifacts, distributing to customers — is the job SBOM Studio exists for; generators deliberately stop at the file.
- Validate in CI.
sbom-utility validateorpyspdxtoolscatches malformed output before a customer's ingestion pipeline does. NTIA minimum elements are easy to fail on supplier name alone.
Frequently asked questions
Which SBOM format should I generate, CycloneDX or SPDX?
Generate CycloneDX 1.6 as your working format — richer vulnerability and service metadata, better tool support in security pipelines — and produce SPDX on demand for customers and regulators that require it. Syft and Trivy emit both natively, and format conversion is lossy enough that generating twice from source beats converting.
Why do all generators miss vendored and bundled code?
Vendored code has no manifest entry, so lockfile-driven catalogers never see it; only build-integrated tools like cdxgen or binary-analysis approaches catch some of it. If you vendor dependencies, declare them explicitly in an SBOM fragment you merge at build time — that is currently the only reliable fix.
How often should SBOMs be regenerated?
Never regenerate for the same artifact — an SBOM is immutable documentation of a specific build. Generate once per build, then rescan the stored SBOM against new vulnerability data continuously; that separation is what makes answering "are we affected" a query instead of a rebuild. Platforms like Safeguard automate the rescan half against your archived SBOMs.
Is SBOM accuracy good enough for compliance requirements like EO 14028 artifacts?
Yes for the leading tools, with the vendored-code caveat documented. Agencies and enterprise customers currently check structural validity and NTIA minimum elements rather than auditing recall, but the gap between 94 and 76 percent recall is entirely real when the SBOM is used for vulnerability response, which is the point.