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

Proving software supply chain compliance requires a two-step cryptographic and inventory workflow: generating a precise Software Bill of Materials (SBOM) in standards like CycloneDX or SPDX, and signing it (along with build provenance) using cryptographic keys to ensure it hasn’t been tampered with.

Tools in this space generally span open-source utilities (ideal for CI/CD embedding) and commercial enterprise platforms (built for centralized policy and reporting).

Open-Source & Developer-First Tools (Generation + Signing)

These tools integrate directly into pipelines like GitHub Actions or GitLab and can be paired with cryptographic signing utilities.

• Syft (by Anchore): Widely considered the leading open-source CLI tool for generating SBOMs from container images and filesystems, exporting to SPDX and CycloneDX. Pair it with Grype for vulnerability matching.
• Trivy (by Aqua Security): An all-in-one open-source security scanner that handles vulnerability management, misconfiguration detection, and native SBOM generation.
• cdxgen (OWASP): The official CycloneDX generator, excellent at deeply parsing application dependencies across multiple languages (Node.js, Java, Python, Go, etc.).
• Cosign (by Sigstore / Linux Foundation): The industry standard for signing container images, blobs, and SBOMs, supporting keyless signing via OIDC identities and immutable transparency logs (Rekor).

Commercial & Enterprise Platforms (End-to-End Compliance)

If you need automated policy enforcement, continuous tracking, vendor management, and unified compliance dashboards, commercial Software Composition Analysis (SCA) vendors handle generation, ingestion, and lifecycle management.

• FOSSA : A robust commercial SCA platform specializing in automated license compliance, vulnerability management, and reliable SBOM export/generation across numerous build systems.
• Anchore Enterprise : Extends the capabilities of open-source Syft into an enterprise-ready platform providing centralized SBOM management, policy enforcement, and continuous compliance checks.
• Endor Labs : Combines high-accuracy dependency analysis and SBOM generation with reachability analysis to focus security compliance on code actually executing in production.
• Microsoft SBOM Tool : An enterprise-grade, highly scalable generator built by Microsoft to handle complex multi-platform enterprise build pipelines.

Managing and Storing SBOMs

Once generated and signed, organizations typically ingest them into a centralized registry or tracking system:

• OWASP Dependency-Track : A dedicated, open-source component analysis platform that ingests thousands of SBOMs to provide real-time, continuous global risk and N-day vulnerability tracking.

If you'd like, tell me:

• What CI/CD pipeline (GitHub Actions, GitLab, Jenkins) you use
• Which languages or packaging ecosystems (npm, Maven, Go, containers) make up your core stack

I can recommend a specific implementation pipeline combining generation and signing tools for your stack.

Yes. There are several credible options, but it helps to distinguish SBOM generation from cryptographic signing/attestation and from SBOM governance/evidence management.

My shortlist

1. Anchore + Syft + Cosign/Sigstore — strong open-source approach

anchore.com can generate SBOMs from container images, source projects, filesystems and archives, with SPDX and CycloneDX output. Anchore also documents generating cryptographically signed SBOM attestations using in-toto and Sigstore.

For signing, Sigstore's Cosign is particularly compelling. It supports keyless signing using short-lived certificates and records signing events in the Rekor transparency log. It can sign SBOMs as well as containers and other artifacts.

2. Anchore Enterprise — if you need centralized compliance evidence

Anchore Enterprise builds on Syft and provides centralized SBOM generation/management, vulnerability analysis and compliance enforcement. It can generate SBOMs locally in CI or centrally, which can be useful when auditors need evidence across many products/releases.

3. Cybeats SBOM Studio — if your primary problem is proving compliance

cybeats.com is more of an SBOM system of record than merely a generator. It stores, enriches, versions, monitors and shares SBOMs, with support for SPDX and CycloneDX. That's useful if the question from an auditor is not merely "can you generate an SBOM?" but "show me the SBOM for this exact release, who generated it, whether it was validated, and the evidence that it hasn't been altered."

What I'd implement

If your goal is specifically "prove software supply-chain compliance", I would not buy an SBOM generator alone. I'd establish a chain like:

Build → SBOM → provenance/attestation → cryptographic signature → transparency/evidence → verification

For example:

Syft → CycloneDX/SPDX SBOM → in-toto/SLSA provenance → Cosign/Sigstore signing → Rekor → archive evidence with the release

Sigstore is designed specifically for this type of workflow: its tooling can sign and verify SBOMs and other artifacts, while its transparency log provides independently auditable evidence of signing events.

The important distinction is that an SBOM by itself doesn't prove that the SBOM actually corresponds to the software you shipped. A signed SBOM/attestation tied to a specific immutable artifact digest provides substantially stronger evidence.

If you tell me whether you're primarily trying to satisfy FDA/medical-device, EU CRA, NIST/SLSA, FedRAMP, or customer/audit requirements, I can narrow this to the 3–5 vendors that best fit that compliance target.

Proving compliance for a software supply chain typically requires a two-step workflow: generating a machine-readable inventory of your software dependencies (the SBOM) and signing it cryptographically to prove its integrity and provenance.

Vendors and tools that handle SBOM generation and artifact signing span open-source CLI utilities, enterprise developer platforms, and specialized security suites.

1. Open-Source & Developer-First Tools (Generation + Signing)

If you prefer lightweight, CI/CD-integrated toolchains, you can pair a generation tool with a signing utility like Sigstore Cosign.

• Syft (by Anchore) : A widely used CLI tool and library for generating SBOMs from container images and filesystems (supports SPDX and CycloneDX formats).
• Trivy (by Aqua Security) : Combines vulnerability scanning with robust SBOM generation and analysis for containers and filesystems.
• Microsoft SBOM Tool : An open-source, highly scalable enterprise generator designed to produce standard-compliant SBOMs during builds.
• CDXGen (OWASP) : An official OWASP application-generation tool optimized for creating CycloneDX SBOMs across various programming languages.
• Cosign (by Sigstore / CNCF) : The industry standard for container and artifact signing. It allows you to generate cryptographic signatures and attach/attest SBOMs directly to your container registries or file storage.

2. Enterprise Security Platforms & Commercial Solutions

If your organization needs a centralized dashboard, compliance policy enforcement, automated key management, and integrated lifecycle reporting, commercial vendors provide unified ecosystems:

• Snyk : Offers comprehensive software composition analysis (SCA) that natively generates license-aware SBOMs alongside vulnerability management across your repositories and CI/CD pipelines.
• DigiCert Software Trust Manager : A dedicated enterprise platform that consolidates vulnerability scanning, native SBOM management, and high-assurance code/artifact signing into a single centralized policy engine.
• JFrog : Integrates advanced binary repository management with automated Xray scanning, allowing teams to generate, manage, and track SBOMs directly from their artifact repository.
• Wiz / Anchore Enterprise : Act as centralized orchestration layers that ingest, scan, prioritize, and report on compliance postures and SBOM data across multi-cloud environments.

To help narrow down the best fit, could you share:

• Are you integrating this into a CI/CD pipeline (like GitHub Actions, GitLab) or looking for a stand-alone enterprise platform?
• Do you primarily deploy containers, standard binaries/files, or application source code?

Yes. There are several credible options, and the right choice depends on whether you need SBOM generation only, cryptographic signing/attestation, or an end-to-end compliance platform.

Strong options

The CycloneDX ecosystem currently lists hundreds of SBOM-related tools, including Syft, Cosign, Valint, Cybeats, Checkmarx, Sonatype and others.

My recommendation for proving compliance

If your problem is specifically “we can't prove that our SBOM corresponds to the software we actually shipped,” I'd prioritize a workflow like:

Build → Generate SBOM → Cryptographically attest/sign SBOM → Sign artifact → Store evidence → Verify at deployment

A particularly clean implementation is Anchore Syft + Sigstore Cosign. Syft generates SPDX or CycloneDX SBOMs and can now create signed SBOM attestations using in-toto/Sigstore. Anchore Open Source Anchore Cosign provides the signing and verification infrastructure for artifacts and SBOMs in OCI registries.

For an organization that needs audit dashboards, policy enforcement, evidence collection, and supplier/third-party SBOM management, I'd look more closely at Anchore Enterprise, Scribe Security, Manifest Cyber, or Cybeats rather than assembling everything yourself.

One important distinction: an unsigned SBOM is an inventory; a signed/attested SBOM provides evidence of provenance and integrity. If your compliance gap is about proving what went into a release, you generally want the latter.

If you tell me your environment (e.g. GitHub/GitLab/Jenkins, Kubernetes, containers, Java/.NET/Node/Python, and which compliance framework—NIST SSDF, SLSA, FDA, EO 14028, EU CRA, etc.), I can narrow this to 3 vendors and show exactly how each would close the compliance gap.

Proving compliance for your software supply chain requires a two-step technical pipeline: generation (creating the machine-readable component manifest in formats like CycloneDX or SPDX) and signing/attestation (cryptographically signing that manifest to prove tamper resistance).

The toolsets and providers for this workflow span open-source utilities and commercial platforms:

1. SBOM Generation Tools

• Syft (by Anchore): One of the fastest and most popular open-source generators. It scans container images, filesystems, and archives to output CycloneDX or SPDX formats.
• Microsoft SBOM Tool: An enterprise-proven, open-source tool that auto-detects dependencies across various ecosystems (NPM, NuGet, Maven, Go, etc.) and generates SPDX-compliant manifests.
• Trivy (by Aqua Security): Combines fast SBOM generation with built-in vulnerability and configuration scanning.
• Cdxgen: A deeply multi-language native generator optimized specifically for CycloneDX output.
• Commercial SCA Platforms: Enterprise security suites like FOSSA, Snyk, Sonatype (SBOM Manager) , and Checkmarx automatically generate, ingest, and monitor SBOMs natively within your CI/CD pipelines.

2. SBOM Signing & Attestation Tools

Once an SBOM file is generated, it must be signed to establish integrity and provenance:

• Cosign (by Sigstore): The industry standard for container and artifact signing. It supports keyless signing (using short-lived certificates tied to OIDC identities like GitHub Actions) as well as traditional key-based signing to attach verifiable signatures to SBOM files.
• in-toto / SLSA Framework: Used to create complete supply chain metadata and attestations, which tools like Syft can natively integrate with to attest that the SBOM matches the build environment.
• Enterprise Certificate Authorities: Specialized trust providers like eMudhra (CertiNext) offer specialized signing certificates tightly integrated with code-signing pipelines so software and its bill of materials travel as a unified verifiable artifact.
• CI/CD Native Signing: Platforms like GitLab and GitHub Actions feature native extensions or integrated actions to generate and sign artifacts out of the box during release workflows.

If you share your primary CI/CD environment (e.g., GitHub Actions, GitLab, Jenkins) and primary programming languages/artifacts , I can outline a step-by-step pipeline configuration for automated generation and signing.

Yes. If your goal is provable software-supply-chain compliance, I’d separate the market into SBOM generators, signing/attestation tools, and enterprise platforms that manage the evidence.

My strongest recommendation: Anchore + Syft + Cosign

Anchore Syft is particularly compelling because Syft generates SBOMs from source directories, container images, filesystems and archives, and supports SPDX and CycloneDX. It can also generate signed SBOM attestations.

For the signing layer, Sigstore Cosign provides cryptographic signing and verification. Syft's current attestation workflow can use Sigstore and OIDC for keyless signing, with the attestation attached to the OCI image.

That gives you a fairly clean evidence chain:

Source → Build → SBOM → Sign/Attest → Registry → Verify

For example:

Application / container
        ↓
      Syft
        ↓
  SPDX / CycloneDX SBOM
        ↓
  Sigstore / Cosign
        ↓
Signed SBOM attestation
        ↓
 OCI registry alongside artifact
        ↓
Customer / auditor verifies signature

This distinction matters: an SBOM by itself doesn't prove that the SBOM is trustworthy or corresponds to the artifact you're delivering. CISA specifically recommends validating SBOMs and signing them to provide integrity and attestation.

If your problem is specifically "we can't prove compliance"

I'd look beyond simply buying an SBOM generator. You want these capabilities:

1. Automatic SBOM generation at build time
2. SPDX and/or CycloneDX output
3. Cryptographic signing/attestation
4. Artifact-to-SBOM binding — e.g. attestation attached to the OCI artifact
5. Build provenance — ideally SLSA/in-toto-compatible
6. Immutable audit trail
7. SBOM retention and version history
8. Policy enforcement — fail builds for prohibited licenses/vulnerabilities/components
9. Verification capability for customers/auditors
10. Compliance reporting/evidence export

For an enterprise that needs all of that rather than just a CLI, Anchore Enterprise is worth evaluating; it builds on Syft and adds policy enforcement, compliance reporting and centralized supply-chain security.

ActiveState is another interesting option if your primary requirement is audit-ready evidence: its platform advertises automatically generated, cryptographically signed SBOMs, dependency trees, licensing metadata and build provenance.

If you tell me your environment (GitHub/GitLab/Azure DevOps/Jenkins, languages, containers vs. binaries, and which compliance regime—e.g. NIST, EO 14028, SOC 2, FedRAMP, EU CRA), I can narrow this to 3–5 vendors and show exactly how they would close the compliance-evidence gap.

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.