SBOM Tools Compared: Syft vs Trivy vs CycloneDX CLI

by

Why SBOMs Matter: The Regulatory and Security Imperative

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of every component, library, and dependency that makes up a piece of software. Think of it as the nutritional label for your application — except instead of calories and sodium, you’re listing packages, versions, licenses, and provenance data.

SBOMs have moved from a nice-to-have to a regulatory requirement. Two landmark policies are driving adoption across every industry:

Executive Order 14028 (United States)

Signed in May 2021, EO 14028 — “Improving the Nation’s Cybersecurity” — mandates that any software sold to the U.S. federal government must include an SBOM. The order directed NIST to define minimum SBOM elements, which resulted in guidance aligning with the NTIA’s SBOM standards. If your organization sells to government agencies, SBOM generation is no longer optional — it is a procurement prerequisite.

EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act, which entered into force in 2024, requires manufacturers and distributors of products with digital elements to provide SBOMs as part of their conformity assessment. The CRA applies broadly — from IoT devices to enterprise SaaS platforms. With enforcement timelines ramping up through 2026 and 2027, European-market software producers must embed SBOM generation into their build processes now.

Beyond Compliance: Operational Value

Regulatory drivers aside, SBOMs deliver concrete operational benefits:

  • Vulnerability response: When a new CVE drops (like Log4Shell), an SBOM lets you instantly determine which products and deployments are affected.
  • License compliance: SBOMs enumerate licenses across your dependency tree, flagging copyleft or incompatible licenses before they become legal problems.
  • Supply chain transparency: SBOMs create an auditable chain of custody, letting downstream consumers verify exactly what they are running.
  • Incident forensics: During breach investigations, SBOMs accelerate root cause analysis by providing a precise component inventory at the time of build.

The question is no longer whether to generate SBOMs, but which tool to use. In this comparison, we evaluate three leading open-source SBOM generators: Syft, Trivy, and CycloneDX CLI.

Syft: Anchore’s Purpose-Built SBOM Generator

Syft is developed by Anchore and is designed to do one thing exceptionally well: generate accurate, comprehensive SBOMs. It is a dedicated SBOM tool, not a scanner that happens to produce SBOMs as a side effect.

Key Capabilities

  • Output formats: SPDX (JSON, tag-value), CycloneDX (JSON, XML), Syft’s native JSON, and GitHub dependency snapshot format.
  • Source types: Container images (from registries, tarballs, or Docker daemon), filesystems, directories, and archive files (tar, zip, jar, war).
  • Language ecosystems: Excellent coverage — Go, Java (Maven/Gradle), JavaScript (npm/yarn), Python (pip/Poetry/Pipenv), Ruby, Rust, PHP (Composer), .NET (NuGet), C/C++ (Conan), Swift, Dart, Haskell, and more.
  • Package catalogers: Syft uses a modular cataloger architecture. Each ecosystem has its own cataloger that understands native lock files, manifests, and binary artifacts. This produces highly accurate results.
  • Attestation support: Syft integrates tightly with cosign and in-toto attestation frameworks. You can pipe Syft SBOM output directly into cosign attest to produce signed SBOM attestations.

Strengths

Syft’s singular focus on SBOM generation means it has the deepest cataloger coverage of any tool in this comparison. It detects components that other tools miss — especially binary packages compiled into Go and Rust binaries, and nested dependencies inside Java uber-jars. Its output format flexibility is unmatched, and it integrates natively with Anchore’s Grype vulnerability scanner.

Limitations

Syft does not perform vulnerability scanning itself. You need to pair it with Grype or another scanner. This is arguably a strength (Unix philosophy: do one thing well), but it does mean an additional tool in your pipeline.

Example Usage

# Generate CycloneDX SBOM from a container image
syft packages registry.example.com/myapp:latest -o cyclonedx-json > sbom.cdx.json

# Generate SPDX SBOM from a local directory
syft dir:/path/to/source -o spdx-json > sbom.spdx.json

# Attest the SBOM with cosign
cosign attest --predicate sbom.cdx.json --type cyclonedx my-image:latest

Trivy: Aqua Security’s All-in-One Scanner with SBOM Mode

Trivy is developed by Aqua Security and started life as a vulnerability scanner for containers. Over time, it evolved into a comprehensive security tool that also generates SBOMs. Its SBOM capability was added as a scanning mode alongside vulnerability, misconfiguration, secret, and license scanning.

Key Capabilities

  • Output formats: CycloneDX (JSON), SPDX (JSON), Trivy’s native JSON, SARIF, and table/human-readable output.
  • Source types: Container images, filesystems, git repositories, Kubernetes clusters, AWS accounts, and VM images.
  • Language ecosystems: Strong coverage — Go, Java, JavaScript, Python, Ruby, Rust, PHP, .NET, C/C++, Elixir, Dart, Swift, and more.
  • Integrated vulnerability scanning: This is Trivy’s killer feature. Generate an SBOM and scan it for vulnerabilities in a single pass, or scan an existing SBOM file produced by another tool.
  • Attestation support: Trivy can generate and verify in-toto attestations natively via trivy image --format cosign-vuln, and it integrates with cosign for SBOM attestation workflows.

Strengths

Trivy’s biggest advantage is its all-in-one architecture. A single binary handles SBOM generation, vulnerability scanning, misconfiguration detection, secret scanning, and license analysis. This reduces toolchain complexity enormously. It is also the only tool in this comparison that can scan Kubernetes clusters and cloud accounts directly. Its vulnerability database is updated frequently and covers multiple sources (NVD, vendor advisories, GitHub Security Advisories).

Limitations

Because Trivy’s SBOM generation is one feature among many, its cataloger depth can trail Syft in edge cases — particularly for binary analysis of compiled Go/Rust binaries and deeply nested Java artifacts. SPDX support was added later than CycloneDX, so CycloneDX output tends to be more complete in some scenarios. The all-in-one nature also means a larger binary and longer initial database downloads.

Example Usage

# Generate CycloneDX SBOM from a container image
trivy image --format cyclonedx --output sbom.cdx.json registry.example.com/myapp:latest

# Generate SPDX SBOM from a filesystem
trivy fs --format spdx-json --output sbom.spdx.json /path/to/source

# Scan an existing SBOM for vulnerabilities
trivy sbom sbom.cdx.json

# Combined: generate SBOM + scan in one pass
trivy image --format json --list-all-pkgs registry.example.com/myapp:latest

CycloneDX CLI: OWASP’s Native SBOM Toolkit

CycloneDX CLI is part of the OWASP CycloneDX project. Unlike Syft and Trivy, it is not primarily an SBOM generator from source code or container images. Instead, it is a toolkit for manipulating, converting, validating, merging, and diffing CycloneDX SBOMs. The broader CycloneDX ecosystem includes language-specific SBOM generation plugins (e.g., cyclonedx-maven-plugin, cyclonedx-npm, cyclonedx-gomod) that produce SBOMs during the build process itself.

Key Capabilities

  • Output formats: CycloneDX (JSON, XML, Protocol Buffers) — full fidelity. Can convert between CycloneDX versions. Limited SPDX conversion support.
  • SBOM operations: Merge multiple SBOMs into one, diff two SBOMs to see what changed, validate SBOMs against the CycloneDX schema, and convert between CycloneDX formats.
  • Build-time generation: The CycloneDX ecosystem’s language plugins generate SBOMs during the build by reading the dependency resolver directly (Maven, npm, Go modules, pip, etc.), which yields the most accurate dependency graph possible.
  • Attestation support: CycloneDX SBOMs can be wrapped in CycloneDX BOM-Link attestations, and the ecosystem supports VEX (Vulnerability Exploitability eXchange) documents as first-class citizens.

Strengths

The CycloneDX ecosystem’s build-time generation approach produces the most accurate SBOMs because it taps into the build tool’s actual dependency resolution — not a post-hoc filesystem scan. The CLI’s merge capability is invaluable for monorepos and microservice architectures where you need to combine per-service SBOMs into a product-level SBOM. Schema validation ensures SBOMs conform to spec before distribution. VEX support is the most mature in this ecosystem.

Limitations

The CycloneDX approach requires per-language plugin integration into your build system. This is more work than running a single binary against a container image. The CLI itself does not scan containers or filesystems for packages — you need the language plugins for generation. SPDX support is limited compared to Syft and Trivy. The tooling is more fragmented (CLI + multiple plugins) versus a single binary.

Example Usage

# Generate SBOM during Maven build
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom

# Generate SBOM from npm project
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Merge multiple SBOMs
cyclonedx merge --input-files sbom-api.cdx.json sbom-frontend.cdx.json --output-file product-sbom.cdx.json

# Validate an SBOM against the schema
cyclonedx validate --input-file sbom.cdx.json --fail-on-errors

# Diff two SBOMs to see what changed between releases
cyclonedx diff --from v1-sbom.cdx.json --to v2-sbom.cdx.json

Head-to-Head Comparison Table

Feature Syft Trivy CycloneDX CLI + Plugins
Primary purpose SBOM generation All-in-one security scanner SBOM manipulation + build-time generation
SPDX output JSON, tag-value (excellent) JSON (good) Limited conversion only
CycloneDX output JSON, XML (excellent) JSON (excellent) JSON, XML, Protobuf (native, best)
Container scanning Yes (registry, daemon, tarball) Yes (registry, daemon, tarball) No (build-time only)
Filesystem scanning Yes Yes Via language plugins
Binary analysis Strong (Go, Rust binaries) Moderate None
Vulnerability scanning No (use Grype) Yes (built-in) No (use separate tool)
Accuracy (dependency depth) Excellent Very good Best (build-time resolution)
SBOM merge/diff No No Yes (native)
VEX support Via Grype/Vunnel OpenVEX support Native CycloneDX VEX
Attestation signing Via cosign integration Via cosign integration BOM-Link attestation
CI/CD integration GitHub Action, CLI GitHub Action, CLI, Kubernetes operator Build plugin per language
Speed (typical container) Fast (15–30s) Moderate (20–60s with DB download) Fastest (build-integrated, no separate scan)
Kubernetes cluster scan No Yes No

Accuracy and Completeness: Where It Really Matters

SBOM accuracy is the single most important differentiator. An incomplete SBOM is arguably worse than no SBOM — it provides false confidence.

CycloneDX build-time plugins win on accuracy for a clear reason: they hook into the package manager’s resolver during the build. When cyclonedx-maven-plugin runs, it sees the exact same dependency tree that Maven resolved. There is no guessing, no heuristic matching — it reads the resolved graph directly.

Syft comes second. Its cataloger architecture is specifically tuned to parse lock files, manifests, and binary metadata with high fidelity. Syft excels at finding components that other tools miss — particularly Go binaries (which embed module information), Rust binaries, and Java uber-jars with embedded dependencies.

Trivy is very good for most use cases but can miss edge cases in binary analysis. Its strength is breadth — it covers more source types (Kubernetes, cloud) even if per-source depth is slightly less than Syft in some scenarios.

CI/CD Integration: Getting SBOMs Into Your Pipeline

All three tools integrate into CI/CD pipelines, but the integration patterns differ significantly:

Syft in CI/CD

Syft provides an official GitHub Action (anchore/sbom-action) that generates SBOMs and optionally uploads them as GitHub dependency snapshots. For GitLab, Jenkins, or other CI systems, the CLI binary is straightforward to install and invoke. Pair it with the anchore/scan-action (Grype) for vulnerability gates.

Trivy in CI/CD

Trivy offers the broadest CI/CD integration surface: a GitHub Action (aquasecurity/trivy-action), Kubernetes operator (Trivy Operator), and SARIF output for GitHub Code Scanning integration. A single Trivy step can produce an SBOM, scan for vulnerabilities, check for misconfigurations, and detect secrets — replacing three or four separate tools.

CycloneDX in CI/CD

CycloneDX integration requires adding the appropriate language plugin to your build configuration. For Maven, you add the plugin to your POM. For npm, you add a script calling @cyclonedx/cyclonedx-npm. This build-native approach means the SBOM is generated as a build artifact alongside your application, with no separate scanning step needed.

When to Use Which Tool

Choose Syft when:

  • SBOM generation accuracy is your top priority
  • You need maximum output format flexibility (SPDX + CycloneDX)
  • You are scanning container images or pre-built artifacts (not source code)
  • You already use or plan to use Grype for vulnerability scanning
  • You need to analyze compiled binaries (Go, Rust)
  • You want a lightweight, single-purpose tool with minimal dependencies

Choose Trivy when:

  • You want a single tool for SBOM generation and vulnerability scanning
  • You need to scan Kubernetes clusters or cloud accounts
  • Simplicity and reduced toolchain complexity matter more than peak SBOM depth
  • You want built-in misconfiguration and secret detection alongside SBOMs
  • Your team prefers a single, well-maintained tool over assembling multiple components
  • You need SARIF output for GitHub Code Scanning or Azure DevOps integration

Choose CycloneDX CLI + Plugins when:

  • You need the most accurate dependency resolution possible
  • Your organization has standardized on the CycloneDX format
  • You manage monorepos and need to merge per-service SBOMs into product-level SBOMs
  • You need to diff SBOMs between releases to track dependency changes
  • Schema validation of SBOMs before distribution is a requirement
  • VEX document generation is part of your vulnerability disclosure workflow

Combined Pipeline: Using All Three Together

In practice, many mature organizations combine these tools. Here is a pipeline pattern that leverages the strengths of each:

# Stage 1: Build-time SBOM (most accurate dependency graph)
# In your Maven/npm/Go build step:
mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom
# Output: target/bom.json (CycloneDX format)

# Stage 2: Container-level SBOM (catches OS packages + runtime deps)
syft packages myapp:${BUILD_TAG} -o cyclonedx-json > container-sbom.cdx.json

# Stage 3: Merge build-time and container SBOMs
cyclonedx merge \
  --input-files target/bom.json container-sbom.cdx.json \
  --output-file merged-sbom.cdx.json

# Stage 4: Validate the merged SBOM
cyclonedx validate --input-file merged-sbom.cdx.json --fail-on-errors

# Stage 5: Vulnerability scan the merged SBOM
trivy sbom merged-sbom.cdx.json --exit-code 1 --severity CRITICAL,HIGH

# Stage 6: Sign and attest
cosign attest --predicate merged-sbom.cdx.json \
  --type cyclonedx myapp:${BUILD_TAG}

This pipeline achieves the best of all worlds: CycloneDX plugins provide build-time accuracy, Syft adds container-level package discovery, the CycloneDX CLI merges and validates the combined SBOM, Trivy scans for vulnerabilities as a quality gate, and cosign provides cryptographic attestation.

Performance Considerations

Speed matters in CI/CD pipelines where every minute of build time has a cost:

  • Syft is consistently fast. A typical container image scan completes in 15–30 seconds with no external database download required. The binary is lightweight and starts instantly.
  • Trivy requires an initial vulnerability database download (~30–50MB) on first run, which adds 10–30 seconds. Subsequent runs with a cached database are comparable to Syft. Using --skip-db-update in CI (with a pre-warmed cache) eliminates this overhead.
  • CycloneDX plugins add negligible time to builds because they run as part of the existing build process. There is no separate scanning phase — the SBOM is a byproduct of dependency resolution that already happened.

Attestation and Signing: Proving SBOM Provenance

An unsigned SBOM is a trust-me document. For SBOMs to have real value in supply chain security, they must be cryptographically signed and associated with the artifact they describe.

Syft + cosign is the most mature attestation workflow. Anchore has invested heavily in SLSA and in-toto attestation support, and Syft’s output is designed to feed directly into cosign attest.

Trivy supports cosign-based attestation and can verify existing attestations. The trivy image --format cosign-vuln output produces attestation-ready vulnerability reports.

CycloneDX supports BOM-Link, which provides a URI-based linking mechanism between SBOMs and the artifacts they describe. Combined with Sigstore or in-toto, this creates a verifiable chain from source to deployment.

Conclusion

There is no single “best” SBOM tool — the right choice depends on your specific needs. For pure SBOM generation depth, Syft is the gold standard. For all-in-one simplicity, Trivy reduces toolchain complexity dramatically. For build-time accuracy and SBOM lifecycle management, the CycloneDX ecosystem is unmatched.

The strongest approach is to combine them: use CycloneDX plugins at build time for maximum accuracy, Syft for container-level discovery, the CycloneDX CLI for merging and validation, and Trivy for vulnerability scanning. Layer cosign attestation on top, and you have a production-grade SBOM pipeline that satisfies EO 14028, the EU CRA, and your own operational security needs.

Ready to build this pipeline hands-on? Check out our SBOM Lab for a step-by-step walkthrough with real container images and CI/CD templates.