SBOM Signing and Verification: Securing Supply Chain Integrity

SBOM Signing and Verification

A Software Bill of Materials (SBOM) is often treated as a static inventory list—a JSON or SPDX document detailing the components within a binary. However, in a hostile supply chain, the SBOM itself is a target. If an attacker can intercept the build pipeline and swap a legitimate lodash entry for a maliciously crafted one in the SBOM file, the consumer’s vulnerability scanner will report false negatives. The binary contains malware, but the SBOM says it is clean.

SBOM signing solves this by binding a cryptographic signature to the SBOM artifact. This ensures integrity (the file has not changed) and authenticity (the file came from a trusted builder). We achieve this not through traditional PGP keys, but through the Sigstore ecosystem, which leverages short-lived certificates and OIDC identity.

Why Sign the SBOM?

The core mechanism at play here is provenance verification. When you download a container image, you verify its signature against the registry. You assume the SBOM attached to that image is valid because it was generated during the same trusted build. But what if the SBOM is distributed separately? Or what if you need to prove that the SBOM was generated by a specific commit hash?

Without signing, an SBOM is just data. With signing, it becomes an attestation.

The threat model is simple:

1. Tampering: An actor modifies the SBOM to hide vulnerabilities.
2. Substitution: An actor replaces the SBOM with one from a different, potentially malicious build.

Signing prevents both by creating a cryptographic seal. Any change to the SBOM content invalidates the signature.

The Sigstore Stack: Cosign and Keyless Signing

Sigstore is the standard for open-source software transparency. It consists of three main components:

1. Fulcio: A certificate authority that issues short-lived X.509 certificates.
2. Rekor: An immutable transparency log that records signatures.
3. Cosign: The CLI tool used to sign and verify artifacts.

Keyless Signing

Traditional signing requires managing a private key. This is risky: keys can be leaked, stolen, or lost. Sigstore uses Keyless Signing. Instead of a long-lived private key, Cosign requests a short-lived certificate from Fulcio. This certificate is bound to your CI/CD identity (e.g., GitHub Actions OIDC token) via a secure bridge.

The mechanism works as follows:

1. Your CI/CD pipeline obtains an OIDC token from the provider (GitHub, GitLab, etc.).
2. Cosign sends this token to Fulcio.
3. Fulcio validates the token and issues a certificate valid for ~10 minutes.
4. Cosign signs the SBOM with the private key corresponding to that certificate.
5. Cosign uploads the signature (and the certificate bundle) to Rekor.

This means you never handle a persistent private key. The identity is verified at runtime, and the signature is logged immutably.

Attestation: Cosign vs. in-toto

It is crucial to distinguish between signing a file and attesting to a process.

Cosign: Signing the Artifact

Cosign is designed to sign blobs (files). When you run cosign sign-blob, you are cryptographically sealing the SBOM file itself. This proves that this specific file was signed by the identity associated with the certificate.

in-toto: Attesting to the Build Process

in-toto is a framework for supply chain integrity. It allows you to sign metadata about the build process, not just the file. This is done via attestations.

An in-toto attestation includes a predicate that describes what happened. The most common predicate is the SLSA Provenance predicate (https://slsa.dev/provenance/v1), which details:

• The builder ID
• The repository and commit SHA
• The build configuration
• The dependencies used

You can attach an in-toto attestation to a container image or an SBOM using Cosign. This provides a richer context: not only do we know the SBOM is authentic, but we also know exactly how it was generated.

Implementation: Signing an SBOM

Let’s walk through a concrete workflow using GitHub Actions and Cosign.

Step 1: Generate the SBOM

Assume you have a container image myapp:v1.0. Use a tool like syft to generate the SBOM.

# Generate SBOM in SPDX format
syft myapp:v1.0 -o spdx-json > sbom.spdx.json

Step 2: Sign the SBOM with Cosign

Install Cosign and configure it for keyless signing. In a GitHub Actions workflow, you can use the sigstore/cosign-installer action.

- name: Install Cosign
  uses: sigstore/cosign-installer@v3
 
- name: Sign SBOM
  run: |
    cosign sign-blob \
      --yes \
      --output-signature sbom.spdx.json.sig \
      sbom.spdx.json

Mechanism Explanation:

• --yes: Skips the interactive confirmation prompt so the command can run non-interactively in CI.
• --output-signature: Writes the resulting signature to the specified file.

The signer's identity is derived automatically from the GitHub Actions OIDC token at signing time; it is checked later using --certificate-identity-regexp and --certificate-oidc-issuer-regexp during verification, which prevents other repositories from being trusted as the signer.

The result is two files: sbom.spdx.json and sbom.spdx.json.sig.

Advanced: Attaching in-toto Attestations

For higher assurance, you can attach an in-toto attestation. This requires generating a provenance statement first. Tools like slsa-framework/slsa-github-generator can automate this.

Once you have the attestation file (attestation.json), you can attach it to the container image using Cosign:

cosign attach attestation \
  --attestation attestation.json \
  myapp:v1.0

Now, the container image carries the build provenance alongside its SBOM. Consumers can verify the SBOM's signature and then parse the attestation to ensure the SBOM was generated in a secure, isolated environment.

Verification in Practice

Verification is a policy decision. Platforms like GitHub Container Registry or AWS ECR can be configured to reject images or artifacts that do not have valid signatures.

For SBOMs, verification typically happens at the consumer side. Vulnerability scanners like Trivy and Grype can be configured to check the signature of the SBOM before trusting its contents. If the signature is invalid, the scanner should flag the SBOM as untrusted, preventing false negatives.

cosign verify-blob \
  --signature sbom.spdx.json.sig \
  --certificate-identity-regexp="https://github\.com/myorg/myrepo/.+" \
  --certificate-oidc-issuer-regexp="https://token.actions.githubusercontent\.com" \
  sbom.spdx.json

If the SBOM was modified even by one byte, verification fails. If the signature was generated by a different repo, verification fails.

Common Pitfalls

When implementing SBOM signing, several common mistakes can undermine security:

1. Using Long-Lived Keys: Avoid falling back to traditional PGP or SSH keys for signing. Long-lived keys increase the attack surface if compromised and require complex revocation procedures. Stick to Sigstore’s keyless signing model.
2. Ignoring Certificate Expiration: Sigstore certificates are short-lived (typically valid for ~10 minutes). If you attempt to verify an SBOM weeks after it was signed, the certificate will have expired, but verification tools like Cosign rely on the timestamped entry in Rekor to confirm the certificate was valid at the time of signing, rather than its current validity.
3. Failing to Verify Attestation Structure: When using in-toto, simply verifying the signature is not enough. You must also validate the structure of the predicate (e.g., slsa_provenance) to ensure it contains the expected fields like commit SHA and builder ID. Malformed predicates can hide missing provenance details.

Practical Takeaways

Implementing SBOM signing and verification provides critical benefits for supply chain security:

• Integrity: Cryptographic signatures ensure that the SBOM has not been altered since it was generated.
• Authenticity: Keyless signing binds the SBOM to a specific CI/CD identity, proving the source of the artifact.
• Transparency: Logging signatures in Rekor provides an immutable record of all SBOM generations, enabling auditability.
• Provenance: Attaching in-toto attestations adds context about the build environment, allowing consumers to assess the security posture of the generation process.

FAQ

Why use Sigstore for SBOM signing? Sigstore provides a keyless signing experience that eliminates the need to manage long-lived private keys. It leverages existing CI/CD identities (like GitHub Actions OIDC tokens) and provides an immutable transparency log (Rekor) for auditability.

What is the difference between signing and attesting? Signing a file (using Cosign) cryptographically seals the content of the SBOM itself, ensuring it hasn't changed. Attesting (using in-toto) signs metadata about the build process, providing context such as the commit hash, builder ID, and build configuration. You can do both to maximize trust.

How do I verify an SBOM? You can verify an SBOM using the cosign verify-blob command. You need the original SBOM file, the signature file (.sig), and the certificate identity/issuer patterns used during signing. Tools like Grype and Trivy can also automate this verification during vulnerability scanning.

Conclusion

SBOM signing is not optional in a secure supply chain. It transforms the SBOM from a passive document into an active, verifiable artifact. By leveraging Sigstore’s keyless signing and in-toto’s attestation framework, you eliminate the risks of key management while providing cryptographic proof of provenance.

The mechanism is straightforward:

1. Generate the SBOM.
2. Sign it with a short-lived certificate bound to CI/CD identity.
3. Log the signature in Rekor.
4. Verify the signature and attestation at consumption time.

This workflow ensures that the inventory of your software is accurate, authentic, and untampered.