Supply Chain Security

How dependencies became the leading attack vector, and the post-SolarWinds defenses (SBOM, signed artifacts, SLSA).

Overview

Attacks that arrive through your dependencies

Supply chain attacks target what a system relies on, not the system itself. The attacker compromises a library, a package, a CI tool or an infrastructure provider, anything upstream of your code, and your build inherits the compromise.

> [!IMPORTANT] Every stage from source to production is an attack surface. Defenses must let you trace any running artifact back to reviewed source.

Notable incidents

SolarWinds (2020) — Nation-state attackers compromised the build server and injected code into a routine Orion update; 18,000 customers, including major US government agencies, received it; undetected for months
Log4Shell (Dec 2021) — Critical remote code execution in log4j, a ubiquitous Java logging library; an estimated 35% of Java applications affected; the fix was simple, the discovery and rollout a global emergency
xz-utils (March 2024) — A backdoor in the xz compression library from an attacker who spent 3 years building trust as a maintainer; caught by chance through a performance regression; could have compromised most Linux distributions
Codecov (2021) — A compromised bash uploader script exfiltrated CI environment variables, including secrets, for ~2 months

The defenses

1. SBOM — A manifest of every dependency in SPDX or CycloneDX; syft generates, grype scans; tells you what you have when a CVE drops
2. Dependency scanning — Snyk, Dependabot, Trivy, Anchore, Renovate; scan every PR and block on critical vulnerabilities
3. Signed artifacts — Sign images and binaries with Sigstore, cosign or Notary; verify before deploy so unsigned or unknown-key artifacts never run
4. SLSA — A framework of supply chain security levels, from a documented build to hermetic, reproducible, two-party-reviewed builds; any artifact traceable to its source
5. Reproducible builds — Same source gives the same binary byte for byte, exposing tampering; hard in practice because of timestamps and paths
6. Build server hardening — The SolarWinds attack surface; treat it as production: minimal access, full audit, isolation, ephemeral runners; hosted CI helps but still needs care
7. Pinned versions — No floating latest or stable tags; specific or hash-pinned (:sha256:abcd...) versions updated by reviewed PR
8. Vendor due diligence — Who maintains critical dependencies and how they respond to security issues; SOC 2, ISO 27001, FedRAMP audits for cloud providers

Why SREs own it

Pipeline concern — It lives in CI/CD and deploys
Reliability-adjacent — A compromised dependency can break the system
Engineering work — Security teams alone cannot implement it

Minimum viable hygiene (2026)

> [!TIP] Setup takes about 1-2 weeks of SRE time with low ongoing maintenance, an outsized return against a rapidly growing class of attack.

The 2026+ direction

AI-assisted discovery — Finding dependency vulnerabilities
Hardware-rooted attestation — For builds
Confidential computing — For sensitive build steps
Standardized SBOM consumption — Regulators requiring SBOM disclosure

Key concepts

SBOM: Software Bill of Materials. Manifest of every dependency. SPDX or CycloneDX format. syft + grype tools.
Sigstore: Open standard for signing artifacts. cosign tool. Verifies authenticity at deploy.
SLSA: Supply chain Levels for Software Artifacts. 4 levels of supply chain security. Industry framework.
Reproducible builds: Same source → same binary, byte-for-byte. Detects build tampering. Progress over years.
Pinned versions: No floating tags. Specific versions or hash-pinned. Updates via PR review.
Build server as attack surface: Compromised CI = compromised builds. Treat as production. Ephemeral runners.

When to use it

Setting up CI/CD — supply chain hygiene from day 1
Compliance prep — SBOM and signed artifacts increasingly required
Post-incident with dependency root cause — what controls were missing?
Vendor evaluation — supply chain security as criterion

Interview questions

What is SLSA and why does it matter?
How do you respond to a major OSS dependency vulnerability (e.g., Log4Shell)?
How do you sign and verify container images?