Delivering a Software Bill of Materials (SBOM) has moved from an optional security exercise to a contractual and regulatory baseline across government procurement, healthcare, finance, and enterprise software supply chains. Yet teams that treat SBOM generation as a single command run at the end of a release pipeline often discover that their exported JSON files fail compliance audits—missing transitive dependencies, omitting cryptographic hashes, or misidentifying system packages inside container base layers.

Not every SBOM generator inspects software at the same stage of the build lifecycle. A tool that parses source lockfiles captures developer-declared libraries cleanly, while a container-image scanner uncovers compiled binaries and OS packages invisible to source manifests, and a build-system plugin observes exact compiler flags and resolved dependency trees. Selecting the right SBOM generation tool requires aligning its inspection point, format fidelity (CycloneDX versus SPDX), and cryptographic attestation support with how your software is actually assembled and shipped.

Three Points Where SBOM Tools Inspect Your Software

Understanding where a generator extracts component metadata is the single most consequential distinction in the SBOM tooling landscape.

1. Source Manifest and Lockfile Generators

Tools such as CycloneDX ecosystem plugins (cyclonedx-npm, cyclonedx-gomod, cyclonedx-python), cdxgen, and GitHub’s dependency graph exporter read package manifests and resolved lockfiles (package-lock.json, Cargo.lock, go.sum, pom.xml).

• Strength: Captures exact dependency hierarchies (direct versus transitive relationships) and distinguishes runtime dependencies from build-only test tools.
• Limitation: Blind to operating-system packages (apt, apk, rpm), vendored C/C++ shared libraries, and static binaries copied into a final container image during a multi-stage Dockerfile build.

2. Container Image and Filesystem Scanners

CLI scanners such as Syft, Trivy, and Microsoft SBOM Tool inspect built OCI/Docker images, tarballs, and compiled binaries after packaging completes.

• Strength: Inventories everything actually shipped inside the production artifact—including base OS libraries, language runtimes, JARs, wheels, and compiled Go/Rust symbol tables.
• Limitation: Post-build filesystem inspection can struggle to reconstruct full parent-child dependency trees or separate test fixtures from production libraries unless paired with build-time metadata.

3. Build-System and Compiler-Integrated Generators

Native build plugins—such as the CycloneDX Maven/Gradle plugins, Yocto/BitBake SPDX emitters for embedded Linux, and Bazel SBOM rules—run inside the build tool itself while dependencies are resolved and linked.

• Strength: Produces high-fidelity provenance, exact compiler configurations, and accurate license metadata directly from the authoritative build graph.
• Limitation: Language- and build-tool-specific; polyglot organizations must configure and maintain separate plugins across every build system in their stack.

Notable SBOM Generation Tools Across Workflows

Syft (Anchore) — Container and Filesystem Artifact Inventory

Maintained by Anchore as an open-source Go CLI utility, Syft has become a foundational tool for generating SBOMs from container images, OCI archives, directories, and Linux filesystems. It catalogs operating-system packages alongside language ecosystems (Java, JavaScript, Python, Go, Rust, Ruby, .NET, PHP) and exports natively to CycloneDX, SPDX, and Syft’s own detailed JSON schema.

Syft’s core differentiator is container-layer awareness and tight interoperability with Sigstore Cosign—allowing CI pipelines to generate an SBOM and attach it as a signed attestation directly to a container image in an OCI registry. Because Syft inspects built artifacts rather than hooking into compiler execution, teams building complex C/C++ firmware or custom-vendored binaries should verify component detection coverage against their specific build outputs.

OWASP cdxgen — Deep Polyglot and Build-Aware CycloneDX Generation

Maintained under the OWASP Foundation, cdxgen is an open-source, multi-language SBOM generator engineered specifically around the CycloneDX specification. Unlike scanners that rely solely on static file parsing, cdxgen can invoke native package managers and build tools (such as Maven, Gradle, npm, pip, Cargo, and Go) when executed in a build environment to resolve accurate dependency trees, formulation metadata, and machine-learning model components (ML-BOMs).

cdxgen also supports generating Cryptography Bills of Materials (CBOM) and Software-as-a-Service Bills of Materials (SaaSBOM). Its breadth makes it particularly valuable for organizations standardizing on CycloneDX across diverse application stacks, though its comprehensive feature set introduces more configuration options and runtime dependencies than single-binary filesystem scanners.

Trivy (Aqua Security) — Unified SBOM Export and Vulnerability Pipeline

While widely known as an all-in-one vulnerability and misconfiguration scanner, Trivy functions as a fast, single-binary SBOM generator supporting both CycloneDX and SPDX output formats across container images, Git repositories, filesystems, and Kubernetes clusters.

For DevOps teams already running Trivy in CI/CD, generating SBOMs requires no additional tooling—and Trivy can subsequently ingest its own generated SBOMs (or SBOMs produced by Syft) to run offline vulnerability scans. Its trade-off is that SBOM generation is one capability within a broader security scanner rather than a dedicated supply-chain metadata tool with deep compiler-level provenance.

Microsoft SBOM Tool — Enterprise SPDX Generation for Cross-Platform Builds

Originally built to satisfy Microsoft’s internal engineering supply-chain requirements across Windows, Linux, and macOS builds, the open-source Microsoft SBOM Tool (sbom-tool) generates SPDX 2.2 compliant manifests from build drop directories and component detection logs.

It excels in large, mixed-language enterprise build pipelines (especially .NET, C/C++, Node.js, and Python) where teams need deterministic file hashes (SHA-256), package provenance, and automated manifest validation against NTIA minimum elements. Its focus is strictly aligned with SPDX standards rather than CycloneDX, making it less suited for teams whose downstream vulnerability tools require CycloneDX-specific extensions such as VEX or CBOM.

Tern — Deep Layer-by-Layer Container Image Inspection

Hosted under the Linux Foundation, Tern is an open-source inspection tool built specifically to analyze container images layer by layer—reconstructing what packages were installed or modified at each Dockerfile instruction and exporting findings in SPDX, CycloneDX, or human-readable reports.

Tern is especially useful for compliance and legal teams auditing third-party or legacy base container images where the original Dockerfile history is opaque. Because it performs deep container unpacking and shell-command analysis, Tern runs noticeably slower than Go-based scanners like Syft or Trivy, making it better suited for compliance audits than sub-second pull-request checks.

CycloneDX & SPDX Native Ecosystem Plugins (Maven, Gradle, npm, Yocto)

When regulatory audits demand authoritative dependency graphs and exact license expressions, ecosystem-native plugins remain essential:

• CycloneDX Maven and Gradle Plugins hook directly into JVM build lifecycles to record exact resolved artifact coordinates, SHA checksums, and dependency scopes (compile, runtime, test).
• SPDX SBOM Generator (spdx-sbom-generator) and Yocto Project / BitBake SPDX classes serve embedded Linux and C/C++ device manufacturers that must document kernel modules, compiler patches, and cross-compiled system libraries to comply with standards like the EU Cyber Resilience Act and FDA medical device guidance.

Comparison of SBOM Generation Tools

Five Technical Checks to Ensure Your SBOMs Pass Compliance Audits

Generating a valid JSON file is not the same as generating a useful or compliant SBOM. Before standardizing on a generator, verify five technical details against your actual build artifacts:

1. Alignment with NTIA Minimum Elements

Procurement frameworks—including U.S. Executive Order 14028 and regulatory regimes like the EU Cyber Resilience Act—expect SBOMs to include NTIA Minimum Elements: supplier name, component name, version string, unique identifiers (such as Package URLs purl or CPEs), dependency relationships, author of the SBOM data, and timestamp. Verify that your tool populates purl identifiers consistently rather than leaving version or supplier fields blank.

2. Multi-Stage Container Build Blind Spots

If your Dockerfile compiles a Go or Rust binary in a builder stage and copies only the static executable into a distroless or scratch runtime image, a source-level lockfile generator sees the dependencies, while a container scanner may miss stripped symbols unless the binary retains Go build info (go version -m) or Rust cargo-auditable metadata. Test how your chosen generator handles stripped binaries in minimal base images.

3. CycloneDX vs. SPDX Format Interoperability

Both CycloneDX (OWASP/Ecma standard) and SPDX (Linux Foundation / ISO/IEC 5962 standard) are widely accepted, though each has distinct strengths: CycloneDX is heavily favored in application security and CI/CD pipelines for native VEX and cryptography support, whereas SPDX dominates legal license auditing and embedded Linux supply chains. Ensure your generator outputs clean, schema-validated JSON in the format your customers or internal ingestion tools (such as OWASP Dependency-Track) expect.

4. Cryptographic Signing and Registry Attachment

An unsigned SBOM stored in a build log can be altered or separated from the binary it describes. Pair your SBOM generator with signing tools like Sigstore Cosign or in-toto attestations so the SBOM is cryptographically bound to the container image digest in your registry.

5. Automated Schema Validation in CI

Schema drift and malformed fields regularly break downstream SBOM ingestion platforms. Add a validation step—using cyclonedx-cli validate or pyspdxtools—immediately after SBOM generation in CI so broken manifests fail the build before release.

Selecting the Right SBOM Generation Approach

• For cloud-native containerized applications: Combine Syft (or Trivy) in your container build pipeline to capture full OS and application layers, attach the output as a signed Cosign attestation, and ingest it into an SBOM monitoring platform.
• For polyglot application teams needing deep CycloneDX dependency graphs: Run OWASP cdxgen inside your build environment to capture accurate transitive trees, build provenance, and specialized CycloneDX profiles.
• For enterprise .NET, C++, or cross-platform builds requiring strict SPDX manifests: Standardize on Microsoft SBOM Tool alongside automated SPDX schema validation.
• For regulated embedded firmware or complex JVM monoliths: Use build-system-native plugins (Yocto SPDX classes, CycloneDX Maven/Gradle plugins) so compiler-resolved dependencies and license obligations are recorded directly at build time.

Rather than relying on a single scanner across every repository type, run a pilot against your most complex production release—comparing the component count, purl completeness, and transitive tree depth produced by a source-level generator against a post-build container scanner to close blind spots before audit season arrives.

Ethan