Supply Chain Security

Supply Chain Attack Landscape

A software supply chain attack compromises software or its delivery infrastructure before it reaches the consumer. Kubernetes clusters are high-value targets because a single compromised component can affect all workloads.

The Full Trust Chain

Securing the supply chain means establishing and verifying trust at every step from source code to running container.

SBOM: Software Bill of Materials

An SBOM is a machine-readable inventory of every component in a software artifact — OS packages, language libraries, build tools, and their versions and licenses. It is the foundation of supply chain visibility.

SBOM Formats

Generating SBOMs with Syft

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

# Generate CycloneDX SBOM from container image
syft registry.example.com/myapp@sha256:abc123 \
  -o cyclonedx-json=sbom.cyclonedx.json

# Generate SPDX SBOM
syft registry.example.com/myapp@sha256:abc123 \
  -o spdx-json=sbom.spdx.json

# Generate SBOM from source directory (during build)
syft dir:. -o cyclonedx-json=sbom.cyclonedx.json

# Generate from Docker image tarball
syft docker-archive:myapp.tar -o cyclonedx-json=sbom.cyclonedx.json

# Include licenses in output
syft registry.example.com/myapp@sha256:abc123 \
  -o cyclonedx-json=sbom.cyclonedx.json \
  --config syft.yaml  # syft.yaml: catalogers, exclude patterns

Generating SBOMs with Trivy

Copy# Generate CycloneDX SBOM with Trivy
trivy image \
  --format cyclonedx \
  --output sbom.cyclonedx.json \
  registry.example.com/myapp@sha256:abc123

# Generate SPDX SBOM
trivy image \
  --format spdx-json \
  --output sbom.spdx.json \
  registry.example.com/myapp@sha256:abc123

# Docker buildx: generate SBOM during build (BuildKit 0.11+)
docker buildx build \
  --sbom=true \
  --output type=registry \
  --tag registry.example.com/myapp:1.0.0 \
  .

Distributing SBOMs via OCI Registry

Copy# Attach SBOM as OCI artifact referrer (using cosign)
cosign attach sbom \
  --sbom sbom.cyclonedx.json \
  --type cyclonedx \
  registry.example.com/myapp@sha256:abc123

# Verify and retrieve attached SBOM
cosign download sbom registry.example.com/myapp@sha256:abc123

# Attach as attestation (preferred — signed and verifiable)
cosign attest \
  --key cosign.key \
  --type cyclonedx \
  --predicate sbom.cyclonedx.json \
  registry.example.com/myapp@sha256:abc123

# Download and verify SBOM attestation
cosign verify-attestation \
  --key cosign.pub \
  --type cyclonedx \
  registry.example.com/myapp@sha256:abc123 | \
  jq '.payload | @base64d | fromjson | .predicate'

in-toto Attestations

in-toto is a framework for cryptographically securing software supply chain operations. It defines a format for recording facts about software artifacts (attestations) that can be verified independently of the artifact itself.

SLSA Provenance Attestation

Copy# SLSA provenance predicate (v1) — generated by build platform
{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [{
    "name": "registry.example.com/myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/tags/v1.2.3",
          "repository": "https://github.com/myorg/myrepo",
          "path": ".github/workflows/release.yaml"
        }
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1.10.0"
      },
      "metadata": {
        "invocationId": "https://github.com/myorg/myrepo/actions/runs/1234567890",
        "startedOn": "2024-01-15T10:00:00Z",
        "finishedOn": "2024-01-15T10:05:00Z"
      }
    }
  }
}

Vulnerability Attestation

Copy# Generate vulnerability scan attestation with Trivy + Cosign

# 1. Run Trivy scan and save results
trivy image \
  --format cosign-vuln \
  --output vuln-results.json \
  registry.example.com/myapp@sha256:abc123

# 2. Attest vulnerability scan results
cosign attest \
  --key cosign.key \
  --type vuln \
  --predicate vuln-results.json \
  registry.example.com/myapp@sha256:abc123

# 3. Verify vulnerability attestation at admission (Policy Controller)
# (Policy Controller can reject images whose latest scan exceeds CVE threshold)

Sigstore Policy Controller

The Sigstore Policy Controller is a validating admission webhook that enforces image signature and attestation policies. It is more expressive than Kyverno's verifyImages and is the reference implementation for Sigstore-native policies.

Copy# Install Sigstore Policy Controller
helm repo add sigstore https://sigstore.github.io/helm-charts
helm install policy-controller sigstore/policy-controller \
  --namespace cosign-system \
  --create-namespace

Copy# Opt namespace into Policy Controller enforcement
kubectl label namespace production \
  policy.sigstore.dev/include=true

ClusterImagePolicy: Keyless Signature

CopyapiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-signed-images
spec:
  images:
  - glob: "registry.example.com/**"
  authorities:
  - keyless:
      url: https://fulcio.sigstore.dev
      identities:
      - issuer: https://token.actions.githubusercontent.com
        subject: https://github.com/myorg/myrepo/.github/workflows/release.yaml@refs/heads/main

ClusterImagePolicy: Require SBOM Attestation

CopyapiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-sbom-attestation
spec:
  images:
  - glob: "registry.example.com/**"
  authorities:
  - keyless:
      url: https://fulcio.sigstore.dev
      identities:
      - issuer: https://token.actions.githubusercontent.com
        subjectRegExp: "https://github.com/myorg/.*"
    attestations:
    - name: must-have-sbom
      predicateType: https://cyclonedx.org/bom
      policy:
        type: cue
        data: |
          # CUE policy: SBOM must have at least one component
          predicate: components: [_, ...]

ClusterImagePolicy: Require Vulnerability Scan with No Critical CVEs

CopyapiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-vuln-attestation
spec:
  images:
  - glob: "registry.example.com/**"
  authorities:
  - keyless:
      url: https://fulcio.sigstore.dev
      identities:
      - issuer: https://token.actions.githubusercontent.com
        subjectRegExp: "https://github.com/myorg/.*"
    attestations:
    - name: no-critical-cves
      predicateType: cosign.sigstore.dev/attestation/vuln/v1
      policy:
        type: cue
        data: |
          import "time"
          # Scan must be less than 24 hours old
          predicate: scanner: result: Summary: Critical: 0
          predicate: metadata: scanFinishedOn: >time.Now().Add(-24*time.Hour)

CI/CD Pipeline Hardening

The CI/CD pipeline is the highest-privilege environment in the supply chain. Compromising the build pipeline allows injecting malicious code into all downstream artifacts without modifying source.

GitHub Actions Hardening

Copy# .github/workflows/release.yaml — hardened workflow
name: Release
on:
  push:
    tags: ['v*']

permissions:              # Minimal top-level permissions
  contents: read

jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write     # Required for OIDC token (Cosign keyless)
      packages: write     # Required for pushing to GHCR
      attestations: write # Required for GitHub Attestations API

    steps:
    # Pin actions to immutable SHA — never use @main or @v1 (mutable tags)
    - name: Checkout
      uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@c47758b77c9736f4b2ef4073d4d51994fabfe349  # v3.7.1

    - name: Log in to GHCR
      uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567  # v3.3.0
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}  # Short-lived, auto-rotated

    - name: Build and push
      id: build
      uses: docker/build-push-action@4f58ea79222b3b9dc2c8bbdd6debcef730109a75  # v6.9.0
      with:
        context: .
        push: true
        tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
        sbom: true           # BuildKit SBOM generation
        provenance: mode=max  # SLSA provenance

    - name: Sign image
      run: |
        cosign sign --yes \
          ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}
      env:
        COSIGN_EXPERIMENTAL: "1"

Fork PR Security

Copy# Prevent fork PRs from accessing secrets
on:
  pull_request_target:    # DANGER: runs in context of base repo, has secrets
# Use pull_request instead — runs in fork context, no secrets
on:
  pull_request:           # Safe: no access to base repo secrets

# Require approval for first-time contributors
# Settings → Actions → Fork pull request workflows → Require approval

Securing CI Secrets

Copy# GitHub Actions OIDC → AWS ECR (no static credentials)
- name: Configure AWS credentials via OIDC
  uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
  with:
    role-to-assume: arn:aws:iam::123456789012:role/github-actions-ecr-push
    aws-region: us-east-1

# AWS IAM role trust policy (allows GitHub Actions OIDC)
{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:myorg/myrepo:*"
    }
  }
}

Dependency Management

Lockfile Integrity

Lockfiles record the exact versions and checksums of every dependency. Committing them to the repository ensures reproducibility and enables detection of unexpected changes.

Copy# Python: install with hash verification
# requirements.txt with hashes
requests==2.31.0 \
  --hash=sha256:58cd2187423839f822e6c5d5ded81a... \
  --hash=sha256:942c5a758f98d790eaed1a29cb6eefc...

# Install enforcing hash verification
pip install --require-hashes -r requirements.txt

# Go: verify all module checksums
go mod verify
# Fails if any module hash doesn't match go.sum

# Node: use npm ci (not npm install) in CI
# npm ci: installs exactly what's in package-lock.json, fails on mismatch
npm ci --only=production

Private Module Proxy / Artifact Repository

Routing all dependency downloads through a private proxy prevents dependency confusion attacks — the proxy enforces that internal package names never resolve to public registries.

Copy# Go: use private module proxy (Athens, Artifactory, Nexus)
GONOSUMCHECK=*.internal.example.com \
GONOSUMDB=*.internal.example.com \
GOFLAGS=-mod=mod \
GOPROXY=https://goproxy.internal.example.com,direct \
  go build ./...

# npm: private registry via .npmrc
# .npmrc
registry=https://registry.example.com
//registry.example.com/:_authToken=${NPM_TOKEN}
# Block public registry fallback:
@myorg:registry=https://registry.example.com

# pip: private PyPI mirror
pip install --index-url https://pypi.internal.example.com/simple/ \
  --no-deps \
  requests==2.31.0

Automated Dependency Updates

Copy# .github/renovate.json — automated dependency updates with PR per change
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "automerge": true     // Auto-merge patch updates if CI passes
    },
    {
      "matchDepTypes": ["action"],
      "pinDigests": true     // Pin GitHub Action versions to SHA
    }
  ],
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
  }
}

Third-Party Operators & Helm Charts

Kubernetes operators and Helm charts from external sources are high-risk: they often request cluster-admin or broad RBAC permissions and run privileged workloads.

Operator Security Vetting Checklist

Helm Chart Verification

Copy# Helm provenance: verify chart integrity (classic Helm signing)
# Chart packager creates .prov file with PGP signature

# Import chart maintainer's PGP key
gpg --import maintainer-pubkey.gpg

# Install with provenance verification
helm install myrelease myrepo/mychart --verify

# Download chart and verify manually
helm pull myrepo/mychart --verify --provenance

# Helm OCI: charts stored as OCI artifacts can be signed with Cosign
cosign sign oci://registry.example.com/charts/mychart:1.2.3
cosign verify \
  --key cosign.pub \
  oci://registry.example.com/charts/mychart:1.2.3

Copy# Helm chart security review: render and inspect before installing

# Render all templates to stdout
helm template myrelease myrepo/mychart --values my-values.yaml

# Check for dangerous RBAC
helm template myrelease myrepo/mychart | \
  grep -A5 "ClusterRoleBinding\|cluster-admin\|\"*\""

# Check for privileged pods
helm template myrelease myrepo/mychart | \
  grep -i "privileged\|hostPID\|hostNetwork\|hostPath"

# Use Polaris to audit rendered templates
helm template myrelease myrepo/mychart | polaris audit --audit-path -

Software Composition Analysis

Software Composition Analysis (SCA) identifies open-source components and their known vulnerabilities (CVEs) and license obligations in your codebase and container images.

SCA in the Pipeline

Copy# Grype: vulnerability scan from SBOM
grype sbom:sbom.cyclonedx.json \
  --fail-on critical \
  --output json > vuln-report.json

# OWASP Dependency-Check for Java/Node/Python
dependency-check \
  --project myapp \
  --scan ./app \
  --format JSON \
  --out ./reports \
  --nvdApiKey $NVD_API_KEY

# OSV-Scanner: checks against OSV database (comprehensive, fast)
osv-scanner --lockfile package-lock.json
osv-scanner --sbom sbom.cyclonedx.json

VEX: Vulnerability Exploitability eXchange

VEX documents allow you to assert that a CVE in a dependency is not exploitable in your specific artifact — reducing false positives in vulnerability reports.

Copy# VEX document: assert CVE not exploitable in our context
{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/myapp-1.0.0",
  "author": "security@example.com",
  "timestamp": "2024-01-15T10:00:00Z",
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-44487" },
      "products": [{ "@id": "pkg:oci/myapp@sha256:abc123" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "HTTP/2 is not used by this component; TLS terminates at ingress"
    }
  ]
}

# Generate VEX with vexctl
vexctl create \
  --product "pkg:oci/myapp@sha256:abc123" \
  --vuln CVE-2023-44487 \
  --status not_affected \
  --justification vulnerable_code_not_in_execute_path

# Trivy respects VEX: filter results using VEX document
trivy image \
  --vex vex-document.openvex.json \
  registry.example.com/myapp@sha256:abc123

Runtime Integrity

dm-verity for Container Image Verification

dm-verity is a Linux kernel mechanism that cryptographically verifies block device data on every read. When used with container storage, it ensures the on-disk image layers match their expected hash — preventing tampering after pull.

Kata Containers for Workload Isolation

Kata Containers run each pod in a lightweight VM instead of a container. This provides hardware-level isolation between workloads and between workloads and the host kernel — the strongest available workload isolation.

Copy# Use Kata Containers runtime class for high-security workloads
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-containers
handler: kata
scheduling:
  nodeSelector:
    kata-containers: "true"
---
spec:
  runtimeClassName: kata-containers
  containers:
  - name: sensitive-workload
    image: registry.example.com/payment-service@sha256:abc123

Metrics, Alerts & Runbooks

Key Metrics

Alerts

Copy# Alert: Unsigned image deployment blocked
- alert: UnsignedImageBlocked
  expr: increase(cosign_verification_failures_total[5m]) > 0
  for: 0m
  severity: critical
  annotations:
    summary: "Image signature verification failed — possible supply chain attack or CI misconfiguration"

# Alert: SBOM attestation missing for new deployment
- alert: SBOMAttestationMissing
  expr: increase(policy_controller_admissions_total{policy="require-sbom-attestation",result="denied"}[5m]) > 0
  annotations:
    summary: "Deployment rejected: missing SBOM attestation"

# Alert: Critical CVE in SBOM attestation
- alert: CriticalCVEInAttestaton
  expr: increase(policy_controller_admissions_total{policy="require-vuln-attestation",result="denied"}[5m]) > 0
  annotations:
    summary: "Deployment rejected: Critical CVE in vulnerability attestation"

# Alert: Policy Controller webhook unhealthy
- alert: PolicyControllerWebhookDown
  expr: up{job="policy-controller"} == 0
  for: 2m
  severity: critical
  annotations:
    summary: "Policy Controller webhook down — supply chain enforcement not active"

Runbooks

Best Practices