Security Architecture

Supply Chain Security

Securing the software supply chain: SBOM generation, SLSA build provenance, dependency vulnerability scanning, artifact signing with Sigstore/Cosign, and container image integrity.

⏱ 10 min read

What it is

Software supply chain security addresses the security of the entire path from source code to running software: source code repositories, build systems, third-party dependencies, container base images, CI/CD pipelines, and artifact distribution channels. The SolarWinds attack (2020) and Log4Shell (2021) demonstrated that a compromise or vulnerability at any point in this chain can affect thousands of downstream organisations simultaneously. The key concepts are: SBOM (Software Bill of Materials) — a machine-readable inventory of all components in a software artifact, including transitive dependencies, their versions, and licenses, in CycloneDX or SPDX format; SLSA (Supply chain Levels for Software Artifacts) — a Google-originated framework that defines four levels of build provenance and tamper-resistance, from basic source control (SLSA 1) to fully hermetic, reproducible builds (SLSA 4); and artifact signing using Sigstore/Cosign — keyless signing of container images and other artifacts using short-lived certificates tied to OIDC identity, providing verifiable proof that a specific build system produced a specific artifact.

Dependency scanning tools (Dependabot, Snyk, Renovate, OWASP Dependency-Check) continuously monitor declared dependencies against vulnerability databases (NVD, OSV, GitHub Advisory Database) and alert when a known CVE affects a dependency version. Container image scanning (Trivy, Grype, Snyk Container) extends this to OS packages installed in container base images, which are a common source of vulnerabilities that application dependency scanners miss. Software Composition Analysis (SCA) provides both vulnerability scanning and license compliance checking — identifying GPL-licensed components in proprietary software that create license obligations.

Why it exists

Modern applications consist of 80–95% third-party code (direct and transitive dependencies). Log4Shell (CVE-2021-44228) — a critical RCE vulnerability in the ubiquitous Log4j library — affected hundreds of thousands of applications worldwide, many of which didn't even know they were using Log4j (it was a transitive dependency of another library). An SBOM would have enabled affected teams to identify their exposure in minutes rather than days. The SolarWinds attack demonstrated that a compromised build pipeline could inject malicious code into signed, trusted artifacts — SLSA build provenance makes it cryptographically verifiable that an artifact came from an expected build system running expected source code, making pipeline compromise attacks detectable.

When to use

All software with third-party dependencies — SBOM generation and dependency scanning are baseline requirements.
Public or regulated software — SBOM is increasingly required by government procurement (US Executive Order 14028) and industry standards.
Container-based workloads — image scanning of base images and all installed packages is essential.
Critical infrastructure or software distributed to customers — SLSA build provenance and artifact signing provide supply chain integrity guarantees.

When not to use

These are not optional controls for any serious software project. SBOM generation and dependency scanning have near-zero overhead and should be universal. SLSA higher levels (3–4) require significant build system investment and are most appropriate for software distributed to many downstream consumers.

Typical architecture

SUPPLY CHAIN SECURITY IN CI/CD:

Source Code (GitHub)
  │ Protected branches, code review required
  │ Secret scanning on push (no credentials in code)
  ▼
Build Pipeline (GitHub Actions)
  │ Dependency scanning (Snyk/Dependabot) on PR
  │ SAST scan (CodeQL)
  │ Build runs in isolated, ephemeral runner
  ▼
SBOM Generation
  │ syft generates CycloneDX SBOM for artifact
  │ SBOM includes: all deps + versions + licenses
  │ SBOM stored as build artifact (+ attested)
  ▼
Container Build
  │ FROM base image (pinned by digest, not tag)
  │ Image built deterministically
  ▼
Image Scanning (Trivy)
  │ Scan image layers for CVEs
  │ Block deployment if CRITICAL/HIGH unfixed CVEs
  ▼
Artifact Signing (Cosign + Sigstore)
  │ Image signed using GitHub OIDC identity
  │ Signature + provenance attestation pushed
  │ to OCI registry alongside image
  ▼
Container Registry (ECR / GAR)
  │ Continuous scanning enabled
  │ Admission controller verifies signature on deploy
  ▼
Kubernetes (with Kyverno/OPA Gatekeeper)
  Policy: deny deployments of unsigned images
  Policy: deny images not from approved registries
  Policy: deny images with critical CVEs

SLSA LEVELS:
  Level 1: Build scripted, SBOM generated
  Level 2: Build service (CI), signed provenance
  Level 3: Isolated build, source verified, non-forgeabale provenance
  Level 4: Hermetic build, reviewed build def, two-party review

COSIGN KEYLESS SIGNING:
  cosign sign --yes ${IMAGE}@${DIGEST}
  # Signs using GitHub Actions OIDC token
  # Certificate: github.com/org/repo/.github/workflows/build.yml
  # Stored in Rekor transparency log
  cosign verify --certificate-identity-regexp="github.com/org/repo"
                --certificate-oidc-issuer=https://token.actions.githubusercontent.com
                ${IMAGE}@${DIGEST}

Pros and cons

Pros

SBOM enables rapid vulnerability impact assessment: when Log4Shell-equivalent CVEs emerge, teams can identify affected services in minutes by querying the SBOM rather than manually auditing code.
Automated dependency scanning with PR blocking prevents new vulnerabilities from being introduced and provides immediate feedback to developers.
Artifact signing with admission control enforcement means only verified, approved images can run in production — compromised or tampered images are rejected at deploy time.
SLSA provenance creates an auditable chain from specific source commit to specific running artifact, enabling post-incident investigation of supply chain compromises.

Cons

Dependency scanning generates alert noise; a large dependency tree with many vulnerabilities requires triage processes to distinguish exploitable vulnerabilities from irrelevant ones.
Pinning container base images by digest prevents tag-based automatic updates; digest pinning must be managed by automation (Renovate) to incorporate security updates.
SLSA level 3+ requires significant build infrastructure investment and is complex to implement correctly.
Keyless signing with Sigstore publishes information to a public transparency log; this may not be appropriate for proprietary software that should not advertise its dependency structure.

Implementation notes

Pin all dependency versions (use lockfiles — package-lock.json, Pipfile.lock, go.sum, Cargo.lock) and commit them to source control. Never use version ranges (^1.2.0) in production builds without a lockfile, as they allow transitive dependency upgrades that introduce vulnerabilities silently. For container base images, pin by SHA256 digest in the Dockerfile (FROM ubuntu@sha256:abc123...) rather than by tag, since tags are mutable and a tag can be repointed to a different image. Use Renovate or Dependabot to automate PR creation when dependency updates with security fixes are available.

Implement a vulnerability triage process: not every CVE in a dependency is exploitable in your specific usage. CVSS score alone is insufficient — use EPSS (Exploit Prediction Scoring System) for exploitability context and VEX (Vulnerability Exploitability eXchange) documents to record "this dependency contains the vulnerability but we are not affected because the vulnerable code path is not reachable." Store VEX documents alongside SBOMs in the artifact registry to carry forward suppression decisions.

Common failure modes

Unpinned dependencies: Using latest container tags or unpinned dependency versions means the build is not reproducible and vulnerabilities can be introduced silently between builds.
Scanning without enforcement: Dependency and image scanning configured to report-only (not block) provides visibility but allows vulnerable code to reach production indefinitely.
SBOM not generated for transitive dependencies: SBOMs that list only direct dependencies miss the vast majority of dependency surface area (transitive dependencies are typically 5–10x more numerous than direct ones).
No process for newly disclosed CVEs: Scanning only on build time misses CVEs disclosed after the last build; continuous monitoring (registry scanning, watchdog processes) is needed to detect post-build CVE disclosures.

Decision checklist

Are SBOMs (CycloneDX or SPDX) generated for all software artifacts including transitive dependencies?
Is dependency scanning integrated into CI/CD and configured to block merges with critical vulnerabilities?
Are container base images pinned by digest and automatically updated via bot PRs?
Are build artifacts signed using Cosign/Sigstore and verified at deployment time?
Is there a vulnerability triage process that distinguishes exploitable from non-exploitable CVEs?
Is continuous monitoring in place to detect CVEs disclosed after the last build?

Example use cases

Log4Shell response: Team with SBOM inventory queries all services for log4j-core in 10 minutes; patches highest-criticality services first; uses VEX to document services that have Log4j as an unreachable transitive dependency and do not require emergency patching.
Government software procurement: Vendor delivers SBOM alongside each software release as required by US Executive Order 14028; procuring agency runs SBOM through their vulnerability scanner to validate no known critical CVEs before deployment.
Kubernetes admission control: Kyverno policy enforces that all production pods use images signed by the CI/CD system's Cosign key; unsigned images from developer laptops are rejected; a compromised CI/CD pipeline producing unsigned artifacts is detected immediately.

Secure SDLC — Supply chain security is a key component of shift-left security.
Container Security — Image scanning and signing are core container security controls.
CI/CD Pipelines — Build pipelines are the implementation point for supply chain security controls.