Software Supply Chain Security: What SolarWinds and XZ Utils Changed

The SolarWinds compromise of 2020 was not a novel attack technique. Malicious modifications to software build pipelines had been documented for years in academic research. What changed was scale: a trusted software vendor's update mechanism became a distribution channel for a nation-state implant, ultimately reaching 18,000 customers including US federal agencies. The XZ Utils backdoor in 2024 demonstrated that the same attack surface exists in open-source software that forms the foundation of most internet infrastructure.

What Made SolarWinds Work

The SUNBURST implant was inserted into the SolarWinds Orion build process, signing the malicious code with SolarWinds' legitimate certificate. The implant lay dormant for two weeks after installation, then performed extremely slow, low-volume command-and-control that blended with the legitimate product's network traffic patterns. By the time it was discovered, threat actors had had access to some environments for over a year.

• --Build pipeline access: the attacker modified the source code before compilation, so code review after the fact showed no changes.
• --Legitimate signing: signed with the vendor's code-signing certificate, bypassing signature verification.
• --Long dormancy: no activity for 12-14 days after initial execution to evade sandboxing and automated analysis.
• --Traffic mimicry: C2 communication used the same domain naming convention as legitimate Orion telemetry.

What XZ Utils Demonstrated

The XZ Utils backdoor (CVE-2024-3094) was a years-long social engineering operation. A threat actor using the persona 'Jia Tan' contributed to the xz project for two years, building trust and earning commit access, before inserting a backdoor into the release build process that would have allowed unauthenticated SSH access to any system running the affected version. It was discovered accidentally by a Microsoft engineer noticing unexpected CPU usage.

Software Bill of Materials (SBOM)

An SBOM is a structured list of all components, libraries, and dependencies in a software product, along with their versions and known vulnerabilities. The US Executive Order on Improving the Nation's Cybersecurity (EO 14028) mandated SBOMs for software sold to the federal government, and the practice is spreading into commercial contracts.

# Generate SBOM using Syft (open source, supports SPDX and CycloneDX formats)
syft packages dir:. -o spdx-json > sbom.spdx.json

# Or for a container image
syft packages nginx:latest -o cyclonedx-json > nginx-sbom.json

# Scan SBOM for known vulnerabilities using Grype
grype sbom:sbom.spdx.json

# Example Grype output:
# NAME          INSTALLED   FIXED-IN  TYPE  VULNERABILITY   SEVERITY
# openssl       1.1.1t      1.1.1u    deb   CVE-2023-0464   High
# libcurl4      7.74.0      7.74.0-1  deb   CVE-2023-23914  Medium

Securing the Build Pipeline

# GitHub Actions: Restrict what build steps can do (OIDC + minimal permissions)
name: Build and Sign
on: [push]
permissions:
  contents: read        # minimal: read source only
  id-token: write       # for OIDC token to authenticate to artifact registry

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          persist-credentials: false    # don't leave git credentials around

      - name: Build
        run: make build

      # Sign artifact with Sigstore/Cosign
      - name: Sign artifact
        uses: sigstore/cosign-installer@v3
      - run: cosign sign-blob --yes dist/app --output-signature dist/app.sig

Proportionate Response by Organisation Size