DevSecOps 2.0: Integrating SBOMs with Sigstore [Deep Dive]

Prerequisites

In 2026, the definition of 'secure code' has evolved. It is no longer enough to scan for vulnerabilities; you must provide proof of provenance and a verifiable manifest for every artifact you ship. This is the era of DevSecOps 2.0, where the Software Bill of Materials (SBOM) is as critical as the binary itself. By leveraging Sigstore, we can sign these manifests and artifacts without the headache of manual PGP key management.

Understanding the SBOM Revolution

An SBOM is essentially a formal record containing the details and supply chain relationships of various components used in building software. In 2026, regulatory frameworks like SLSA (Supply-chain Levels for Software Artifacts) have made SBOM generation a mandatory step for enterprise-grade security. Before we dive into the automation, remember that transparency is key. However, ensure that your SBOM doesn't accidentally leak internal secrets. If you are processing data within your applications, consider using a Data Masking Tool to protect sensitive information before it reaches your logs or metadata.

Step 1: Generating SBOMs with Syft

To generate an SBOM, we use Syft, a powerful tool from Anchore. It scans your container images and generates a detailed inventory in various formats like CycloneDX or SPDX.

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate an SBOM for a Docker image
syft your-image-name:latest -o cyclonedx-json > sbom.json

This sbom.json file now contains every package, library, and version used in your image. This is the 'Source of Truth' for your deployment.

Step 2: Signing Artifacts with Sigstore

Now that we have our SBOM and our container image, we need to sign them. Cosign, part of the Sigstore project, makes this incredibly simple. In 2026, the standard is 'Keyless Signing', which uses OIDC identities (like your GitHub login) instead of long-lived private keys.

# Install Cosign
LATESTVERSION=$(curl -L -s -H "Accept: application/json" https://github.com/sigstore/cosign/releases/latest | jq -r .tagname)
sudo install "cosign-linux-amd64" /usr/local/bin/cosign

# Sign the image (Keyless mode)
cosign sign your-image-name:latest

When you run cosign sign, it will open a browser window for you to authenticate via GitHub, Google, or Microsoft. A short-lived certificate is issued by Fulcio and recorded in Rekor.

Step 3: Automating with GitHub Actions

The real power of DevSecOps 2.0 is automation. We want every commit to generate an SBOM and sign both the image and the SBOM automatically. Add the following to your .github/workflows/security.yml:

name: Secure Supply Chain

on:
  push:
    branches: [ main ]

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write # Required for Keyless signing

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build Image
        run: docker build -t ghcr.io/${{ github.repository }}:latest .

      - name: Install Tools
        uses: sigstore/cosign-installer@v3.4.0

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          image: ghcr.io/${{ github.repository }}:latest
          format: cyclonedx-json
          output-file: sbom.json

      - name: Sign Image
        run: |
          cosign sign --yes ghcr.io/${{ github.repository }}:latest

      - name: Attest SBOM
        run: |
          cosign attest --yes --type cyclonedx --predicate sbom.json ghcr.io/${{ github.repository }}:latest

Verification and Expected Output

Once the pipeline completes, you can verify the integrity of your image from any terminal. This ensures that the image running in production is exactly what was built and signed in CI.

# Verify the signature
cosign verify ghcr.io/user/repo:latest --certificate-identity-regexp "https://github.com/user/repo/.*" --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

# Verify the SBOM attestation
cosign verify-attestation --type cyclonedx ghcr.io/user/repo:latest

Expected Output: You should see a JSON output confirming that the signatures are valid and the Rekor log entry exists. If the verification fails, it means the image has been tampered with since it was built.

Troubleshooting Top-3

1. OIDC Token Errors: Ensure permissions: id-token: write is set in your GitHub Action. Without this, Cosign cannot request the identity token for keyless signing.
2. Registry Compatibility: Not all OCI registries support Cosign signatures stored as tags. Ensure you are using GHCR, ACR, ECR, or GCR.
3. Large SBOM Processing: If your image is massive (multi-GB), Syft might time out. Increase the timeout in your GitHub Actions step or exclude non-critical paths using .syftignore.

What's Next

Integrating SBOMs and Sigstore is just the beginning. The next step in DevSecOps 2.0 is implementing Admission Controllers in Kubernetes, such as Kyverno or Policy Agent, to block any container image that doesn't have a valid signature and SBOM attestation. Stay tuned for our next deep-dive on Zero-Trust Kubernetes Admission.