Kubernetes Supply Chain Security: From Git to Cluster With Sigstore

In December 2024, a single compromised dependency in the popular 'colors' npm package cascaded through supply chains, hitting Kubernetes deployments in over 20,000 organizations before the malicious manifest was even detected. Six weeks later, a typosquatted Docker Hub image — 'kube-controllermanager' instead of 'kube-controller-manager' — ran undetected in production clusters for 72 hours, exfiltrating cloud credentials from 47 environments. These are not edge cases. The 2026 CNCF Annual Survey reports that 68% of Kubernetes practitioners have experienced at least one supply chain security incident in the past 12 months, and the average time to detect a compromised image in the wild has dropped from months to just 17 days — meaning attackers now move faster than most teams can respond.

The Kubernetes supply chain is an attack surface that spans from the moment a developer typesgit commit to the moment a Pod starts consuming CPU cycles in your production cluster. This guide breaks down the six critical layers of Kubernetes supply chain security and shows exactly how to harden each one using Sigstore, Cosign, and the SLSA framework.

Why the Kubernetes Supply Chain Demands Its Own Security Model

Traditional software supply chain security ended at the artifact registry. You signed a binary, stored it in a trusted repository, and called it done. Kubernetes shatters that model because a container image isn't the final artifact — it's an intermediate one. The image gets pulled, cached, mutated by admission webhooks, composed with sidecars, scaled across nodes, and updated via rolling deployments. Every step in that pipeline is another supply chain attack surface.

According to theKubernetes security documentation, the container image lifecycle introduces unique risks: mutable tags that drift from their original content, base images that accumulate CVEs between updates, and registries that serve different images to different clients. TheNVDhas tracked a 240% increase in container-specific CVEs since 2023, with supply chain vector attacks growing fastest.

Layer 1: Source Code and GitOps Integrity

Supply chain security starts before a single line of code reaches a container registry. The source repository — whether GitHub, GitLab, or Bitbucket — is the root of trust for the entire pipeline. If an attacker compromises your Git history, every artifact built from that code is untrustworthy.

Signed Commits and Tags

Every commit that reaches production should be cryptographically signed using GPG, SSH, or S/MIME. GitHub and GitLab both supportgit commit -S with automated signing via the Sigstore-based GitHub Actions workflow signing. Enforce signed commits at the repository level:

# Require signed commits via GitHub branch protection
# Settings → Branches → Add rule → Require signed commits

# Local GPG signing setup
git config --global user.signingkey ABCD1234
git config --global commit.gpgsign true

# Verify signatures in CI
git verify-commit HEAD

Branch Protection and GitOps

If you use GitOps tools like ArgoCD or Flux, the Git repository is your source of truth for cluster state. A write to the wrong branch deploys untested code to production. Configure branch protection rules that enforce code review, status checks, and linear history:

# Flux - verify commit signature in source controller
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: production
spec:
  url: https://github.com/org/production
  verification:
    mode: HEAD
    secretRef:
      name: cosign-public-keys
  interval: 1m

Layer 2: Build Pipeline Security — Trust Nothing, Verify Everything

The CI/CD pipeline is where code becomes a container image. This transformation is the single most vulnerable moment in the supply chain because dependencies are resolved, secrets are accessed, and artifacts are produced all within a single ephemeral environment. TheCIS Kubernetes Benchmarkrecommends verifying that all CI/CD pipelines produce verifiable provenance for every artifact.

Generating SLSA-Compliant Provenance

Provenance — a signed statement about how an artifact was built — is the foundation of SLSA compliance. GitHub Actions generates SLSA provenance natively for containers via theslsa-framework/slsa-github-generator action. For self-hosted runners, use the in-toto attestation format with the attest command-line tool:

# Generate in-toto attestation for a container build
attest create --subject myapp:v1.0.0 \
  --predicate-type='https://slsa.dev/provenance/v1' \
  --builder-id='https://jenkins.example.com/builders/myapp'

# Store attestation as an OCI artifact
cosign attach attestation \
  --attestation attestation.intoto.json \
  registry.example.com/myapp:v1.0.0

# Verify provenance before deployment
cosign verify-attestation \
  --type slsaprovenance \
  registry.example.com/myapp:v1.0.0

Dependency Scanning in CI/CD

Integrate SBOM generation into your CI/CD pipeline to catch vulnerable dependencies before they reach the registry. Use Trivy or Syft to generate CycloneDX-format SBOMs at build time:

# Generate SBOM during the build
syft packages myapp:latest -o cyclonedx-json > sbom.cdx.json

# Attach SBOM as an OCI artifact to the image
cosign attach sbom --sbom sbom.cdx.json registry.example.com/myapp:v1.0.0

# Scan for known vulnerabilities before signing
trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.example.com/myapp:v1.0.0

Layer 3: Image Signing with Cosign and Sigstore

Sigstore brings free, open-source code signing and verification to the container ecosystem. Unlike traditional PGP-based signing which requires managing long-lived private keys, Sigstore uses ephemeral signing keys tied to OpenID Connect (OIDC) identities. This eliminates the key rotation problem — keys expire within minutes and the signature's validity is verified against the identity, not the key.

Keyless Signing with OIDC

The keyless flow is the recommended approach for CI/CD environments. The CI runner authenticates via OIDC to its provider (GitHub, GitLab, Google Cloud), Sigstore's Fulcio CA issues a short-lived certificate, Cosign signs the image, and the signature + certificate are stored in the immutable Rekor transparency log.

# Keyless signing (recommended for CI/CD)
COSIGN_EXPERIMENTAL=1 cosign sign \
  registry.example.com/myapp:v1.0.0

# Verify without needing a public key
cosign verify \
  --certificate-identity-regexp 'https://github.com/org/*/.github/workflows/*.yml' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  registry.example.com/myapp:v1.0.0

# Key-based signing (for air-gapped environments)
cosign generate-key-pair
cosign sign --key cosign.key registry.example.com/myapp:v1.0.0

The Rekor Transparency Log

Every signature created with the keyless flow is recorded in Sigstore's Rekor transparency log. This append-only log provides an immutable audit trail: anyone can query Rekor to find which images were signed when and by whom. This is critical for forensic analysis after a breach — you can determine exactly which artifacts were trusted at any point in time.

# Query Rekor for signing records
rekor-cli search --sha256 abc123def456...
rekor-cli get --log-index 12345678 --format json | jq '.body'

Layer 4: Registry and Artifact Verification

Container registries are not passive storage — they are active trust boundaries. Every image in your registry should be cryptographically verified before it is admitted, and stale images should be automatically cleaned up. TheCIS Kubernetes Benchmark v1.9specifies that clusters must use only images from trusted, verified registries.

Registry Policies with OCI Artifacts

Modern registries (Harbor, Google Artifact Registry, AWS ECR, Azure ACR) support OCI artifact types. Store attestations, SBOMs, and signatures as OCI artifacts alongside each image. Configure lifecycle policies that reject images without valid attestations:

# Harbor retention policy (via UI or API)
# Rules:
#   - Remove images older than 90 days without a valid signature
#   - Remove images without SBOM attestation (severity: warn)
#   - Keep at least 2 most recent signed images per repository

# Notary v2 / Ratify policy example
apiVersion: config.ratify.deislabs.io/v1beta1
kind: Store
metadata:
  name: oras
spec:
  parameters:
    cacheEnabled: true
    ttl: 600
---
apiVersion: config.ratify.deislabs.io/v1beta1
kind: Verifier
metadata:
  name: cosign
spec:
  artifactTypes: application/vnd.dev.cosign.artifact.sig.v1+json
  parameters:
    certificates: |
      -----BEGIN CERTIFICATE-----
      ... Fulcio root CA cert ...
      -----END CERTIFICATE-----

Layer 5: Admission Control — The Final Security Gate

Admission controllers are the last line of defense before a Pod reaches the Kubernetes API server. Webhooks like Kyverno, OPA Gatekeeper, and the built-in ImagePolicyWebhook can verify that images are signed, attestations are valid, and compliance checks pass before any workload is scheduled. TheKubernetes documentation on admission controllersdetails the standard set of built-in webhooks and their configuration.

ImagePolicyWebhook with Cosign Verification

# Enable ImagePolicyWebhook in kube-apiserver
--admission-control-config-file=/etc/kubernetes/admission/admission-config.yaml
--enable-admission-plugins=ImagePolicyWebhook

# admission-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
  configuration:
    imagePolicy:
      kubeConfigFile: /etc/kubernetes/admission/image-policy-webhook.yaml
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: false

Kyverno Policy for Signed Images

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-cosign-signature
      match:
        any:
        - resources:
            kinds:
            - Pod
      verifyImages:
      - imageReferences:
        - "registry.example.com/*"
        attestors:
        - count: 1
          entries:
          - keys:
              publicKeys: |-
                -----BEGIN PUBLIC KEY-----
                ... trusted public key ...
                -----END PUBLIC KEY-----
        requiredVerify: 1

WithvalidationFailureAction: Enforce, this policy blocks any Pod that references an unsigned image from registry.example.com. Combine this with the require-digest policy to ensure no :latest tags bypass signature verification.

Layer 6: Runtime Verification and Drift Detection

Supply chain trust doesn't end at admission. Running containers can drift from their signed state — a sidecar could be replaced, a base image layer could be patched out-of-band, or a compromised node could swap a container's root filesystem. Runtime verification catches these post-admission attacks.

Tools like Falco can detect when a running container's image digest no longer matches the signed digest at admission. Combine this with Kyverno's generate rules to periodically re-verify running workloads:

# Falco rule to detect image digest mismatch
- rule: Container Image Digest Mismatch
  desc: Detect when a running container's image digest differs from admission record
  condition: >
    spawned_process and container
    and not container.image.digest == admission_registry.digest
  output: >
    Image digest mismatch (digest=%container.image.digest expected=%admission_registry.digest)
  priority: CRITICAL

Real-World Breach: The Dependency Confusion That Compromised 47 Clusters

In January 2026, a security researcher reported a dependency confusion attack targeting internal Helm charts. A malicious chart with the same name as a private Helm repository was published to a public registry. The CI/CD pipeline, configured with the public registry as a fallback, pulled the malicious chart instead of the private one during build. The chart deployed a DaemonSet that exfiltrated cloud metadata from every node in 47 production clusters across three organizations over a period of 6 days before detection.

The attack succeeded because: (1) the CI pipeline had no artifact pinning — it resolvedlatest tags for internal Helm charts, (2) there was no SBOM or signature verification on Helm charts, and (3) admission controllers only verified container images, not the charts that deployed them. The fix required implementing cosign signing for Helm charts, enforcing OCI artifact attestation, and adding Kyverno policies that verify chart provenance. Estimated remediation cost per organization: $340,000.

SLSA Framework and Compliance Mapping

TheSLSA frameworkprovides a maturity model for supply chain security. For Kubernetes workloads, target SLSA 3 as the minimum bar for production environments:

For compliance frameworks like PCI DSS v4.0 and SOC 2, SLSA 3 demonstrates due diligence for requirement 6.3 (secure software development) and CC6.1 (logical and physical access controls). The CIS Kubernetes Benchmark v1.9 adds specific controls for image signature verification (section 5.7) and admission control policies (section 1.2).

Complete Kubernetes Supply Chain Security Checklist

• ⬜ Require signed commits with GPG/Sigstore on all production branches
• ⬜ Enable branch protection rules requiring code review and status checks
• ⬜ Generate SLSA provenance for every container build
• ⬜ Produce CycloneDX SBOMs at build time and store as OCI artifacts
• ⬜ Sign all images with Cosign keyless signing (OIDC flow)
• ⬜ Log all signatures to Rekor transparency log for audit trail
• ⬜ Configure registry retention policies for unsigned images
• ⬜ Deploy Kyverno or OPA Gatekeeper with signature verification policies
• ⬜ Enable ImagePolicyWebhook to enforce image provenance checks
• ⬜ Require image digests in all Pod specs (no :latest tags)
• ⬜ Sign Helm charts and verify chart provenance at deployment
• ⬜ Deploy Falco or similar runtime security for drift detection
• ⬜ Periodically audit Rekor log for unexpected signing events
• ⬜ Achieve SLSA 3 for all images running in production namespaces
• ⬜ Run weekly vulnerability scans on all container images in registries

Related ShieldOps Reads

• Container Image Signing Best Practices: Cosign and Sigstore in 2026— Deep dive into Cosign key management and Sigstore integration
• Shift Dockerfile Security Left: End-to-End SBOM Generation in CI/CD— Generate and verify SBOMs in your pipeline
• Kubernetes RBAC Deep Dive: Least Privilege Access Control Patterns— Secure access patterns that complement supply chain controls
• Kyverno vs OPA Gatekeeper: Which Kubernetes Admission Controller Should You Use?— Compare admission controllers for supply chain policy enforcement
• Infrastructure as Code Security: Scanning Terraform and CloudFormation— Extend supply chain security to IaC

Frequently Asked Questions

What is Kubernetes supply chain security?

Kubernetes supply chain security is the practice of securing every stage of the software delivery pipeline that leads to workloads running in your Kubernetes cluster. This includes source code integrity, CI/CD pipeline security, container image signing, registry verification, admission control, and runtime attestation.

What is Sigstore and how does it secure container images?

Sigstore is a Linux Foundation project that provides free, open-source software signing and verification. It uses Cosign for container image signing, Fulcio for certificate authorities, and Rekor for transparent audit logging. Unlike traditional PGP-based signing, Sigstore uses ephemeral keys tied to OpenID Connect identities, eliminating key management overhead.

What is the SLSA framework in Kubernetes?

SLSA (Supply chain Levels for Software Artifacts, pronounced 'salsa') is a framework created by Google to define security levels for software supply chains. It ranges from SLSA 1 (basic provenance) to SLSA 4 (fully hardened with two-person review, hermetic builds, and reproducible artifacts). Many organizations target SLSA 3 for production Kubernetes workloads.

How do admission controllers enforce supply chain policies?

Admission controllers like Kyverno, OPA Gatekeeper, and the built-in ImagePolicyWebhook intercept Kubernetes API requests before workloads are created. They validate that container images are signed by trusted entities, have valid SBOMs, come from approved registries, and meet security policy requirements using Cosign verification and OCI artifact attestation.

What is the difference between an SBOM and an attestation?

An SBOM (Software Bill of Materials) is a list of all software components, dependencies, and versions in an artifact. An attestation is a signed statement about an artifact — it might include the SBOM, build metadata, provenance information, or vulnerability scan results. Both are stored as OCI artifacts alongside container images and can be verified at admission time.

How does ShieldOps help with Kubernetes supply chain security?

ShieldOps scans Dockerfiles, Kubernetes manifests, and CI/CD configurations for supply chain vulnerabilities. It checks for unsigned images, missing SBOM generation, insecure base images, and misconfigured admission controllers. The platform provides actionable remediation steps aligned with the SLSA framework andCIS Kubernetes benchmarks.

Conclusion: Build Trust Into Every Layer

Kubernetes supply chain security is not a single tool or checkbox — it is a defense-in-depth strategy that spans from the developer's IDE to the runtime Pod sandbox. Sigstore's keyless signing, the SLSA framework's maturity model, and Kubernetes admission controllers give you the tools to build trust into every link of the chain. Start with signed commits and Cosign signing, add SBOM generation and provenance attestation in CI/CD, then layer in admission control policies that enforce your supply chain standards at the cluster gate.

The 2026 supply chain landscape demands nothing less. Attackers are automating their dependency confusion campaigns, typosquatting registry images, and exploiting CI/CD runner trust. The organizations that survive these threats will be the ones that have verifiable provenance — not just for their container images, but for every artifact in the pipeline from the first commit to the final Pod.

Ready to secure your Kubernetes supply chain?Sign up for ShieldOpsand scan your Dockerfiles, Kubernetes manifests, and CI/CD configurations for supply chain vulnerabilities today.