104% more reported CVEs per day in 2026 than last year.

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

Two routes to a monitored SBOM After the build: files such as source, a lockfile or an image are scanned by a generator such as Syft, Trivy or cdxgen, and the SBOM file goes to a manager such as Anchore, FOSSA, Cybeats, Manifest, Lineaje or Dependency-Track, which stores and monitors it. During the build: CRACI records what the build job fetched and produces an SBOM with a completeness state, which it monitors for new vulnerabilities. After the build generate, then manage Files source, lockfile or image Generator Syft, Trivy, cdxgen SBOM file what the scan could see Manager Anchore, FOSSA, Cybeats, Manifest, Lineaje, D-Track During the build record, then monitor build job on CRACI Recorded every package the job fetched SBOM with a completeness state Monitored for new vulnerabilities

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.

CRACI is our product. CRACI cannot be scored the way the others can, because it records builds and cannot scan a directory.
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

The CRACI homepage
craci.com

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

The Syft and Grype homepage
anchore.com

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

The Trivy homepage
trivy.dev

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

The cdxgen homepage
github.com

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 homepage
github.com

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

Pricing as of September 2026.
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

The Anchore homepage
anchore.com

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

The FOSSA homepage
fossa.com

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

The Cybeats homepage
cybeats.com

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

The Manifest Cyber homepage
manifestcyber.com

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

The Dependency-Track homepage
dependencytrack.org

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