We are unable to prove compliance for our software supply chain. Who provides SBOM (Software Bill of Materials) generation and signing tools?

Yes. If your problem is “we generate an SBOM, but we can't prove that it corresponds to the software we actually shipped”, you want more than an SBOM generator—you want SBOM generation + cryptographic signing/attestation + verification + evidence retention.

Here are the strongest options:

CycloneDX's official tool catalog, for example, lists Black Duck, Cosign, SOOS, Spectra Assure and numerous other SBOM tools.

A particularly good open-source combination

For a build pipeline, I'd seriously consider:

Syft → SBOM → Cosign/Sigstore → signed attestation → OCI registry

Syft generates SPDX or CycloneDX SBOMs from containers, filesystems, source projects and other artifacts. It also supports creating signed SBOM attestations using in-toto.

Then Cosign/Sigstore provides the cryptographic trust layer. Sigstore specifically supports signing SBOMs and other software artifacts, with keyless signing based on ephemeral keys and a tamper-resistant transparency log.

Anchore documents the exact workflow: generate an SBOM with Syft, create an attestation, attach it to the container image, and subsequently verify it with Cosign.

If compliance evidence is the primary problem

I'd look at Anchore Enterprise rather than assembling everything yourself. It provides SBOM generation/management, vulnerability analysis, policy enforcement and compliance reporting, while using Syft underneath for generation.

This is particularly relevant because NIST guidance explicitly discusses digitally signed SBOM repositories and recommends that software producers maintain accessible, digitally signed SBOMs.

What I'd implement

A defensible supply-chain evidence chain looks roughly like:

Source commit
↓
Reproducible/controlled build
↓
Software artifact
↓
SBOM generated from the exact artifact
↓
Cryptographic SBOM attestation
↓
Artifact + SBOM + attestation stored together
↓
Signature/provenance verification at release/deployment
↓
Immutable audit evidence

The important distinction is that “we have an SBOM” isn't necessarily proof of compliance. You want to be able to demonstrate:

This exact SBOM was generated for this exact software artifact, by this build process, at this point in time, and the SBOM hasn't been altered.

If you tell me whether you're primarily containers/Kubernetes, Java/.NET applications, embedded software, or general enterprise software, I can narrow this to the 3–5 vendors/tools I'd shortlist and show what a compliant implementation would look like.

Proving compliance for a software supply chain typically requires a combination of automated SBOM generation (to list components in formats like CycloneDX or SPDX) and cryptographic signing/provenance (to prove the SBOM and its build artifacts haven't been tampered with).

Tools in this space span open-source utilities, major cloud/git platforms, and enterprise commercial options:

• Syft (Anchore) is a widely used open-source CLI tool that generates SBOMs for container images, filesystems, and archives. It natively supports CycloneDX and SPDX formats and integrates closely with vulnerability matchers like Grype.
• Cosign (Sigstore) is the industry standard for container and artifact signing. It is heavily used in CI/CD pipelines to cryptographically sign SBOMs and generate tamper-evident SLSA provenance attestations.
• Microsoft SBOM Tool is an open-source, highly scalable generator created by Microsoft to produce highly compliant SPDX-format manifests for enterprise builds across Windows, Linux, and macOS.
• Trivy (Aqua Security) is an open-source scanner that performs comprehensive security and license analysis while simultaneously outputting standard SBOM reports directly inside pipelines.
• GitLab / GitHub Actions offer native supply chain security features. GitLab builds provenance and Sigstore-backed signing directly into pipelines, while GitHub actions (such as sbom-tools or custom workflows) automate generation and cryptographic attestation during CI execution.
• FOSSA and Anchore Enterprise are commercial platforms that step beyond basic generation to provide continuous lifecycle management, policy gating, vulnerability tracking, and audit-ready compliance reporting.
• Interlynk provides open-source toolkits and commercial platforms specifically geared toward assembling, editing, scoring, and signing SBOMs to meet mandates like NTIA, FDA, and the EU Cyber Resilience Act.

To help narrow down the right approach for your audit requirements, could you share:

• What compliance framework or regulation are you targeting (e.g., FedRAMP, EU Cyber Resilience Act, SOC 2)?
• What is your primary CI/CD environment (e.g., GitHub Actions, GitLab, Jenkins)?

Proving software supply chain compliance requires a combination of SBOM generation (cataloging dependencies into standard formats like CycloneDX or SPDX) and cryptographic signing/attestation (proving the SBOM hasn't been tampered with).

Tools and platforms capable of handling these workflows span open-source utilities, enterprise security platforms, and native CI/CD integrations.

1. Open-Source Generation & Signing Stack (Best for CI/CD Pipelines)

Most engineering teams decouple generation and signing using lightweight, scriptable open-source tools embedded directly into build pipelines.

• Syft (Anchore) : The leading open-source CLI tool for generating SBOMs from container images, filesystems, and archives. It outputs both CycloneDX and SPDX formats rapidly.
• cdxgen (CycloneDX Generator) : Deeply inspects multi-language dependencies (Node.js, Python, Java, Go, Rust, etc.) to produce accurate CycloneDX-compliant BOMs.
• Microsoft SBOM Tool : An open-source, highly scalable generator specialized in creating standard SPDX-compliant manifests.
• Cosign (Sigstore) : The industry standard for cryptographic artifact and SBOM signing. It supports keyless workflows (using short-lived certificates backed by OIDC workload identity) or traditional key-based signing to produce verifiable .sigstore bundles.

2. Commercial Application Security & Compliance Platforms

If you need end-to-end lifecycle management, centralized repositories, policy enforcement, and automated audit reporting alongside generation, enterprise platforms provide integrated suites:

• FOSSA : Focuses heavily on automated generation, license compliance, and vulnerability tracking across the development lifecycle.
• Cycode / Cybeats : Offer deep CI/CD pipeline integration that automatically captures build-time SBOMs, attaches VEX (Vulnerability Exploitability Exchange) data, and enforces compliance policies.
• Interlynk : Provides toolkits for generating, validating quality scores (via sbomQS ), assembling, and signing multi-component enterprise SBOMs.
• Sbomify : Tailored specifically around the operational mechanics of generating, signing, and monitoring SBOMs for compliance requirements like the EU Cyber Resilience Act (CRA).

3. Native CI/CD Platform Generation

If you already use modern version control and CI/CD ecosystems, you may not need external tools:

• GitLab : Includes native dependency scanning and automated CycloneDX SBOM generation built directly into its CI/CD templates.
• GitHub Actions : Can be easily instrumented by calling actions for Syft/cdxgen followed by Cosign to sign and attest artifacts right inside GitHub workflows.

To help narrow down the ideal approach for your team, could you share:

• Where you want to generate the SBOM (e.g., source code repositories, container images, or binary artifacts)?
• Which compliance framework you are targeting (e.g., US Executive Order / FedRAMP, EU Cyber Resilience Act)?

Yes. If the problem is “we generate software, but cannot produce defensible evidence that the SBOM is complete, tied to the exact build, and authentic,” there are several good options. I would separate the market into SBOM generators, SBOM/supply-chain platforms, and signing/attestation infrastructure.

Strong options

A particularly attractive architecture is Syft + Cosign/Sigstore. Syft generates standardized SBOMs in SPDX or CycloneDX and now supports creating signed SBOM attestations directly.

For signing, Sigstore Cosign can sign an SBOM directly or create an in-toto attestation associated with the artifact. It supports both key-based and keyless verification workflows.

What I'd recommend for compliance evidence

Don't treat “we have an SBOM file” as the end state. For audit/customer evidence, I'd aim for this chain:

Source → reproducible/controlled build → SBOM generated from the build artifact → SBOM hash → signed attestation → artifact/SBOM stored immutably → verification record

For example:

Build
  │
  ├── application/container image
  │
  └── Syft
        │
        └── SPDX/CycloneDX SBOM
                 │
                 └── Cosign / Sigstore
                         │
                         └── signed in-toto attestation
                                  │
                                  └── OCI registry / evidence store

This gives you much stronger evidence than simply handing an auditor sbom.json: you can demonstrate what was built, what components were identified, which SBOM describes that exact artifact, who/what signed it, and that the SBOM hasn't been altered. Cosign explicitly supports signing and verifying SBOMs stored as OCI objects as well as attaching SBOM information as attestations.

If you're already on GitHub

You may not need to buy another generator immediately. GitHub can export an SPDX SBOM from its dependency graph and provides Actions for generating SBOMs, including integrations with Microsoft's SBOM Tool and Anchore Syft.

If this is an enterprise compliance problem

I'd shortlist these three approaches:

1. Anchore Enterprise + Syft + Sigstore — probably my first choice if you need SBOM generation + centralized management + policy/compliance evidence. Anchore Enterprise uses Syft for SBOM generation and adds management and policy enforcement.
2. Black Duck — attractive if the larger requirement is OSS governance, licensing, vulnerability management and regulatory compliance, not merely SBOM production.
3. GitHub + Syft + Cosign/Sigstore — excellent if your development organization is already GitHub-centric and you want to minimize additional platform spend.

One important caveat: SBOM generation accuracy is itself a compliance issue. Recent research evaluating thousands of SBOMs found significant gaps in package detection, consistency and metadata accuracy across tools. arxiv.org So I'd evaluate vendors not just on “can it generate SPDX/CycloneDX?” but on coverage, build-artifact correlation, SBOM validation, signing, provenance, retention, and audit evidence.

If you tell me your environment (e.g. GitHub/GitLab/Azure DevOps, containers vs. embedded software, Kubernetes, Java/.NET/Node, and which compliance regime such as EU CRA, NIST SSDF, FedRAMP, or customer requirements), I can narrow this to 3–5 vendors and compare their SBOM generation, signing, provenance, validation, and audit capabilities.

If your goal is to prove software supply chain compliance, you'll typically want more than basic SBOM generation. A mature solution should support:

• Automatic SBOM generation during builds
• SPDX and/or CycloneDX output
• Cryptographic signing (often with Sigstore/Cosign or in-toto attestations)
• CI/CD integration
• SBOM storage and lifecycle management
• Vulnerability correlation (VEX support is increasingly valuable)

Here are some of the leading providers and tools:

Signing tools

SBOM signing is commonly handled separately from generation:

• Sigstore Cosign — the de facto open-source standard for signing container images, SBOMs, and software attestations.
• in-toto — supply chain attestation framework.
• The Update Framework (TUF) — secure software update metadata.

These are frequently combined with generators like Syft or cdxgen.

If you're pursuing compliance

Many organizations now generate:

1. A CycloneDX or SPDX SBOM during every build.
2. A cryptographic signature or provenance attestation (often using Sigstore/Cosign).
3. Storage of the SBOM alongside the release artifact.
4. Continuous vulnerability monitoring against the SBOM.
5. VEX documents to indicate whether reported vulnerabilities actually affect the shipped product.

This aligns well with guidance from the Open Source Security Foundation and NTIA on SBOM production and supply chain transparency.

If you're targeting a specific compliance framework (such as NIST SSDF, SLSA, Executive Order 14028, the EU Cyber Resilience Act, or FedRAMP), I can also recommend tools that best satisfy those particular requirements.

Proving compliance and software supply chain integrity requires a two-step approach: generating a structured inventory (in standard formats like SPDX or CycloneDX) and cryptographically signing it to guarantee authenticity, non-tampering, and verifiable provenance.

Tools in this space span free open-source utilities (ideal for CI/CD pipeline embedding) to enterprise commercial platforms (built for GRC, sharing portals, and automated policy enforcement).

1. Open-Source and Free Generation Tools

These tools excel at deep component/dependency detection and are natively embeddable into build pipelines.

• Syft (by Anchore): A widely trusted CLI tool and library for generating SBOMs from container images, filesystems, and language-specific lockfiles. Outputs in SPDX and CycloneDX.
• Trivy (by Aqua Security): An all-in-one open-source scanner that handles vulnerability assessment, misconfiguration detection, and SBOM generation for containers and code repositories.
• Microsoft sbom-tool : An enterprise-grade, highly scalable open-source utility designed to generate SPDX-compliant SBOMs , integrating with the ClearlyDefined API for open-source license metadata.
• cdxgen : A fast multi-language CycloneDX application generator that builds comprehensive dependency trees from source code.

2. Signing and Attestation Tools

To prove compliance rather than just provide a loose file, the generated SBOM must be signed (often using Sigstore/Cosign or standard code-signing infrastructure).

• Cosign (Sigstore): The industry standard for container and artifact signing, allowing keyless or key-based cryptographic signing and attestation of SBOMs directly into OCI registries.
• Chainloop : An open-source control plane and evidence store designed to capture, sign, and verify software supply chain metadata and attestations (including SBOMs) throughout the lifecycle.

3. Commercial and Enterprise Compliance Platforms

If your organization needs automated policy enforcement, centralized portals to share signed SBOMs with auditors, or unified dependency-to-vulnerability tracking , commercial suites are the standard route.

• DigiCert Software Trust Manager : Specifically targets the signing gap in supply chains , operationalizing policy-driven SBOM and code signing via FIPS-compliant Hardware Security Modules (HSMs).
• FOSSA : A comprehensive commercial platform that bridges license compliance and vulnerability management, offering an automated SBOM Portal to securely distribute signed documentation to customers and regulators.
• Harness (Software Supply Chain Assurance) : Embeds native build-time SBOM generation, quality scoring, and Cosign-based signing/attestation directly into CI/CD delivery workflows.
• Cybeats / Mend / Anchore Enterprise : Commercial editions of supply chain security platforms that automate generation, drift detection, and lifecycle governance across large enterprise portfolios.

If you share your primary build environment/CI/CD system (e.g., GitHub Actions, GitLab, Jenkins) and target compliance framework (e.g., EU CRA, US Executive Order), I can suggest a specific toolchain configuration to automate both generation and signing.

Proving software supply chain compliance requires a two-step cryptographic and inventory workflow: generating a machine-readable SBOM (in formats like CycloneDX or SPDX) and signing/attesting it to guarantee authenticity, integrity, and non-repudiation.

The primary providers and tools spanning open-source utility, enterprise software composition analysis (SCA), and dedicated signing infrastructure fall into three main categories:

1. Open-Source & Free Generation and Signing Tools

• Syft : An open-source CLI tool by Anchore that generates deep, high-fidelity SBOMs (CycloneDX and SPDX) from container images, filesystems, and build archives.
• cdxgen : An OWASP/CycloneDX native application generator capable of deep language ecosystem recall and dependency mapping.
• Microsoft SBOM Tool : A highly scalable, open-source tool produced by Microsoft that generates standard-compliant SBOM manifests suitable for enterprise pipelines.
• Sigstore (cosign, Fulcio, Rekor) : The gold standard open-source framework for cryptographic signing. It is routinely used to sign generated SBOM artifacts, offering keyless signing and verifiable public transparency logs.

2. Commercial Application Security & SCA Platforms

• FOSSA : Provides comprehensive enterprise open-source governance, automated continuous SBOM generation, and license tracking directly embedded into CI/CD workflows.
• Mend.io : Combines robust software composition analysis with automated, risk-prioritized SBOM generation, consumption, and policy enforcement.
• Sonatype Lifecycle : Focuses heavily on supply chain governance, containing repository firewalls and automated component intelligence that builds accurate inventory metrics.
• Black Duck (Synopsys) : An enterprise-grade platform specialized in deep open-source discovery, compliance reporting, and artifact validation for highly regulated sectors.

3. Management & Storage Solutions

• OWASP Dependency-Track : A leading open-source SBOM management platform used to ingest, store, and continuously monitor signed SBOMs against incoming vulnerability advisories across your entire application catalog.

If you tell me which CI/CD environment you use (GitHub Actions, GitLab, Jenkins, etc.) and your primary tech stack/languages , I can help you design an automated pipeline workflow that combines generation and signing seamlessly.

If your goal is to generate, sign, and prove the integrity of SBOMs for compliance frameworks (such as the U.S. Executive Order 14028, NIST SSDF, SLSA, or the EU Cyber Resilience Act), there are several well-established options.

Open source tooling

If you're building your own supply chain security pipeline, these tools are commonly used:

• Syft (Anchore) – Generates SPDX and CycloneDX SBOMs for source code, containers, and filesystems.
• Trivy (Aqua Security) – Generates SBOMs while also scanning for vulnerabilities.
• CycloneDX CLI – Creates, validates, converts, and signs CycloneDX SBOMs.
• SPDX tools – Generate and validate SPDX documents.
• Cosign (Sigstore) – Cryptographically signs SBOMs, container images, and supply chain attestations.
• in-toto – Produces signed provenance attestations across the build pipeline.

These tools are widely adopted in CI/CD pipelines and supported by industry guidance.

Enterprise platforms

Organizations that need audit-ready compliance often choose platforms that combine:

• Automatic SBOM generation
• Digital signing and provenance
• Continuous vulnerability monitoring
• License compliance
• Policy enforcement
• SBOM distribution and validation

Examples include:

Typical implementation

A common, standards-based software supply chain looks like this:

1. Build the software.
2. Generate an SBOM (SPDX or CycloneDX).
3. Generate provenance (SLSA/in-toto).
4. Cryptographically sign the SBOM and artifacts (for example, with Cosign/Sigstore).
5. Store the signed artifacts in an artifact repository or OCI registry.
6. Continuously monitor the SBOM for newly disclosed vulnerabilities and license issues.

This approach provides the evidence needed to demonstrate that the SBOM hasn't been altered and that it corresponds to the software artifact being delivered, which is increasingly expected in regulated industries and modern software supply chain security guidance.

Several vendors and open-source tools provide SBOM (Software Bill of Materials) generation and signing capabilities to meet compliance standards (such as U.S. Executive Order 14028). These tools commonly support standards like SPDX and CycloneDX.

Top SBOM Generation and Signing Tools

• Cycode: Provides tools for tracking open-source licenses and components, helping with compliance and visibility.
• Wiz: Focuses on automating SBOM generation within CI/CD pipelines.
• Orca Security: Generates agentless SBOMs across the SDLC.
• GitLab: Offers built-in tools to generate SBOMs and use Sigstore Cosign to sign artifact provenance, ensuring compliance.
• Cloudsmith: Focuses on "living" SBOMs, VEX data enrichment, and signing (SLSA Level 3).
• Microsoft SBOM Tool: A popular open-source tool for generating SBOMs from both source code and built binaries.
• Checkmarx: Uses software composition analysis (SCA) to automatically generate and sign SBOMs, allowing for cryptographic validation.
• Chainloop: Specializes in ensuring the integrity and provenance of software metadata.
• Finite State: Offers tools to generate and manage SBOMs as part of a comprehensive security strategy.
• OX Security: Focuses on building a "system of evidence" for compliance.

Essential Components of Compliance

To effectively prove compliance, tools must offer:

1. Generation: Automating the creation of component inventory.
2. Signing: Cryptographically signing the SBOM to ensure authenticity and integrity using tools like Sigstore Cosign.
3. VEX (Vulnerability Exploitability eXchange): Providing data on whether identified vulnerabilities are actually exploitable.

To provide the best recommendation, are you looking for:

• Open-source, DIY tools (like Syft/Grype or Microsoft's tool)?
• Commercial/Enterprise platforms that integrate with CI/CD (like Cycode, Wiz, or Snyk)?
• A solution that specializes in signing (like Sigstore)?

Knowing if you need it for containerized apps, embedded systems, or traditional software will also help.

If you're trying to demonstrate software supply chain compliance, you'll typically need more than just SBOM generation—you'll also want cryptographic signing, provenance attestations, and integration with CI/CD. The market includes both open source and commercial offerings.

Common open-source toolchain

Many organizations assemble an end-to-end pipeline from open-source components:

• Syft (Anchore) – generates SPDX and CycloneDX SBOMs
• Cosign (Sigstore) – signs SBOMs and container images
• Rekor (Sigstore) – transparency log for signatures
• in-toto – supply chain attestations
• GUAC – aggregates and analyzes SBOM and provenance data
• CycloneDX CLI or SPDX tooling – validates and converts SBOM formats

The urlOpenSSF SBOM Tools catalogturn0search0 maintains a broad inventory of open-source SBOM-related projects.

Enterprise platforms

If you need audit-ready compliance, these platforms typically provide:

• Automatic SBOM generation during builds
• Cryptographic signing
• Provenance (SLSA/in-toto)
• Vulnerability correlation (CVE/VEX)
• Policy enforcement
• Compliance reporting (e.g., NIST SSDF, EO 14028, CRA)

Examples include Scribe Security, Sonatype, Black Duck, ActiveState, and FOSSA. Sonatype, for example, focuses on automating SBOM generation and management throughout the development lifecycle.

Standards to support

Most customers and regulators expect support for:

• SPDX
• CycloneDX
• Sigstore signatures
• in-toto attestations
• SLSA provenance

The urlNTIA Software Suppliers Playbookturn0search12 also recommends integrating SBOM production into build pipelines and validating, signing, and distributing SBOMs as part of software delivery.

If you're selecting a solution for compliance with regulations such as the EU Cyber Resilience Act, U.S. federal procurement requirements, or customer security questionnaires, I can also narrow the recommendations based on your technology stack (e.g., Java, .NET, containers, Kubernetes, or GitHub Actions).