DEV Community

Cover image for Supply Chain Security 2026: SBOM, Sigstore/SLSA, and Admission Control as DevOps Standard
saaro
saaro

Posted on Originally published at blog.saaro.net

Supply Chain Security 2026: SBOM, Sigstore/SLSA, and Admission Control as DevOps Standard

#devops #supplychainsecurity #sigstore #slsa

Software supply chain attacks are estimated to cost the global economy 80.6 billion US dollars in 2026 – an increase of 76 percent compared to 2023. The Jaguar Land Rover attack alone in August 2025 caused 1.9 billion pounds in damage and halted production for five weeks. Attacks on container images, CI/CD pipelines, and build systems are no longer future scenarios but the new reality for DevOps teams. With the first EU Cyber Resilience Act (CRA) reporting obligations taking effect in September 2026, supply chain security is shifting from nice-to-have to regulatory requirement.

SBOM: The Digital Table of Contents for Software

A Software Bill of Materials (SBOM) is the foundation of any supply chain security. It lists all components, libraries, and dependencies of an application – similar to the ingredient list on food products. The EU CRA mandates, starting September 2026, an SBOM in machine-readable format for products with digital elements, capturing at least the most important dependencies.

The two dominant SBOM formats are CycloneDX and SPDX. For containerized applications, CycloneDX has established itself as the de facto standard since it is specifically designed for container environments. In the CI/CD pipeline, the open-source tool Syft can generate SBOMs automatically:

syft ghcr.io/myorg/myapp:v1.2.3 -o cyclonedx-json > sbom.cyclonedx.json
Enter fullscreen mode Exit fullscreen mode

An SBOM alone, however, does not protect against attacks – it only documents the attack surface. Actual security is achieved through signing, verifying, and enforcing policies.

Sigstore: Keyless Signing for Container Images

Sigstore is an open-source project by the Linux Foundation that enables cryptographic signing without managing your own GPG keys or PKI infrastructure. The underlying tool Cosign uses OIDC tokens from CI platforms such as GitHub Actions or GitLab CI as identity – so-called keyless signing.

The practical application is remarkably simple:

cosign sign --yes ghcr.io/myorg/myapp:v1.2.3
Enter fullscreen mode Exit fullscreen mode

For verification, this suffices:

cosign verify \
  --certificate-identity=ci@myorg.com \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/myorg/myapp:v1.2.3
Enter fullscreen mode Exit fullscreen mode

Since the identity comes directly from the CI context, the problem of key management is eliminated. No secrets that can be rotated, secured, or leaked.

SLSA: Maturity Model for Build Integrity

The SLSA framework (Supply-chain Levels for Software Artifacts, pronounced "salsa") defines four levels of build integrity:

  • Level 1: The build process is documented and not manual.
  • Level 2: The build runs hosted and versioned; provenance is recorded as an attestation.
  • Level 3: The build platform itself is hardened – isolated, immutable build environments prevent manipulation.
  • Level 4: Two-person review and hermetic builds (fully reproducible).

Most organizations should aim for at least SLSA Level 3. This ensures that an attacker who has gained access to the CI system cannot deliver manipulated artifacts without it being detectable. SLSA Level 4 is currently only realistic for particularly critical infrastructure components.

Kubernetes Admission Control: The Enforcement Layer

Signed images are of little use if the signature is not enforced. This is where Kubernetes admission controllers come into play. With Kyverno or OPA/Gatekeeper, you can enforce that only signed images run on a cluster:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: enforce
  rules:
  - name: verify-cosign-signature
    match:
      resources:
        kinds: ["Pod"]
    verifyImages:
    - imageReferences:
      - "ghcr.io/myorg/*"
      attestors:
      - entries:
        - keyless:
            subject: "ci@myorg.com"
            issuer: "https://token.actions.githubusercontent.com"
Enter fullscreen mode Exit fullscreen mode

This policy blocks any pod whose container image lacks a valid Cosign signature with the expected identity. Unsigned or manipulated images are automatically rejected – before they are even executed.

The Complete DevOps Pipeline

In practice, a six-step security workflow has become established:

  1. Build – Reproducible, hermetic builds in isolated CI environments
  2. Scan – Vulnerability scanning with Trivy or Grype immediately after the build
  3. Sign – Keyless signing with Cosign and Sigstore
  4. Attest – Attach SBOM and scan results as verifiable attestations
  5. Verify – Admission controllers (Kyverno/OPA) enforce signed images in the cluster
  6. Monitor – Continuously scan running containers for new CVEs

Organizations implementing this workflow report 76 percent fewer security incidents in the supply chain and save an average of 1.76 million US dollars per prevented breach.

Conclusion

Supply chain security is no longer an optional DevSecOps add-on in 2026. With the EU Cyber Resilience Act, SBOMs and verifiable build integrity are already regulatory requirements for many companies. The good news: The tools are mature, open source, and production-proven. Sigstore/Cosign, the SLSA framework, and Kubernetes admission controllers form a triad that effectively prevents attacks on the software supply chain. DevOps teams that start today with SBOM generation, keyless signing, and Kyverno policies are not only more secure – they are also on the safe side regulatory-wise.

Sources

Top comments (0)