Software Supply Chain Attacks: XZ Utils, SolarWinds, and What to Do About Them

The software supply chain has become one of the most consequential attack surfaces in modern security. When a widely-deployed open source library or a trusted software vendor is compromised, the blast radius can encompass thousands of downstream organizations simultaneously — organizations that did everything "right" in terms of their own security practices but trusted a component they had no visibility into.

Anatomy of a Supply Chain Attack

SolarWinds SUNBURST (2020)

The SolarWinds attack remains the defining case study in supply chain compromise at scale. The attackers (attributed to Russia's SVR intelligence service) compromised SolarWinds' build pipeline and injected the SUNBURST backdoor into signed updates of Orion, SolarWinds' network monitoring platform. The malicious update was digitally signed by SolarWinds' own code signing certificate.

The backdoor was dormant for two weeks after installation, blended with legitimate Orion network traffic, and only communicated with command-and-control infrastructure if the infected system was joined to an Active Directory domain with a non-trivial domain name (to avoid sandboxes and test environments). It was deployed to approximately 18,000 organizations, with around 100 receiving hands-on follow-up intrusion activity including 9 US federal agencies.

The attack succeeded because:

1. SolarWinds' build environment was compromised (attackers had access to the build system)
2. The signed update was trusted by all Orion customers with no mechanism to verify build provenance
3. No SBOM existed to inventory what was actually in the Orion binary
4. Detection required behavioral monitoring that most customers lacked

XZ Utils Backdoor (CVE-2024-3094)

The XZ Utils attack is qualitatively different and, in many ways, more alarming because it came close to succeeding without detection. A threat actor using the name "Jia Tan" spent approximately two years contributing legitimate, high-quality code to the xz compression library — a foundational component included in virtually every Linux distribution.

Over that time, "Jia Tan" systematically built trust within the project, eventually becoming a co-maintainer. Once in that position, the attacker introduced obfuscated backdoor code through a multi-stage, highly sophisticated technique:

• The malicious code was hidden in a binary test file (not visible in a normal diff review)
• It patched liblzma to intercept the RSA_public_decrypt function in sshd
• The backdoor would allow the attacker to execute arbitrary code on affected systems if they possessed the correct Ed448 private key, by sending a crafted SSH certificate

The attack was caught almost by accident: Andres Freund, a Microsoft engineer, noticed that SSH connections on his Debian Sid system were taking 500ms longer than expected and consuming unexpected CPU. He traced it to xz-utils and published his findings. Had it shipped in stable releases of major distributions, it would have given the attacker unauthenticated root access to millions of servers worldwide.

The XZ attack illustrates that supply chain risk includes the human element of open source maintainership — there is no automated control that catches a malicious but legitimate-seeming contributor.

The SLSA Framework

Supply-chain Levels for Software Artifacts (SLSA, pronounced "salsa") is a Google-originated framework for incremental supply chain security improvement. It defines four levels of assurance:

SLSA Level 1: Build Provenance Exists

The build process is scripted (not manual), and provenance — metadata describing how an artifact was built — is generated. This level establishes the foundation: if you can't answer "where did this artifact come from?", you can't reason about its trustworthiness.

Provenance at Level 1 is generated by the build system itself and is not verified to be unforgeable.

SLSA Level 2: Hosted Build Service

The build is performed by a hosted CI/CD service (GitHub Actions, Google Cloud Build, etc.) rather than a developer's local machine. The provenance is signed by the build service, making it harder to forge without compromising the service itself.

This means a developer with write access to the repository cannot inject malicious changes into the build output without that change appearing in version history.

SLSA Level 3: Hardened Build Service

The build service itself has stronger security guarantees: the build environment is ephemeral (destroyed after each build, preventing environment poisoning), build scripts cannot inject content into the provenance, and the builder is isolated from the source code it's building.

Level 3 would significantly raise the bar for attacks like SolarWinds — the attacker would need to compromise the hosted CI/CD platform itself rather than just gaining write access to the build server.

SLSA Level 4: Two-Party Review + Hermetic Builds

Level 4 adds two-person review of all changes to the build process and hermetic builds (all build dependencies are pinned, declared, and fetched deterministically — no network access during build). This enables reproducible builds, where an independent party can rebuild the artifact and verify the output is byte-for-byte identical.

Build Provenance in Practice

GitHub Actions supports SLSA provenance generation natively through the actions/attest-build-provenance action. For a Node.js project:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm ci && npm run build
      - name: Generate SLSA provenance
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: dist/

This creates a cryptographically signed attestation linking the output artifact to the specific commit, workflow run, and repository that produced it. Consumers can verify this attestation using the gh attestation verify command.

Dependency Pinning

Unpinned dependencies are a supply chain vulnerability. npm install with a ^ version range in package.json will install the latest compatible version at install time — if a package is compromised between your last build and your next deployment, you get the malicious version.

Pin all production dependencies to exact versions in lockfiles (package-lock.json, yarn.lock, poetry.lock). Commit lockfiles to version control. Use tools like Renovate or Dependabot to automatically open PRs when pinned versions have security updates, maintaining the benefits of staying current without the risk of unpinned installs.

For Docker base images, pin to digest (not tag):

# Vulnerable to tag mutation
FROM node:20-alpine

# Pinned to immutable digest
FROM node:20-alpine@sha256:a1b2c3d4...

SBOM Generation

A Software Bill of Materials is an inventory of all components in your software, analogous to a food ingredient list. SBOMs don't prevent attacks, but they dramatically accelerate response when a new vulnerability is disclosed: instead of auditing every codebase manually, you query your SBOM inventory.

CycloneDX and SPDX are the two dominant SBOM formats. Generate SBOMs as part of your build pipeline:

# Generate CycloneDX SBOM for Node.js
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Generate SPDX SBOM using syft
syft . -o spdx-json=sbom.spdx.json

# For container images
syft nginx:latest -o cyclonedx-json=nginx-sbom.json

Store SBOMs in a central inventory and query them when new CVEs are published. Tools like Grype, Trivy, and SBOM analysis platforms (Anchore, Snyk) can scan SBOMs against vulnerability databases.

Sigstore and Cosign for Artifact Signing

Sigstore is an open source project (backed by Google, Red Hat, and Purdue University) that provides free, transparent, and auditable software signing infrastructure. The key component for artifact signing is Cosign.

Signing a container image:

# Sign using keyless signing (OIDC-based, no key management required)
cosign sign ghcr.io/myorg/myimage:v1.0.0

# Verify the signature
cosign verify ghcr.io/myorg/myimage:v1.0.0 \
  --certificate-identity-regexp="https://github.com/myorg/*" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com"

Keyless signing uses short-lived certificates tied to OIDC identity (GitHub Actions identity, Google service account, etc.) rather than long-lived keys that need to be protected. All signatures are recorded in Rekor, Sigstore's transparency log, creating an auditable record of what was signed and when.

Detecting Anomalous Builds

Behavioral anomaly detection in CI/CD pipelines can catch supply chain attacks that bypass code review:

• Unexpected network connections during build: A legitimate build of a well-known library shouldn't need to call home to an external IP. Network egress monitoring during CI builds catches data exfiltration or C2 beacon installation.
• New executables added to build output: File system monitoring during builds can detect artifacts that weren't produced by declared build steps.
• Dependency hash mismatches: Lock file verification catches cases where a dependency version's published hash doesn't match what was downloaded.
• Binary diffs on releases: Comparing binary artifacts between releases and flagging unexpected additions (like the hidden binary files in XZ Utils) requires tooling but can catch sophisticated attacks.

The XZ Utils attack survived for months in testing repositories. Widespread adoption of SLSA Level 2+ builds, reproducible builds, and automated binary analysis would significantly reduce dwell time for similar attacks. Supply chain security is not a solved problem, but the tooling available in 2025 makes meaningful progress tractable for organizations willing to invest in the build pipeline as a security surface.