Comparison
SBOM tools compared
The best SBOM tool depends on the job. Syft, Trivy and cdxgen generate SBOMs by scanning files; Dependency-Track, FOSSA and Anchore manage them; CRACI records the SBOM while your build runs. Here is how twelve tools differ and how to choose.
Updated
The short answer
- Free SBOMs for container images and filesystems: Syft, or Trivy if you also want a vulnerability, secrets and IaC scanner.
- CycloneDX from source code: cdxgen, from the CycloneDX community.
- SPDX for a build output you already package: the Microsoft SBOM Tool.
- Workloads on AWS: the Amazon Inspector SBOM Generator, which feeds Amazon Inspector.
- A quick SBOM of a GitHub repository: GitHub's dependency graph export.
- A free, self-hosted place to monitor SBOMs: OWASP Dependency-Track.
- License compliance first: FOSSA. Supplier and portfolio SBOMs: Manifest or Cybeats. Container fleets and government policy packs: Anchore Enterprise.
- An SBOM of what your own builds actually pulled in, with vulnerability monitoring and provenance data: CRACI, for GitHub Actions.
What an SBOM tool does
A software bill of materials lists the components, libraries and dependencies inside a piece of software, in a machine-readable format such as CycloneDX or SPDX. SBOM tools come in two kinds. Generators write the SBOM. Managers store SBOMs from many products and suppliers, match them against vulnerability data, apply policy and share them. Managers depend on what generators feed them.
When the SBOM is taken matters as much as which tool takes it. CISA's guidance on SBOM types separates a source SBOM, created from the development environment and source files, a build SBOM, generated as part of building the releasable artifact, and an analyzed SBOM, generated by analyzing artifacts such as executables and container images after the build. Most generators below produce source or analyzed SBOMs. CRACI produces a build SBOM. Build-time SBOMs explains the difference in detail.
Who this is for
This page is for teams that need SBOMs, for the Cyber Resilience Act, a customer questionnaire or their own vulnerability work, and are sorting through the options. We build CRACI, so weigh that in. Every claim about another tool comes from its own documentation, and each tool has a longer CRACI vs X page.
How to choose an SBOM tool
- Do you need to produce SBOMs, manage them, or both? A generator gives you a file. A manager gives you a place to keep files from many products and suppliers, enrich them and act on them.
- Is the software yours or bought? For your own builds you control the input, so you can record it. For supplier software you need intake, validation and sometimes binary analysis.
- How sure do you need to be that the list is complete? Generators read files after the fact, and they disagree more than most people expect (see below). A build SBOM describes what the build used.
- Which format do your customers ask for? CycloneDX and SPDX are both widely accepted; most tools write at least one of them.
- Which CI do you run, and must it be self-hosted? Open-source generators run anywhere. CRACI supports GitHub Actions on Linux today, as a managed service, with GitLab CI, Jenkins and customer-hosted runners on the roadmap.
SBOM generators
This compares what each generator does, not how many components it returns.
| Capability | CRACI | Syft | Trivy | cdxgen | Microsoft SBOM Tool | GitHub export | Amazon Inspector Sbomgen |
|---|---|---|---|---|---|---|---|
| Where the component list comes from | Recorded build traffic | Catalogers read files and images | Lock files or installed packages | Source and container images | A build drop folder | Manifests and lock files | Files in images, directories, archives and binaries |
| Formats | CycloneDX, SPDX | CycloneDX, SPDX, Syft JSON | CycloneDX, SPDX | CycloneDX | SPDX | SPDX | CycloneDX |
| Records what the build fetched | Including CI caches | Dependency submission | |||||
| Works without running the build | |||||||
| Signed attestation or provenance | No signed provenance | in-toto SBOM attestation | With Cosign | Not stated | Not stated | Artifact attestations | Not stated |
| Vulnerability matching | Monitored SBOMs | Pair with Grype | Not stated | Not stated | Dependabot alerts | Inspector Scan API | |
| Egress policy for the build | Fails closed | ||||||
| Runs in any CI | GitHub Actions today; GitLab CI and Jenkins on the roadmap | GitHub repositories | Linux only | ||||
| Price | Pay per build minute, no monthly fee | Free, Apache-2.0 | Free, Apache-2.0 | Free, Apache-2.0 | Free, MIT | Included with GitHub | Free download |
- Included
- Partly
- Not included
- On the roadmap
CRACI
CRACI is a recorder rather than a scanner. Your GitHub Actions jobs run on CRACI runners, and a package-aware proxy records what each job fetches, including packages restored from a CI cache. The SBOM, in CycloneDX or SPDX, includes the transitive dependencies the build used and states its completeness per job and per cache. CRACI then keeps re-evaluating monitored SBOMs, so it does the job of a generator and a manager together. Best for software you build in GitHub Actions. Watch out: it cannot scan an image or a directory, and it runs Linux jobs on GitHub Actions today (other CI systems, Windows and macOS are on the roadmap). SBOM generation in CRACI
Syft
Syft is Anchore's free, Apache-2.0 generator for container images and filesystems. It recognizes dozens of package types, writes CycloneDX, SPDX and Syft JSON, and can create signed in-toto SBOM attestations. Grype, its companion, matches the SBOM against vulnerabilities. Best for images and for any pipeline that needs a free generator. Watch out: catalogers are chosen by scan type, so on an installed express checkout one flag decides whether npm packages appear in the result at all. CRACI vs Syft and Grype
Trivy
Trivy, from Aqua Security, is a versatile Apache-2.0 scanner for images, filesystems, repositories, VM images and Kubernetes. It finds vulnerabilities, IaC misconfigurations, secrets and licenses, and writes CycloneDX or SPDX as a side effect. Best for teams that want one free binary for many security checks. Watch out: for a repository it reads lock files, so express 5.2.1 (no lockfile) and claude-code (no manifest) give it nothing to read, exactly as documented. CRACI vs Trivy
cdxgen
cdxgen is an OWASP CycloneDX project that creates CycloneDX BOMs from source and container images, under Apache-2.0. Best for teams standardized on CycloneDX that want a generator from the format's own community. Watch out: like the other scanners, it can only report what the files in front of it declare. CRACI vs a DIY SBOM stack
Microsoft SBOM Tool
The Microsoft SBOM Tool is an MIT-licensed generator that writes SPDX 2.2, or SPDX 3.0 on request, and can validate an SBOM against the SPDX specification. It expects a build drop folder, a package name, a version and a supplier on the command line, which makes it a post-build step, and it runs in GitHub Actions and Azure Pipelines. Best for teams that want SPDX for a build output they already package. Watch out: pointed at repositories as committed, rather than at a build drop, it has almost nothing to describe. Because it takes a supplier on the command line, it can fill the supplier field. CRACI vs a DIY SBOM stack
GitHub dependency graph export
GitHub's dependency graph summarizes a repository's manifest and lock files, plus anything sent through the dependency submission API, and exports as SPDX from the UI or REST API. It feeds Dependabot alerts and is included in every GitHub plan. Best for teams already on GitHub who need a quick SBOM. Watch out: it reflects the default branch rather than a pinned commit, and it is built from what GitHub knows about the repository rather than from files a scanner reads. CRACI vs GitHub Advanced Security
Amazon Inspector SBOM Generator
Sbomgen is the generator behind Amazon Inspector's own image, Lambda and EC2 scanning, offered as a standalone Linux binary. It reads package metadata from container images, directories, archives, mounted volumes and compiled Go and Rust binaries, covers OS packages (APK, DPKG, RPM) and languages including C#, Go, Java, Node.js, PHP, Python, Ruby and Rust, and writes CycloneDX. It can send the SBOM to the Amazon Inspector Scan API for vulnerability findings, which needs an AWS account. Best for teams whose workloads already run on AWS. Watch out: it runs on Linux only, and like the other scanners it finds what the files it reads declare.
Safeguard
Safeguard's CLI runs Syft and Grype to produce CycloneDX and SPDX SBOMs from repositories, container images and uploaded manifests, and its platform adds AI-written fix pull requests and policy gates. Best for teams that want scanning and automated fixes in one subscription. Watch out: like the other scanners, it lists what the files it reads declare. CRACI vs Safeguard
What a scanned SBOM depends on
Point the generators above at the same repository and they return different lists. These are the patterns the tools' own documentation predicts:
- Tools disagree on what counts as a component. Each generator decides for itself which files to trust and how to name what it finds, so one repository gives each of them a different list.
- No lockfile, no dependencies. Express 5.2.1 commits none, so a generator that resolves dependencies from lock files reports none of its npm dependencies and returns whatever else it recognizes.
- No manifest at all. The claude-code repository has no manifest or lockfile, so what each tool returns is assembled from other file types and says more about the tool than about the project.
- Thin metadata. The supplier field often comes out empty, because most generators have no source for it.
None of these tools is broken. Each reads the files in front of it, as designed. The lesson is that a scanned SBOM depends on the tool, its settings and whether anyone installed dependencies first. For what Syft, Trivy and cdxgen each read, see what open source SBOM generators miss.
SBOM managers
| Capability | CRACI | Anchore Enterprise | FOSSA | Cybeats | Manifest | Dependency-Track |
|---|---|---|---|---|---|---|
| Where the SBOM comes from | Recorded during your build | Scans of images, filesystems and source | FOSSA CLI analysis, or imports | Imports; generators via its Marketplace | Scanners (Syft by default) or binary analysis | SBOMs you upload |
| Completeness or quality signal | Per job and cache | Schema validation | Minimum element policies | SBOM Quality Score | Not stated | Not stated |
| Imports supplier SBOMs | Vendor SBOMs can be added | Vendor portal | CycloneDX | |||
| Continuous vulnerability monitoring | ||||||
| VEX | ||||||
| Policy engine or gates | Policy gates, build blocking | Policy packs | Policy-based alerts | Not stated | ||
| License compliance | License policy can block a build | Not stated | Not stated | |||
| Sharing SBOMs with customers | File export | Not stated | SBOM Portal | Not stated | ||
| Runs your build | Egress policy, provenance | |||||
| Self-hosted | Customer-hosted runners | Including air-gapped | Not stated | Not stated | Not stated | |
| Pricing | $0.002 per vCPU-minute ($0.004 for 2 vCPU), metered per second; no monthly fee | Quote | Free plan; Business $20 per project per month | Not stated | Not stated | Free, Apache 2.0 |
- Included
- Partly
- Not included
- On the roadmap
Anchore Enterprise
Anchore Enterprise builds on Syft and Grype and adds what large organizations need: container, source and filesystem SBOMs, imported SBOMs validated for schema correctness, continuous rescanning without the original artifact, and policy packs for FedRAMP, NIST, CIS, PCI DSS and CMMC. It deploys on Kubernetes, Docker Compose or air-gapped. Best for container fleets across several CI systems and for government work. Watch out: its SBOMs still describe what a scanner found, and pricing is by quote. CRACI vs Anchore
FOSSA
FOSSA started with license compliance: full-text license detection, policies and attribution notices. It generates and imports SPDX and CycloneDX SBOMs, can add VDR or VEX statements, checks imports against NTIA and FDA minimum elements, and shares SBOMs through a portal on Enterprise. The Free plan covers 5 projects. Best for teams whose first concern is license risk. Watch out: its CLI queries your build tools when a working build is available and infers from source when not, and binary and snippet scanning are add-ons. CRACI vs FOSSA
Cybeats SBOM Studio
SBOM Studio calls itself "the SBOM system of record." It imports and exports SPDX 2.2 to 3.0.1 and CycloneDX 1.2 to 1.7, scores SBOM quality before import, matches every component continuously, and shares SBOM and VEX data with customers, including over the Transparency Exchange API. Best for product security teams in ICS, medical devices, telecom and automotive running an SBOM program. Watch out: it manages SBOMs rather than producing them, and a quality score confirms format, not what the generator missed. CRACI vs Cybeats and Cybeats alternatives
Manifest
Manifest collects, enriches and shares SBOMs across your products, your vendors and your AI models. Vendors upload through a secure portal, and when they provide none, Manifest can analyze the binary and generate one. It supports SPDX, CycloneDX and VEX and maps to FDA guidance, NIST 800-218 and UNECE R155. Best for organizations whose main exposure is software they buy. Watch out: its GitHub Action generates first-party SBOMs with Syft by default. CRACI vs Manifest
OWASP Dependency-Track
Dependency-Track is an Apache 2.0 platform that tracks components across every version of every application, pulls vulnerability data from sources including NVD and GitHub Advisories, applies security, license and operational policies, and consumes and produces CycloneDX VEX. Pipelines upload SBOMs through its API. Best for teams that want a transparent, self-hosted analysis platform. Watch out: it does not generate SBOMs, and you run it yourself (the API server needs at least 2 GB of RAM and 2 CPU cores). CRACI for Dependency-Track users
CycloneDX or SPDX
Both formats are open standards, and most tools on this page write at least one of them. CycloneDX is an OWASP project, standardized by Ecma International as ECMA-424, and carries vulnerability and VEX data alongside the component list. SPDX is a Linux Foundation project and an international standard, ISO/IEC 5962:2021. The Cyber Resilience Act asks for "a commonly used and machine-readable format" without naming one, so pick the format your customers and downstream tools read.
How CRACI fits
CRACI is neither a scanner nor a manager. It is a recorder. Your GitHub Actions jobs run on CRACI runners (change
runs-on to craci), and a package-aware proxy records what each job fetches from npm, PyPI,
RubyGems, Cargo, Go, Nix, OCI, apt, apk and Git sources, plus download presets. Packages restored from a CI cache carry their
evidence forward. The SBOM, in CycloneDX or SPDX, includes the transitive dependencies the build used, and states its
completeness per job and per cache: Complete, Complete with connections, Incomplete, Unavailable or Not recorded.
CRACI's inventory view shows exactly which software versions are deployed to which products, globally.
After the build, CRACI keeps re-evaluating monitored SBOMs, aggregates vulnerabilities across builds and repositories, supports VEX, returns SBOMs, network traces and provenance through its API, and exports SBOMs as CycloneDX or SPDX files. Vendor SBOMs can be added, so bought-in components are monitored alongside your own builds. It automates a significant part of the software supply chain visibility and evidence that companies need for their wider CRA compliance process. See SBOM generation in CRACI for the full capability.
So CRACI does the job of a generator and a manager together, for the software you build. It is not the right choice when:
- you need SBOMs for images or software you did not build (use a generator such as Syft or Trivy),
- you need a mature policy engine with many rule types across a portfolio of products and suppliers (use a manager),
- your pipelines run outside GitHub Actions, on Windows or macOS, or must be self-hosted (all on CRACI's roadmap).
The quickest way to judge is side by side: book a demo, run one of your workflows on CRACI, and put its SBOM next to the one your current tool produces.
See also SCA tools compared, AI-generated SBOMs vs build-time SBOMs, and why build-time SBOMs differ from scanned ones.
SBOM tools: frequently asked questions
What is an SBOM tool?
An SBOM tool produces or manages a software bill of materials: a machine-readable list of the components, libraries and dependencies inside a piece of software. Generators such as Syft, Trivy and cdxgen write the SBOM by reading files. Managers such as Dependency-Track, FOSSA and Anchore Enterprise store SBOMs, match them against vulnerability data and share them. CRACI records the SBOM during the build itself and monitors it afterwards.
What is the best free SBOM tool?
It depends on what you point it at. Syft and Trivy are free, Apache-2.0 generators for container images and filesystems. cdxgen writes CycloneDX from source and images. The Microsoft SBOM Tool writes SPDX for a build output folder. OWASP Dependency-Track is a free, self-hosted manager for the SBOMs those tools produce.
Should I use Syft or Trivy?
Syft is focused on SBOM generation and pairs with Grype for vulnerability matching. Trivy is a broader scanner that also finds IaC misconfigurations, secrets and licenses, and writes CycloneDX or SPDX along the way. Both read the files in front of them, so both depend on lock files or installed packages being present.
CycloneDX or SPDX: which SBOM format should I use?
Both are open, widely supported standards. CycloneDX is an OWASP project, standardized by Ecma International as ECMA-424, and also carries vulnerability and VEX data. SPDX is a Linux Foundation project and an international standard, ISO/IEC 5962:2021. Use the one your customers and your downstream tools ask for; most generators write both.
Why do SBOM tools give different results for the same project?
Each generator decides which files to trust and what counts as a component. Some read lock files, some read installed packages, some read binaries, and a repository without a lockfile gives a lock file reader nothing to work with. A scanned SBOM depends on the tool, its settings and whether dependencies were installed before the scan. A build-time SBOM avoids that by recording what the build actually fetched.
Does the Cyber Resilience Act require a specific SBOM tool or format?
No. Annex I, Part II of the CRA asks manufacturers to draw up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products. CycloneDX and SPDX both qualify. The regulation does not name a tool.
Can CRACI generate an SBOM for software I did not build?
No. CRACI records the builds that run on its runners, so its SBOMs describe software you build. For software you buy, you can add the vendor's SBOM to CRACI and monitor it alongside your own builds. For a third-party container image you did not build, a scanner such as Syft or Trivy is the practical choice.
Which CI systems does CRACI support?
GitHub Actions today, on Linux x86-64 and ARM64 runners. You change runs-on to craci and the runs still appear in GitHub. Other CI systems, starting with GitLab CI and Jenkins, are on the roadmap.
Put a recorded SBOM next to your current one
Book a demo, run one GitHub Actions workflow on CRACI and compare its SBOM with the one your generator produces today.
Book a demo