Chapter 24: Supply Chain Attacks¶

Overview¶

Supply chain attacks compromise software, hardware, or services upstream of the intended target, allowing a single breach to cascade to thousands of downstream victims. The SolarWinds compromise infected 18,000 organizations through a legitimate software update. The XZ Utils backdoor nearly compromised every major Linux distribution. The MOVEit zero-day exploited managed file transfer software used by thousands of enterprises. This chapter analyzes supply chain attack vectors, high-profile case studies, detection strategies, and defense frameworks including SLSA, SBOM, and secure software development lifecycle (SSDLC).

Learning Objectives¶

By the end of this chapter, students SHALL be able to:

1. Categorize supply chain attack vectors across software, hardware, and managed services
2. Analyze SolarWinds, SolarWinds, XZ Utils, and 3CX as case studies
3. Implement Software Bills of Materials (SBOM) and vulnerability tracking
4. Apply SLSA framework levels to software supply chain security
5. Design CI/CD pipeline security controls against build-time attacks
6. Assess third-party vendor risk in managed services and open source dependencies

Prerequisites¶

• Basic understanding of software development and CI/CD pipelines
• Familiarity with package management (npm, pip, Maven)
• Chapter 3 (Data Modeling) and Chapter 7 (Threat Intelligence) foundations

24.1 Supply Chain Attack Taxonomy¶

graph TB
    A[Supply Chain Attacks] --> B[Software Supply Chain]
    A --> C[Hardware Supply Chain]
    A --> D[Managed Service\nProvider / MSP]

    B --> B1[Build Environment\nCompromise\nSolarWinds, 3CX]
    B --> B2[Dependency\nConfusion / Typosquatting\nnpm, pip, Maven]
    B --> B3[Open Source\nRepository Poisoning\nXZ Utils, event-stream]
    B --> B4[Update Mechanism\nHijacking\nAsu, CCleaner]
    B --> B5[CI/CD Pipeline\nCompromise]

    C --> C1[BIOS/Firmware\nImplants]
    C --> C2[Counterfeit\nComponents]
    C --> C3[Hardware\nInterception]

    D --> D1[IT Support\nTools - Kaseya]
    D --> D2[Cloud Management\nPlatforms]
    D --> D3[Professional Services\nCompromise - Cloud Hopper]

    style B1 fill:#e63946,color:#fff
    style B3 fill:#e63946,color:#fff
    style D1 fill:#f4a261,color:#000

24.2 Case Studies¶

24.2.1 SolarWinds SUNBURST (2020)¶

Attack Type: Build environment compromise → trojanized software update Attribution: APT29 (SVR) Scale: 18,000 organizations received backdoored update; 100+ organizations deeply compromised

Attack Timeline:

Technical Mechanism:

SUNSPOT (Build System Backdoor):
1. Monitored MSBuild process for SolarWinds.Orion.Core.BusinessLayer.dll compilation
2. Intercepted compilation and replaced source file with trojanized version
3. Restored original source after compilation to avoid detection in source control
4. Trojanized DLL signed with legitimate SolarWinds code signing certificate

SUNBURST (Backdoor DLL):
1. Slept for 12-14 days after install (evade sandbox analysis)
2. Validated environment: checked for security tools, sandbox artifacts, security domain names
3. Used DGA to contact avsvmcloud.com (subdomain encoded victim org name in base32)
4. Fingerprinted victim, reported to C2 for selection
5. High-value targets received TEARDROP/RAINDROP second-stage payloads
6. Used legitimate cloud services (Office 365, Azure AD) as C2 after initial contact

Detection Opportunities (all missed at the time): - SolarWinds Orion process making outbound DNS queries to avsvmcloud.com - Unusual SAML token generation from SolarWinds service account - Long-lived OAuth tokens issued to "suspicious" application names - Lateral movement from SolarWinds server to high-value targets

24.2.2 XZ Utils Backdoor (CVE-2024-3094)¶

Attack Type: Long-term social engineering of open source maintainer → code implant Actor: JiaT75 (suspected Chinese state actor) Scale: Nearly shipped with OpenSSH in Fedora, Debian, openSUSE (caught just before release)

Social Engineering Timeline (2 years):

Technical Mechanism: - Backdoor injected into liblzma.so during build - Targeted systemd via its dependency on liblzma for OpenSSH authentication - RSA key decode function patched to allow a specific Ed448 public key to authenticate without credentials to any SSH server using the backdoored liblzma - The backdoor key was embedded in the malicious test files

Lessons: Nation-states invest years in social engineering open source maintainers. Any widely-used open source project is a high-value target.

24.2.3 3CX Supply Chain Attack (2023)¶

Attack Type: Second-stage supply chain — infected 3CX's dependency Attribution: Lazarus Group (North Korea) Scale: 600,000+ organizations use 3CX; thousands received malicious update

Mechanism: 1. Compromised trading software Trading Technologies X_TRADER (itself via supply chain attack) 2. X_TRADER installer infected 3CX developer machine 3. 3CX build environment compromised via infected developer credentials 4. Malicious DLL (d3dcompiler_47.dll) included in legitimate 3CX update 5. Organizations that installed 3CX update received ICONICSTEALER (data theft) then GOPURAM backdoor

First publicly known second-order supply chain attack — compromising a target via a compromised software component.

24.2.4 Kaseya VSA (2021)¶

Attack Type: MSP management tool zero-day exploitation Attribution: REvil ransomware affiliate Scale: 60 MSPs → 1,500 downstream businesses encrypted

Mechanism: - Zero-day in Kaseya VSA (CVE-2021-30116) — authentication bypass in web interface - Kaseya VSA runs as privileged agent on all managed endpoints - Attacker deployed ransomware as "policy" via legitimate Kaseya management channel - No malware needed — ransomware deployed via trusted MSP tool

24.3 Open Source Dependency Attacks¶

24.3.1 Dependency Confusion¶

Dependency confusion exploits how package managers resolve package names — tricking them into downloading a malicious public package over a legitimate private one.

# Attacker's approach:
# 1. Discover internal package names (often visible in job postings, error messages, public code)
# 2. Register identically-named package on public registry (PyPI, npm, RubyGems)
# 3. Set version number HIGHER than internal package
# 4. Package managers download highest version → attacker's package wins

# Example discovery method:
# Search GitHub for "import internal-package-name" or "require('corp-internal-lib')"

# Defense: Pin dependencies with exact versions AND hashes
# pip requirements.txt:
requests==2.31.0 --hash=sha256:58cd2187...
# npm package-lock.json with integrity hashes
# Maven settings.xml with checksum policies

24.3.2 Typosquatting¶

Legitimate package → Malicious typosquat:
requests        → reqeusts, reqests, request
lodash          → 1odash (uses numeral 1)
react           → reakt, reacts
boto3           → botto3, bot03
django          → djanjo, diango

# Typosquatting detection tools
pip install safety  # checks installed packages against known malicious
npm audit
# PyPI Guardian — ML-based suspicious package detection
# Socket.dev — npm/PyPI supply chain security
# Snyk — dependency vulnerability + license scanning

24.3.3 Malicious Package Detection¶

# Bandit — Python security static analysis
pip install bandit
bandit -r ./src/

# npm audit — check for known vulnerabilities
npm audit --audit-level=high

# Retire.js — JavaScript component vulnerability scanner
retire --path ./src/

# OWASP Dependency-Check
dependency-check --project "MyApp" --scan ./lib/ --format HTML

# Trivy — container + filesystem vulnerability scanner
trivy fs --exit-code 1 --severity HIGH,CRITICAL ./

24.4 CI/CD Pipeline Security¶

24.4.1 CI/CD Attack Surface¶

graph LR
    A[Developer\nWorkstation] -->|git push| B[Source Control\nGitHub/GitLab]
    B -->|webhook trigger| C[CI Server\nJenkins/GitHub Actions]
    C -->|fetch deps| D[Package Registry\nnpm/PyPI]
    C -->|pull image| E[Container Registry\nDocker Hub]
    C -->|build artifact| F[Artifact Registry\nNexus/JFrog]
    F -->|deploy| G[Production]

    B -.->|attack: secrets in code| H[Attacker]
    C -.->|attack: pipeline injection| H
    D -.->|attack: typosquatting| H
    E -.->|attack: base image malware| H
    F -.->|attack: artifact tampering| H

    style H fill:#e63946,color:#fff

24.4.2 CI/CD Security Controls¶

# GitHub Actions — secrets scanning, dependency pinning
name: Secure Build Pipeline

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write

    steps:
      # Pin actions to specific SHA (not tag — tags can be moved)
      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11  # v4.1.1

      # Dependency vulnerability scanning
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@7b7aa264d83dc58691451798b4d117d53d21edfe  # v0.23.0
        with:
          scan-type: 'fs'
          scan-ref: '.'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'

      # Secret scanning
      - name: Gitleaks secret scan
        uses: gitleaks/gitleaks-action@cb7149a9b57195b609c63e8518d2c6ef0784a5b3  # v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      # SAST
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: "p/security-audit"

      # Sign artifacts
      - name: Sign build artifacts with Cosign
        uses: sigstore/cosign-installer@v3
        run: |
          cosign sign --yes ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

24.5 SLSA Framework¶

SLSA (Supply-chain Levels for Software Artifacts) — pronounced "salsa" — is a Google-developed framework providing incremental supply chain security levels.

# Generate SLSA provenance with GitHub Actions
# Uses SLSA GitHub Generator action
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.9.0

# Verify SLSA provenance
slsa-verifier verify-artifact myapp.tar.gz \
  --provenance-path provenance.intoto.jsonl \
  --source-uri github.com/org/myapp \
  --source-tag v1.0.0

24.6 Software Bill of Materials (SBOM)¶

An SBOM is a machine-readable inventory of all software components, their versions, licenses, and relationships — like an ingredients list for software.

24.6.1 SBOM Formats¶

# Generate SBOM with Syft
syft packages dir:. -o cyclonedx-json > sbom.json

# Generate for container image
syft ghcr.io/org/myapp:latest -o spdx-json > container-sbom.json

# Scan SBOM for vulnerabilities with Grype
grype sbom:sbom.json

# Integrate in CI/CD
syft packages . -o cyclonedx-json | grype --fail-on high

24.6.2 SBOM Workflow¶

sequenceDiagram
    participant DEV as Developer
    participant CI as CI/CD Pipeline
    participant REG as Artifact Registry
    participant SEC as Security Team
    participant VDB as Vuln Database

    DEV->>CI: Push code
    CI->>CI: Build application
    CI->>CI: Generate SBOM (Syft)
    CI->>CI: Scan SBOM (Grype)
    CI-->>DEV: Block if critical CVE found
    CI->>REG: Push artifact + signed SBOM
    REG->>VDB: Subscribe to NVD/OSV feeds
    VDB-->>SEC: Alert: New CVE in component you use
    SEC->>DEV: Emergency patch request

24.7 Third-Party Risk Management¶

24.7.1 Vendor Assessment Criteria¶

CRITICAL VENDORS (high access to systems/data):
├── Software development: SLSA level ≥ 2, SOC2 Type II, pentest report
├── Security tools (EDR, SIEM, SOAR): highest scrutiny — these have deep OS access
├── MSPs/MSSPs: 4th party risk assessment of their key vendors
└── SaaS with sensitive data: CSA STAR certification, DPA, audit rights

STANDARD VENDORS:
├── SOC2 Type II or equivalent
├── Security questionnaire (CAIQ, SIG, VSAQ)
├── Cyber insurance verification
└── Incident notification requirements (SLA <24 hours)

24.7.2 Contractual Protections¶

Supply chain security SHALL be contractually enforced:

KEY CONTRACT PROVISIONS:
1. Right to audit — conduct security assessments of vendor
2. Incident notification — require notification within 24-72 hours of breach
3. Access controls — vendor access limited to minimum necessary
4. Sub-processor disclosure — all 4th parties must be disclosed
5. Data return/destruction — upon contract termination
6. Security standards — SOC2/ISO27001 maintenance required
7. MFA requirement — vendor personnel accessing your systems must use MFA
8. Background checks — vendor employees with privileged access screened

24.8 Benchmark Controls¶

Exam Prep & Certifications¶

Key Terms¶

SBOM (Software Bill of Materials) — A machine-readable inventory of all components, libraries, and dependencies in a software artifact, along with version and licensing information.

SLSA (Supply-chain Levels for Software Artifacts) — A Google-developed framework for incremental supply chain security improvement, defining four levels of build integrity assurance.

SUNBURST — The backdoor malware delivered via the trojanized SolarWinds Orion update in 2020, attributed to APT29.

SUNSPOT — The build system implant used by APT29 to intercept SolarWinds Orion compilations and replace legitimate code with SUNBURST.

Typosquatting — Registering malicious package names that are slight misspellings of popular packages to trick developers into installing them accidentally.

Dependency Confusion — A supply chain attack that tricks package managers into downloading a malicious public package by registering the same name with a higher version number than the internal package.