Supply Chain Security in 2026: SBOM, Sigstore, and Why Software Provenance Is No Longer Optional

Supply Chain Security in 2026: SBOM, Sigstore, and Why Software Provenance Is No Longer Optional

The SolarWinds compromise of 2020 was a watershed moment that transformed “supply chain security” from an obscure concern into a board-level mandate. Six years later, the tooling has matured enough to make software provenance verification practical at scale. This article covers the three pillars of modern supply chain security: Software Bills of Materials (SBOMs), the Sigstore signing ecosystem, and SLSA framework attestations. Together, they give teams a credible answer to the question: “How do we know this software is what we think it is?”

The Threat Model: What Supply Chain Attacks Actually Look Like

Before diving into tooling, it is worth being precise about the threat. A supply chain attack targets the build and distribution process rather than your running application. The attacker’s goal is to insert malicious code into an artifact that your build system, registry, or package manager will fetch and trust.

Attack vectors include compromised developer accounts (npm token theft), malicious packages with typosquatted names (colourama vs colorama), compromised build systems that inject code during compilation (SolarWinds), malicious maintainer takeovers of popular packages (node-ipc, event-stream), and dependency confusion attacks that exploit the resolution order of private and public registries.

None of these attacks require exploiting a vulnerability in your own code. Your code can be flawless while a library you depend on — or the system that built it — has been compromised. That is what makes supply chain attacks so difficult to defend against with traditional security tooling.

Software Bills of Materials: Knowing What You Ship

A Software Bill of Materials is a machine-readable inventory of every component in a software artifact. Think of it as a nutritional label for software: it tells you what ingredients are present, in what versions, and where they came from.

Two formats dominate in 2026:

• SPDX (Software Package Data Exchange): An ISO standard (ISO/IEC 5962:2021), originally developed by the Linux Foundation. Widely supported by open source tooling and required by many government procurement contracts.
• CycloneDX: Developed by OWASP, explicitly designed with security use cases in mind. Supports vulnerability enrichment, service dependencies, and hardware components in addition to software packages.

Most enterprises generate SBOMs at container image build time. The two most common tools for this are Syft (from Anchore) and Trivy (from Aqua Security).

# Generate a CycloneDX SBOM for a container image using Syft
syft scan ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.json

# Generate an SPDX SBOM
syft scan ghcr.io/myorg/myapp:v1.2.3 -o spdx-json > sbom.spdx.json

# Attach the SBOM to the image in the registry as an OCI referrer
oras attach ghcr.io/myorg/myapp:v1.2.3 \
  --artifact-type application/vnd.cyclonedx+json \
  sbom.json:application/vnd.cyclonedx+json

The oras attach step stores the SBOM in the registry alongside the image using the OCI Referrers API. Any consumer can fetch and verify the SBOM with oras discover before deploying the image. This is the emerging standard for SBOM distribution — keep the SBOM co-located with the artifact it describes, in the same registry, with cryptographic binding via image digest.

SBOM Vulnerability Matching

An SBOM by itself is just an inventory. Its value multiplies when you continuously match it against vulnerability databases. Grype (also from Anchore) and Trivy both support this workflow:

# Match an existing SBOM against Grype's vulnerability database
grype sbom:./sbom.json

# Output as table (default), JSON, or SARIF for GitHub Code Scanning
grype sbom:./sbom.json -o sarif > results.sarif

When integrated into a CI pipeline, this gives you continuous visibility into new CVEs that affect your existing artifacts — even if you haven’t changed any code. A critical vulnerability in a base image layer discovered on Tuesday affects the container you built on Monday, and SBOM-based scanning catches it without requiring a rebuild.

Sigstore: Keyless Code Signing at Scale

Traditional code signing requires managing long-lived private keys — generating them, protecting them in HSMs, distributing public keys to verifiers, and revoking them when compromised. This operational burden is why most open source packages historically shipped unsigned. Sigstore eliminates the key management problem entirely through ephemeral signing keys bound to short-lived OIDC identity tokens.

The Sigstore ecosystem consists of three core components:

Cosign

Cosign is the CLI tool for signing and verifying container images and other OCI artifacts. In keyless mode, it authenticates to an OIDC provider (GitHub Actions, Google, Microsoft, or any OIDC-compatible identity), gets an ephemeral key pair, and immediately submits the signing certificate to Rekor (the transparency log) before signing the artifact.

# Sign a container image in a GitHub Actions workflow (keyless)
- name: Sign container image
  uses: sigstore/cosign-installer@v3
  
- name: Sign
  run: |
    cosign sign --yes \
      ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
  env:
    COSIGN_EXPERIMENTAL: 1

# Verify a signed image — check identity and OIDC issuer
cosign verify \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myapp@sha256:abc123...

The verification step checks that the signature was produced by a GitHub Actions workflow at a specific repository path on a specific branch — not just “some CI system.” That specificity is what makes Sigstore verifications meaningful for supply chain security.

Rekor: The Tamper-Evident Transparency Log

Rekor is an append-only transparency log for software supply chain artifacts, similar in design to Certificate Transparency for TLS certificates. Every Sigstore signing operation appends a log entry to Rekor, and the log is maintained as a Merkle tree. This means:

• Every signature is publicly auditable — you can search Rekor for all signatures ever made for a given artifact digest.
• Entries cannot be deleted or retroactively modified without invalidating all subsequent hashes.
• Verifiers can detect if they are being shown a different view of the log than other verifiers (consistency proofs).

# Search Rekor for all log entries for a specific artifact hash
rekor-cli search --sha sha256:abc123def456...

# Get the full log entry including signing certificate
rekor-cli get --uuid <uuid-from-search> --format json | jq .

Fulcio: The Short-Lived Certificate Authority

Fulcio issues the short-lived X.509 certificates that Cosign uses for ephemeral signing. It validates OIDC identity tokens and embeds the verified identity (GitHub Actions workflow URL, email address, service account) into the certificate’s Subject Alternative Name. These certificates have a 10-minute lifetime — long enough to complete a signing operation, short enough that a leaked certificate is useless before it expires.

SLSA: The Supply Chain Levels for Software Artifacts Framework

SLSA (pronounced “salsa”) is a framework of security requirements designed to prevent tampering across the full software supply chain — from source code through the build system to the distribution artifact. It was developed at Google and is now a CNCF project. SLSA defines four levels of increasing rigor:

• SLSA 1: Build process is documented and scripted. Provenance (metadata about how an artifact was built) is generated, even if not authenticated.
• SLSA 2: Build uses a version-controlled build service. Provenance is authenticated by the build service.
• SLSA 3: Build runs on a hardened, isolated build environment. Provenance is non-forgeable by the build service itself.
• SLSA 4: Two-person review required for all code changes. Hermetic, reproducible builds. The highest assurance level, currently requiring custom build infrastructure.

GitHub Actions, Google Cloud Build, and Tekton Chains all support generating SLSA-compliant provenance attestations out of the box at levels 1-3.

# GitHub Actions: generate SLSA 3 provenance for a container image
jobs:
  build:
    uses: slsa-framework/slsa-github-generator/.github/workflows/container_workflow.yml@v2.0.0
    with:
      image: ghcr.io/myorg/myapp
      digest: ${{ needs.release.outputs.digest }}
    secrets:
      registry-username: ${{ github.actor }}
      registry-password: ${{ secrets.GITHUB_TOKEN }}

The reusable workflow generates a signed provenance attestation and attaches it to the image in the registry. The attestation is a JSON document (following the in-toto Attestation Framework format) that records the builder identity, the source repository, the git commit hash, and the build parameters.

Putting It Together: A Practical Supply Chain Security Pipeline

A complete supply chain security pipeline in 2026 combines all three elements. Here is the sequence for a production container image build:

1. Build: Compile the application in an isolated, ephemeral build environment (GitHub-hosted runner or a dedicated build cluster with network egress restrictions).
2. Generate SBOM: Run Syft against the output image to produce a CycloneDX SBOM.
3. Scan SBOM: Run Grype against the SBOM to check for known vulnerabilities. Fail the build on critical CVEs.
4. Sign image: Use Cosign in keyless mode to sign the image digest. The signing certificate is bound to the GitHub Actions workflow identity.
5. Attach SBOM: Attach the SBOM to the image in the registry as an OCI referrer, signing the attachment with Cosign as well.
6. Generate provenance: Use the SLSA GitHub Actions generator to produce a signed provenance attestation at SLSA 3.
7. Verify at deploy time: Admission webhooks (using Policy Controller from Sigstore or Kyverno) verify the signature, validate the SBOM is present, and check that provenance meets SLSA 2+ before allowing a pod to schedule.

# Kyverno policy: require Sigstore signature before deployment
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-signature
    match:
      any:
      - resources:
          kinds: [Pod]
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/myorg/*/.github/workflows/*.yml@refs/heads/main"
            issuer: "https://token.actions.githubusercontent.com"
            rekor:
              url: https://rekor.sigstore.dev

VEX: Communicating Vulnerability Exploitability

One practical challenge with SBOM-based vulnerability scanning is alert fatigue. An SBOM for a typical container image might match 50-200 CVEs, the vast majority of which are either not exploitable in your context (the vulnerable code path is never reached) or already mitigated (the vulnerable component is present but the package is not the affected version in practice).

VEX (Vulnerability Exploitability eXchange) documents let maintainers communicate exploitability status for specific CVEs against specific versions of their artifacts. A VEX statement can assert that a CVE is “not affected” (with a justification like “vulnerable code not in execution path”), “affected,” “fixed,” or “under investigation.” Both CycloneDX and SPDX support embedding VEX statements, and OpenVEX is an emerging standalone format.

# Generate a VEX document with vexctl
vexctl create \
  --product "pkg:oci/myapp@sha256:abc123" \
  --vuln CVE-2024-12345 \
  --status not_affected \
  --justification "vulnerable_code_not_in_execute_path" \
  > myapp.vex.json

Scanners like Grype can consume VEX documents to filter their output, dramatically reducing alert noise without hiding genuine risks.

Compliance and Regulatory Context

For teams working on US federal contracts, NIST SP 800-204D and Executive Order 14028 require SBOM generation for software supplied to federal agencies. CISA has published minimum SBOM element requirements (supplier name, component name, version, component hash, dependency relationships, SBOM author, and timestamp).

The EU Cyber Resilience Act, coming into effect through 2026-2027, imposes similar requirements on products with digital elements sold in the EU. Supply chain security tooling that meets SLSA 2+ and generates SPDX or CycloneDX SBOMs satisfies the technical documentation requirements in both regulatory frameworks.

Conclusion

Supply chain security is no longer a niche concern for government contractors. The combination of SBOM generation, Sigstore keyless signing, and SLSA provenance attestations gives every engineering team the tools to answer the question “how do we know this software is what we think it is?” — without the operational burden of managing signing keys or building custom tooling. Start by generating SBOMs as part of your image build pipeline, add Cosign signing with the GitHub Actions OIDC integration, and progressively enforce verification at deploy time through admission policies. The ecosystem is mature enough to do all of this in a standard CI/CD pipeline today.