A software bill of materials is only as trustworthy as the tool that writes it. Three open-source generators dominate the conversation, and all three shipped fresh releases in October 2026. Syft reached 1.55.0 on October 20 and Trivy reached 0.76.0 on October 14, according to a revisit.tech review of vulnerability scanners. cdxgen followed with 13.5.0 on October 23, based on its GitHub release page.
The tool question hides a format question. Syft, Trivy and cdxgen can all write CycloneDX, and all three can also reach SPDX, so the choice between SPDX vs CycloneDX decides what your downstream consumers can read. The same inventory feeds software composition analysis tools such as Snyk, Mend, Socket and Dependabot, which makes a clean SBOM the cheapest upstream fix in a supply-chain program.
We built this comparison from project pages and release records dated October 2026. Where only one source backed a claim, the text says reportedly or names the source. We found no independent head-to-head speed test of these three tools, so this article prints no speed numbers. Instead, it hands you a short harness to measure them on your own repositories, which is the only benchmark that predicts your own pipeline.
The sections below cover the formats behind a software bill of materials, a full specs table, the evidence we could verify, cost, the release notes that matter, seven real-world scenarios, use-case picks, a migration guide, pros and cons, and a verdict. If you only have two minutes, read the quick answer first.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Quick Answer: Which SBOM Tool Fits Which Team
Pick Syft when you inventory container images and directories and want a generator that stays out of your way. Pick Trivy when one binary should both write the SBOM and match vulnerabilities, because you then run a single tool in CI instead of two. Pick cdxgen when your repositories span many languages, when you want CycloneDX 1.7 output, or when you need cryptographic bills of materials and a Dependency-Track pipeline.
On the format side, choose CycloneDX when security teams consume the software bill of materials and SPDX when a customer, auditor or standards body asks for it by name. SPDX carries the ISO/IEC 5962:2021 designation on its own site, which matters in procurement language. CycloneDX describes itself as a full-stack BOM standard and now covers cryptographic assets, which matters for post-quantum migration planning.
- Container-first platform teams: Syft, with CycloneDX or SPDX JSON, plus Grype for matching.
- One-tool CI pipelines: Trivy, writing CycloneDX and scanning in the same run.
- Polyglot monorepos and Dependency-Track shops: cdxgen 13.x, with the version pinned.
- Embedded and firmware teams: look at lynkctl from the SPDX tools list, which targets C and C++ projects.
- Python and AI model provenance: look at Pitloom, announced October 12, 2026 for SPDX 3.
No single tool wins every column. The rest of the article shows where each one gives ground, so you can decide with your own constraints in mind.
SPDX vs CycloneDX: The Format Decision Comes First
Generators are interchangeable in ways formats are not. If you pick the wrong format, every consumer downstream pays for it, from vulnerability platforms to procurement reviewers. So settle the format before you benchmark a single tool.
SPDX in 2026: a standard with a long tail
SPDX describes itself as a freely available international open standard, designated ISO/IEC 5962:2021. The project built its reputation on license and provenance data, and the 3.x line widens the scope. When the project announced the first release candidate of SPDX 3.1 on January 26, 2026, it said the model now reaches beyond software to safety, service, hardware, supply chain and operations. The same announcement called the release candidate a testing and validation release whose features could still change.
Two version lines run in parallel today. Tools such as cdxgen already export SPDX 3.0.1 JSON-LD, while an SPDX 2.3.1 support branch exists in the specification repository. The project also keeps adding tooling, and we cover that wave in its own section below. Reportedly, the SPDX 3.1 second release candidate was still under development on October 20, 2026, with its milestone running past a September 27 target. Treat 3.1 as a spec to watch, not a spec to emit.
CycloneDX in 2026: security-first and moving fast
The OWASP-hosted standard at cyclonedx.org presents CycloneDX as a full-stack bill of materials format for reducing software supply-chain risk. October 2026 coverage centers on version 1.7. Trivy added CycloneDX 1.7 support during its 0.71 cycle, and cdxgen documents spec targets of 1.6, 1.7 and 2.0 through its --spec-version flag. By contrast, cdxgen no longer produces 1.4 or 1.5 documents directly, because those versions predate features that v13 needs. If a consumer insists on 1.5, you generate at 1.6 or later and convert down with cdx-convert.
CycloneDX also gives cryptographic assets a home. A Safeguard guide published October 23, 2026 walks through the cryptographic BOM, or CBOM, field by field. Both Trivy 0.76.0 and cdxgen 13.5.0 added CBOM-related work this month, which signals where tool vendors expect demand.
| Dimension | SPDX | CycloneDX |
|---|---|---|
| Steward | Linux Foundation project | OWASP project |
| Standard status | ISO/IEC 5962:2021 (per spdx.dev) | Described as a full-stack BOM standard |
| Versions in tool output, Oct 2026 | 3.0.1 in use, 2.3.1 support branch | 1.6 and 1.7, with 2.0 as a cdxgen target |
| Newest milestone | 3.1 RC1, announced Jan 26, 2026 | 1.7 supported by Trivy and cdxgen |
| Scope growth | Safety, service, hardware, supply chain, operations (3.1 model) | Software, cryptographic assets (CBOM) |
| Strongest audience | Compliance, licensing, procurement | Security engineering, vulnerability tooling |
| Conversion between the two | Lossy, per Safeguard’s field mapping guide | Lossy, per Safeguard’s field mapping guide |
| Newest tools announced | Pitloom, SBOMlyze, sbomqs, lynkctl, DevKit Dossier | cdxgen 13.5.0, Trivy 0.76.0 CBOM work |
The pragmatic rule: write CycloneDX for internal security workflows, and keep an SPDX export path for customers who ask. Both Syft and cdxgen can emit both, so you do not need two generators to do that.
Full Specs Comparison: Syft vs Trivy vs cdxgen
The table below uses only details we could confirm from project pages and dated reviews. Where the sources did not confirm a field, the cell says so. A blank honest cell beats a confident wrong one, especially in a table people screenshot.
| Spec | Syft | Trivy | cdxgen |
|---|---|---|---|
| Primary role | SBOM generator | Scanner that also writes SBOMs | CycloneDX BOM generator |
| Maintainer | Anchore | Aqua Security | OWASP cdxgen project |
| Latest version verified | 1.55.0 (Oct 20, 2026) | 0.76.0 (Oct 14, 2026) | 13.5.0 (Oct 23, 2026) |
| Formats written | SPDX and CycloneDX | CycloneDX and SPDX | CycloneDX, plus SPDX 3.0.1 JSON-LD |
| CycloneDX versions | Not confirmed in sources | 1.7 support added (0.71 cycle) | 1.6, 1.7 or 2.0 via –spec-version |
| Licence | Not confirmed in sources | Not confirmed in sources | Apache-2.0 |
| List price | No official price list confirmed | No dated official price found | No paid plans found |
| Cryptographic BOM | Not confirmed in sources | Experimental CBOM security levels (0.76.0) | Certificate identification in CBOMs (13.5.0) |
| OS package coverage | Not itemized in sources | Echo-patched Java and Node.js packages (0.76.0) | Expanded via osquery 5.24.0 (13.5.0) |
| Local container stores | Podman and Buildah container-storage work (Oct 5 pull request) | Not itemized in sources | Not itemized in sources |
| Adoption signal | Syft and Grype passed 50 million combined downloads | Not confirmed in sources | Not confirmed in sources |
| Security issue on record | Issue filed Oct 21 on Go 1.26.8 in v1.55.0 binaries | None confirmed in the sources checked | See the release notes section below |
| Best fit | Container and directory inventories | One-tool CI scanning | Polyglot repos, CBOM, Dependency-Track |
Read the table for gaps as well as strengths. Syft’s blank cells reflect thin source coverage, not missing features, and the same goes for Trivy. cdxgen stands out for how openly it documents spec targets and bundled components, which makes it the easiest of the three to audit from the outside. That openness cuts both ways, as the security notes below show.
One more caution on version numbers. Tools in this class ship patch releases every week or two, so a table like this ages fast. Check the release page of each project on the day you pin a version, and record the exact version string in your pipeline logs.
What the Evidence Says: Benchmarks and Sources
A fair question for any comparison is which tool finds the most components. The honest answer today is that the sources we checked publish no neutral, repeatable head-to-head count for Syft, Trivy and cdxgen on the same targets. What exists instead is a set of dated data points about currency, adoption, spec coverage and conversion risk. The table lists each one with its limits.
| Source | Date | Data point | Limit |
|---|---|---|---|
| Anchore announcement | Oct 22, 2026 | Syft and Grype passed 50 million combined downloads | Downloads measure reach, not accuracy |
| revisit.tech scanner review | Oct 20, 2026 | Syft 1.55.0 and Trivy 0.76.0 named as current | Third-party review, versions only |
| cdxgen documentation | Oct 2026 | Spec targets 1.6, 1.7 and 2.0, no direct 1.4 or 1.5 output | Written by the tool’s maintainers |
| SPDX project posts | Oct 5 and Oct 12, 2026 | Five named tools added to the ecosystem list across two posts | A tools list does not rank quality |
| Safeguard guides | Oct 23, 2026 | Field-by-field SPDX 3.0.1 to CycloneDX 1.7 mapping, with conversion loss documented | Vendor blog, no loss percentage quoted here |
Five publishers, five different kinds of evidence, and none of them is a speed test. That gap matters because SBOM generators disagree in practice. Lockfile-based resolution, installed-package inspection and image-layer cataloging produce different component lists for the same project. A Dev.to post published in October 2026 made the point in its title, arguing that an SBOM is a tool output and not a fact about your software. We agree with the framing.
So measure on your own code. The script below runs all three tools against one target, times each run, counts components and lists package URLs that appear in one output but not another. Run it on three repositories that look like your real workload: a container image build, a language-heavy monorepo and a legacy service with vendored dependencies.
#!/usr/bin/env bash
set -euo pipefail
TARGET="${1:-.}"
mkdir -p out
/usr/bin/time -f "syft %e s" syft "dir:$TARGET" -q -o cyclonedx-json=out/syft.cdx.json
/usr/bin/time -f "trivy %e s" trivy fs --quiet --format cyclonedx --output out/trivy.cdx.json "$TARGET"
/usr/bin/time -f "cdxgen %e s" cdxgen -r -o out/cdxgen.cdx.json --spec-version 1.7 "$TARGET"
for t in syft trivy cdxgen; do
echo "$t components: $(jq '.components | length' out/$t.cdx.json)"
jq -r '.components[].purl // empty' out/$t.cdx.json | sort -u | tee out/$t.purls | wc -l
done
echo "In syft but not cdxgen:"
comm -23 out/syft.purls out/cdxgen.purls | head -40
echo "In cdxgen but not syft:"
comm -13 out/syft.purls out/cdxgen.purls | head -40Interpret the diff, not just the totals. A tool that reports more components may be double-counting, or it may be the only one that saw your vendored libraries. Open ten disagreements by hand per repository and decide which tool was right. After three repositories, you will know more than any published benchmark can tell you.
Pricing and Total Cost of Ownership
All three generators are open source, and none of the sources we checked lists a price for the core tool. That does not make them free to run. The real bill for a software bill of materials program sits in pipeline minutes, artifact storage, engineer time spent triaging noise, and any commercial platform you bolt on for policy, reporting or support.
| Item | Confirmed list price | Licence confirmed | Where the real cost sits |
|---|---|---|---|
| Syft | No official price list confirmed | Not confirmed in sources | CI runtime on large images, SBOM storage |
| Trivy | No dated official pricing found | Not confirmed in sources | Vulnerability database updates, triage time |
| cdxgen | No paid plans found | Apache-2.0 | Version pinning, sandboxing of scanned code |
| SBOMlyze (SPDX tools list) | Open-source CLI and GitHub Action | Apache-2.0 | Review time on SBOM diffs |
| SPDX and CycloneDX specifications | Freely available standards | Open standards | Mapping work between the two |
Budget three line items. First, compute: scanning every image on every commit multiplies minutes quickly, so generate on build and cache on digest. Second, storage and retention: an SBOM per build per environment adds up, and you need to keep them as long as you support the release. Third, people: somebody must own the policy that says what happens when an SBOM shows a banned package or a missing license field. Expect that workload to grow, because AI coding tools add dependencies faster than reviewers read lockfiles.
Commercial platforms from the same vendors add policy engines, dashboards and support contracts. Their prices were not confirmed in the sources we used, so we do not quote any. If you evaluate one, ask for per-asset pricing in writing and test whether the paid layer reads standard CycloneDX or SPDX files from the open-source tool. Portability of your SBOM archive is the cheapest insurance against vendor lock-in.
Release Notes That Matter for Syft, Trivy and cdxgen
Syft. Anchore’s Syft architecture documentation still describes it as the Syft SBOM tool, and the project shows no rename, retirement or acquisition. Version 1.55.0 is the newest release we verified. On October 5, a pull request added Linux container-storage support for local images built with daemonless Podman or Buildah, which helps teams that have dropped the Docker daemon. On October 22, Anchore said it joined OpenChain as a vendor partner and that Syft and Grype passed 50 million combined downloads. The less comfortable item landed October 21, when an issue reported that the v1.55.0 release binaries were built with Go 1.26.8 and carried standard-library vulnerabilities. The issue asked for release builds on Go 1.26.10 or later.
Trivy. Version 0.76.0 landed October 14. It added vulnerability detection for Echo-patched Java and Node.js packages, wider RapidFort base-image coverage and experimental CBOM output with nominal cryptographic security levels. Reportedly, a 0.76.1 patch followed on October 21 with dependency updates and mitigations tied to the eMudhra intermediate-CA key compromise, though we could not confirm that date from a second source. A pull request updated October 25 also teaches Trivy’s SPDX serializer to handle the SHA-512 hash algorithm, which is a small change that matters to anyone who validates hashes strictly.
cdxgen. The cdxgen documentation calls it an OWASP tool for CycloneDX BOM generation, and the repository is public, JavaScript-based and Apache-2.0 licensed. The latest release is version 13.5.0, which adds PHP runtime detection, revised certificate identity handling in CBOMs, improved Go service and module evidence, wider operating-system package coverage through osquery 5.24.0 and extra safeguards against executing scanned-project code. Its PHP images were rebuilt on PHP 8.3.36, 8.4.27 and 8.5.12. Per a GitHub advisory, a server-mode flaw in versions before 13.5.0 let unauthenticated clients bypass the Git-host allowlist and override request options, and the advisory points to 12.8.7 as a patched 12.x release. A second advisory reportedly covers a bundled Node.js runtime flaw, tracked as CVE-2026-111497, in standalone binaries.
The common thread is that SBOM tools are themselves software with supply chains. Syft’s Go toolchain, cdxgen’s bundled Node.js and Trivy’s certificate trust store all showed up in October issue trackers. Pin versions, verify checksums and subscribe to each project’s security advisories. A scanner that nobody patches turns into a liability that wears a compliance badge.
The SPDX Tooling Wave Around the Big Three
While Syft, Trivy and cdxgen fight for the default slot, the SPDX project has been quietly expanding the edges of the ecosystem. On October 5, 2026, it announced four additions in a post titled around four new tools in five weeks, then added a fifth on October 12. They cover gaps the big three leave open.
- SBOMlyze: an Apache-2.0 command-line tool and GitHub Action that reviews changes between SPDX, CycloneDX and Syft SBOMs. It turns two files into a readable diff, which is exactly what a pull request reviewer needs.
- sbomqs: a quality and compliance checker for SBOMs. Run it after generation to score what your tool produced.
- lynkctl: a command-line generator for C and C++ and embedded firmware projects that writes SPDX 3.0.1 and CycloneDX without executing the build.
- DevKit Dossier: a hosted record keeper for manufacturers that sell software, firmware, mobile apps or SDKs in the EU.
- Pitloom: announced October 12, it generates SPDX 3-compliant SBOMs for Python applications and AI models.
Two patterns stand out. First, quality tooling has arrived. A generator without a checker invites confident but wrong files, so sbomqs and SBOMlyze belong in any serious pipeline. Second, SPDX 3 tooling targets niches the general scanners ignore, such as firmware and machine-learning models. If your product ships either one, the general-purpose trio will not cover you on its own.
SDKs deserve special attention here, since DevKit Dossier names them explicitly. Any SDK you embed counts as a component your SBOM should list, including the fraud-detection kits from Kount, Sift and Forter that many online businesses ship inside their apps. These tools are young, and the sources describe them mostly through the announcements that introduced them. Trial each one on a throwaway branch first. A tool announced two weeks ago has not yet met your weirdest build system, and your weirdest build system is where SBOM accuracy usually breaks.
Seven Real-World Scenarios from October 2026
Abstract feature lists do not decide purchases. The scenarios below come from events documented in October 2026 and show where each choice pays off or bites.
1. A scanner shipped with an old Go toolchain. The October 21 issue on Syft v1.55.0 binaries shows how a security tool can inherit the vulnerabilities of its own build chain. Teams that run the binary in locked-down CI should check which Go version their pinned release used and decide whether to build from source with a newer toolchain. The lesson applies to every generator, not only Syft.
2. Server mode exposed to the wrong network. cdxgen offers an HTTP server mode that accepts a path or a Git URL and returns an SBOM. According to the advisory published around October 20, unauthenticated clients could abuse it to run build scripts on versions before 13.5.0. If you ran server mode inside a shared cluster, upgrade, put it behind authentication and restrict which hosts it may clone from.
3. A version that was not the newest one. A project discussion between late September and mid October reported that cdxgen 13.1.0 and later sat on GitHub while npm still showed 12.8.4. Pipelines that install from a package registry and pipelines that pull a release binary can therefore disagree about what current means. Pin an exact version and verify it, then record it next to every SBOM you archive.
4. A platform team without a Docker daemon. The October 5 Syft pull request that adds container-storage support targets developers using Podman or Buildah on Linux. If your build agents run rootless and daemonless, check that your generator reads local storage directly instead of requiring a push to a registry first.
5. A firmware vendor selling into the EU. lynkctl and DevKit Dossier, both announced October 5, address products with C and C++ code, embedded firmware and SDKs. Teams in that position often cannot run a general scanner against a vendor toolchain. A generator that reads the project without executing the build, paired with a record keeper for EU obligations, fits better than a container-first tool.
6. A machine-learning team with model artifacts. Pitloom, announced October 12, writes SPDX 3 documents for Python applications and AI models. Because SPDX 3.x models more than software packages, it suits provenance records that touch model files. Pair it with your general SBOM so the application and the model share one audit trail.
7. A defense supplier facing procurement language. Anchore’s site points to DoW Instruction 8430.01 and says it makes software evidence a condition to operate. A supplier who reads that line should ask the buyer which format and which minimum fields they expect before choosing a generator. When the buyer names SPDX, the ISO/IEC 5962:2021 designation helps your case. When the buyer names nothing, CycloneDX output with an SPDX export path covers both bets.
Fitting an SBOM Generator Into Your CI Pipeline
Choosing a generator is the easy half. The harder half is deciding when it runs, where its output goes and who reads it. Teams that treat SBOM creation as a release-day chore end up with files that describe last month’s code. Teams that generate on every build and store the result next to the artifact get an audit trail almost for free.
A workable pattern has five stages. Generate the SBOM at build time, when lockfiles, base images and compiled outputs all exist. Validate it against the schema for the version you emit. Score it with a quality checker such as sbomqs. Diff it against the previous build with SBOMlyze so reviewers see what changed. Finally, publish it as a build artifact and feed a copy to your vulnerability matcher. Each stage costs seconds, and each one catches a different failure.
name: sbom
on: [push]
jobs:
sbom:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Generate SBOM with a pinned tool version
run: |
syft --version
syft dir:. -q -o cyclonedx-json=sbom.cdx.json
- name: Count components
run: jq '.components | length' sbom.cdx.json
- name: Keep the file with the build
uses: actions/upload-artifact@v4
with:
name: sbom
path: sbom.cdx.jsonSwap the generate step for Trivy or cdxgen without changing the rest of the job. That portability is the reason to standardize on CycloneDX or SPDX files as the contract between stages. If every later step reads a standard file, replacing the generator becomes a one-line change, and your migration risk drops accordingly.
Three habits keep the pipeline honest. Record the tool name and exact version inside your build logs, because an SBOM from Syft 1.55.0 and one from a later release can differ for the same commit. Generate for the artifact you ship, not only the source tree, since base images and runtime layers add components that no lockfile mentions. And keep one SBOM per deployable unit rather than one giant file per repository, so a vulnerability alert maps to a service your team actually owns.
Use-Case Recommendations
The picks below assume you value a defensible choice more than a clever one. Each includes the reason and the main risk.
- Kubernetes platform team with hundreds of images. Use Syft to generate and Grype to match, writing CycloneDX JSON for the security team and an SPDX JSON copy for customers. Risk: pin the release because of the toolchain issue above.
- Startup with one CI system and no security engineer. Use Trivy so a single binary produces the SBOM and the vulnerability report. Risk: you lean on one project for both jobs, so keep the SBOM files in a neutral location you can re-scan with another tool.
- Polyglot monorepo feeding Dependency-Track. Use cdxgen 13.x with
--spec-version 1.7. Its output goes straight to Dependency-Track, and its CBOM work future-proofs the pipeline. Risk: never run server mode on an exposed network, and sandbox any scan of untrusted code. - Embedded product with C and C++ firmware. Trial lynkctl for SPDX 3.0.1 and CycloneDX output without executing the build. Risk: the tool is new and the sources describe it only through its announcement.
- Machine-learning platform shipping models. Trial Pitloom alongside your general generator, and diff the results with SBOMlyze. Risk: SPDX 3 consumers are fewer than SPDX 2.x consumers, so check your buyer can read the file.
- Online business with third-party SDKs. List every embedded SDK with its version, using whichever generator your build already supports. Risk: SDKs delivered as closed binaries may not reveal their own dependencies, so ask the vendor for its SBOM as well.
Teams that sell into regulated markets should add one more step. Ask the customer which fields they expect, then run sbomqs on a sample file to see how it scores. Fixing a missing supplier field before the first audit costs minutes, and fixing it afterward costs a contract renewal conversation.
Migration Guide: Moving Formats and Tools Without Breaking Consumers
Most teams do not start from zero. They inherit a generator, a pile of archived files and a dashboard that expects one format. The steps below move you to a new tool or format while keeping the old pipeline alive until the new one proves itself.
Switching generators in eight steps
- List every consumer of your current SBOMs, including dashboards, auditors and customers, and note the format and version each one reads.
- Pin the new tool to an exact version and record its checksum in your repository.
- Run old and new tools on the same commit using the harness script from the evidence section.
- Diff the package URL lists and review ten disagreements by hand per repository.
- Validate the new files against the schema for the version you emit.
- Feed both outputs to your vulnerability matcher and compare findings, not only components.
- Run both pipelines in parallel for at least one release cycle.
- Cut over, archive the old files with their tool versions, and keep the old pipeline definition in version control for rollback.
# Match vulnerabilities from an existing SBOM instead of re-scanning the image
grype sbom:out/syft.cdx.json
# Push a CycloneDX file to Dependency-Track
curl -X POST "$DT_URL/api/v1/bom" \
-H "X-Api-Key: $DT_KEY" \
-F "autoCreate=true" \
-F "projectName=my-app" \
-F "projectVersion=1.0.0" \
-F "bom=@out/cdxgen.cdx.json"
# Produce a CycloneDX 1.5 file for a consumer that cannot read newer versions
cdxgen -r -o bom.json --spec-version 1.6
cdx-convert -i bom.json -o bom-1.5.json --to 1.5The last pair of commands follows the cdxgen documentation, which says to generate at 1.6 or later and convert down for older readers. Treat any downgrade as a compatibility shim, not a target.
Moving between SPDX and CycloneDX
Generate natively in the target format whenever you can. Converting a finished file is the riskiest path, because the two models do not map one to one. Safeguard’s October 23 guide to mapping SPDX 3.0.1 fields onto CycloneDX 1.7 documents conversion loss, which tells you the problem is real enough to deserve its own article. If you must convert, keep the original file next to the converted one, and record which direction you went.
Moving from SPDX 2.x to 3.0.1 deserves a pilot first. The 3.x model is structured differently, with a graph of elements instead of a flat package list, so scripts that count packages in 2.x JSON will not work unchanged. Update your jq queries, test with one service and confirm every consumer parses the new file before you switch the whole estate. Leave SPDX 3.1 for later, since it is still at the release candidate stage and its first release candidate was described as a testing and validation release.
Teams that track their program through our cybersecurity coverage will find the same pattern elsewhere: change one variable at a time, keep a rollback, and measure before you trust.
Six Mistakes That Make an SBOM Useless
Most failed SBOM programs do not fail on tool choice. They fail on habits. These six show up again and again, and every one is cheap to avoid.
- Trusting one tool’s output as ground truth. Different generators read different evidence, so two correct tools can disagree. Cross-check with the harness before you promise a customer a complete inventory.
- Generating only from source. A source-tree scan misses operating-system packages and base-image layers. If you ship containers, scan the image you ship.
- Dropping the tool version. An archived file without the generator name and version cannot be reproduced or debugged. Store both in the file metadata or the build log.
- Converting formats as an afterthought. Safeguard’s mapping guide documents conversion loss, so a file converted in a hurry before an audit may omit fields the auditor wants. Emit the required format natively.
- Running scanners with too much trust. The October advisories on cdxgen server mode and the Syft toolchain issue show that SBOM tools are attack surface. Run them with least privilege, and keep secrets out of the scan environment.
- Treating the SBOM as a one-time deliverable. Components change with every dependency bump. A file that nobody refreshes becomes a historical document, and historical documents do not help during an incident.
Fix the first two and you remove most of the false confidence. Fix the third and you make every future investigation faster. The remaining three protect you from audits and from the tools themselves.
Pros and Cons of Each Tool
| Tool | Pros | Cons |
|---|---|---|
| Syft | Focused generator, pairs with Grype, active releases through October, wide reach with 50 million combined downloads for Syft and Grype | Release binaries drew a Go toolchain issue on Oct 21, licence and CycloneDX version coverage not confirmed in our sources |
| Trivy | One tool for SBOM and scanning, CycloneDX 1.7 support, new CBOM and Echo-patched package detection in 0.76.0 | SBOM output is a side feature of a scanner, so generator-specific depth may trail a dedicated tool |
| cdxgen | Clear spec targets (1.6, 1.7, 2.0), SPDX 3.0.1 export, Apache-2.0, Dependency-Track fit, broad OS and language evidence | Fast version churn, direct 1.4 and 1.5 output dropped, broad scope means more surface to audit |
| SPDX format | ISO/IEC 5962:2021, wide scope in 3.x, growing tool list | Two active lines (2.x and 3.x), 3.1 still at release-candidate stage |
| CycloneDX format | Security-first design, CBOM support, fast tool adoption of 1.7 | Conversion to SPDX loses information, older consumers may stop at 1.5 |
The pattern is consistent. Tools with the fastest release cadence bring the newest features and the most advisories to read. Tools with the broadest adoption bring the largest pool of examples and answers when something breaks. Weigh which risk your team handles better.
Verdict: A Default Stack and Three Exceptions
For most teams in late October 2026, the best default for a software bill of materials program is a single generator writing CycloneDX 1.7 with an SPDX export path, a quality checker such as sbomqs after generation, and a pinned tool version recorded with every file. Which generator you choose depends on what you build. Container-heavy shops should start with Syft because of its focus and its reach, with 50 million combined Syft and Grype downloads reported by Anchore. Teams that already run Trivy for vulnerabilities should let it write the SBOM too, since one fewer binary means one fewer thing to patch.
Pick cdxgen when your repositories mix many languages, when you feed Dependency-Track, or when cryptographic inventory is on your roadmap. Its 13.5.0 release is the most ambitious of the three, and its documentation is the most explicit about what it emits. Pay for that ambition with discipline: pin versions, skip server mode on shared networks and sandbox untrusted scans.
Three exceptions break the default. Firmware teams should trial lynkctl before forcing a container-first tool onto C and C++ builds. Model-shipping teams should trial Pitloom for SPDX 3 provenance. EU manufacturers should look at DevKit Dossier for record keeping. In every case, run the harness on your own repositories before you commit. The data we could verify says all three major generators are active, maintained and capable. It does not say which one counts your components best, and nobody can say that for you.
Frequently Asked Questions
What is a software bill of materials?
It is a machine-readable inventory of the components inside a piece of software, including libraries, packages and their versions. Security teams use it to find affected products when a vulnerability appears, and buyers use it to check what they are installing.
Should I choose SPDX or CycloneDX?
Choose CycloneDX for security workflows and SPDX when a customer or standard asks for it. SPDX carries the ISO/IEC 5962:2021 designation, while CycloneDX presents itself as a full-stack BOM standard with cryptographic asset support. Syft and cdxgen can write both, so you can serve both audiences.
Which tool is the most accurate, Syft, Trivy or cdxgen?
We found no neutral, repeatable accuracy test comparing the three on identical targets. Run the harness in the evidence section on your own repositories, then review disagreements by hand.
Are these SBOM tools free?
The sources show no list price for Syft, Trivy or cdxgen, and cdxgen lists no paid plans. cdxgen uses the Apache-2.0 licence. Your costs come from CI time, storage and staff time, plus any commercial platform you add.
Can I convert an SPDX file into CycloneDX?
You can, but conversion loses information. Safeguard published a field-by-field mapping from SPDX 3.0.1 to CycloneDX 1.7 that documents the loss. Generate natively in the format you need whenever possible, and keep the original file.
Which CycloneDX version should I emit?
Version 1.7 is the safest forward choice, since Trivy supports it and cdxgen lists it among its targets. If a consumer cannot read 1.7, generate at 1.6 or later and convert down, as the cdxgen documentation advises.
Does cdxgen run the code it scans?
Some package managers run build tooling during dependency resolution. The 13.5.0 release notes list additional safeguards against executing scanned-project code. Even so, scan untrusted repositories inside a sandbox with no secrets and limited network access.
Is SPDX 3.1 final?
Not as of the sources we checked. The project announced the first release candidate on January 26, 2026 and described it as a testing and validation release. For production files today, SPDX 3.0.1 and the 2.x line are the safer targets.
