Software supply chain attacks are running at double the long-term average since mid-2025, approximately 26 attacks per month versus the prior 13 per month. The global cost is forecast at $60 billion in 2025, projected to reach $138 billion by 2031. From the XZ Utils backdoor to the Shai-Hulud npm worm to compromised GitHub Actions (tj-actions/changed-files), attackers have proven that compromising one dependency or build tool can cascade to thousands of downstream victims.
This guide covers practical supply chain security controls spanning dependency management, build integrity, artifact signing, and regulatory compliance.
Supply Chain Attack Surface
Modern software depends on layers of trust, each of which can be compromised:
| Layer | Attack Examples | Impact |
|---|---|---|
| Source code | Compromised maintainer accounts, malicious PRs, social engineering (XZ Utils) | Backdoor in source reaches all downstream consumers |
| Dependencies | Typosquatting, dependency confusion, malicious packages (Shai-Hulud npm worm) | Malware executes during install or import |
| Build system | Compromised CI/CD pipelines, poisoned build tools (SolarWinds) | Malicious code injected into legitimate artifacts |
| Distribution | Compromised registries, hijacked update servers (Notepad++, eScan) | Malware delivered through trusted update channels |
| Development tools | Compromised IDE extensions (GlassWorm VS Code attack), AI assistant manipulation | Developer credentials and infrastructure access stolen |
SBOM: Software Bill of Materials
An SBOM is a machine-readable inventory of every component in a software artifact, including open-source libraries, proprietary modules, and their versions, licenses, and relationships.
Why SBOMs Matter
When a vulnerability like Log4Shell (CVE-2021-44228) is disclosed, the first question is: “Are we affected?” Without SBOMs, answering this requires days or weeks of manual investigation across every application. With SBOMs, the answer is a database query.
SBOM Standards
Two primary formats have stabilized. CycloneDX (OWASP) is security-focused, supports VEX (Vulnerability Exploitability eXchange), and has a lighter specification. SPDX (Linux Foundation, ISO/IEC 5962:2021) is license-compliance focused with broader scope and is an ISO standard.
Both formats are acceptable for regulatory compliance. Choose based on your primary use case. Security teams generally prefer CycloneDX while legal and compliance teams often prefer SPDX.
SBOM Generation
Generate SBOMs at build time, not from deployed artifacts.
Available tools include Syft (Anchore), a multi-format generator for containers, filesystems, and archives. Trivy (Aqua) generates SBOMs alongside vulnerability scanning. cdxgen (CycloneDX) is a language-aware generator supporting 30+ ecosystems. GitHub dependency graph provides automatic SBOM export in SPDX format.
Here’s an integration pattern:
# Generate SBOM in CI/CD pipeline
- name: Generate SBOM
uses: anchore/sbom-action@v0
with:
format: cyclonedx-json
output-file: sbom.cdx.json
- name: Attest SBOM to artifact
uses: actions/attest-sbom@v2
with:
subject-path: dist/
sbom-path: sbom.cdx.jsonSBOM Lifecycle
Generation is the beginning, not the end. Generate at every build since SBOMs must reflect the exact contents of the artifact. Store alongside release artifacts in a registry or artifact repository. Monitor against vulnerability feeds continuously because new CVEs affect existing SBOMs. Share with customers, auditors, and incident responders on request. Update when patching or rebuilding since stale SBOMs are worse than no SBOMs.
SLSA: Supply-chain Levels for Software Artifacts
SLSA (pronounced “salsa”) is a security framework defining increasing levels of build integrity assurance. The current version is SLSA v1.1 (April 2025), with v1.2 in release candidate.
SLSA Levels
| Level | Requirements | What It Prevents |
|---|---|---|
| Level 0 | No guarantees | Nothing, this is just the baseline |
| Level 1 | Build process exists and produces provenance | Ad-hoc builds with no audit trail |
| Level 2 | Provenance is signed and generated by a hosted build service | Tampering after build (artifact swap) |
| Level 3 | Build platform provides strong isolation between builds | Compromise of one build affecting another |
Provenance
SLSA provenance is a signed attestation documenting what was built (artifact digest), from what source (repository, commit, branch), by what build system (GitHub Actions, GitLab CI, Jenkins), and using what build instructions (workflow file, build script).
GitHub Actions now generates signed provenance aligned with SLSA specs via artifact attestations. The Sigstore ecosystem (cosign, Fulcio, Rekor) provides the signing infrastructure.
Achieving SLSA Level 2
For most organizations, SLSA Level 2 is achievable in weeks using existing tooling. Build in a hosted CI/CD service (GitHub Actions, GitLab CI, Cloud Build). Generate provenance using slsa-github-generator or actions/attest-build-provenance. Sign artifacts with cosign using keyless signing via Sigstore/Fulcio. Verify signatures and provenance at deployment using Kyverno, Connaisseur, or cosign verify.
Dependency Management
Package Registry Security
The npm and PyPI ecosystems made significant security improvements in 2025.
For npm, classic tokens have been revoked and all new tokens are granular with scope and expiration. Trusted Publishing eliminates long-lived tokens since GitHub Actions and GitLab CI authenticate via OIDC. TOTP-based 2FA has been deprecated in favor of FIDO-based 2FA for publishers.
For PyPI, 17% of all uploads now include attestations from Trusted Publishing. Automatic typosquatting detection blocks similar-name package registrations. Phishing protection and a hardened upload pipeline have been deployed.
Dependency Vetting
Not all dependencies are equal. Before adopting a new dependency, evaluate maintenance activity (when was the last commit? are issues being addressed?), contributor diversity (is the project maintained by a single person, like XZ Utils was?), security track record (past vulnerabilities and response time), OpenSSF Scorecard (automated security health assessment for open-source projects), and license compatibility (ensure license terms are acceptable for your use case).
Automated Dependency Updates
Use Dependabot or Renovate for automated dependency update PRs. Pin dependency versions in lock files and never use floating ranges in production. Configure automated CI checks to run against dependency update PRs before merging. Set a maximum acceptable age for dependency versions, such as no more than 2 major versions behind.
Defending Against Dependency Attacks
For typosquatting, use GuardDog (OpenSSF) to monitor for suspicious package names. For dependency confusion, configure scoped registries and namespace pinning using .npmrc or pip.conf to specify private registry sources. For slopsquatting, verify AI-suggested package names actually exist in the registry before installing. For malicious updates, use npm audit signatures and pip --require-hashes to verify package integrity.
CI/CD Pipeline Hardening
The CI/CD pipeline is a high-value target. The tj-actions/changed-files compromise (March 2025, CVE-2025-30066) leaked secrets from thousands of repositories through a compromised GitHub Action.
Pipeline Security Controls
Pin action versions to commit SHAs, not tags, because tags can be moved after compromise. Minimize pipeline permissions using the permissions: block in GitHub Actions. Use OIDC federation for cloud access instead of stored secrets. Isolate pipeline secrets so each job only accesses the secrets it needs. Enable branch protection by requiring PR reviews, status checks, and signed commits before merging to main. Audit pipeline changes and treat workflow files as security-critical code.
# Secure GitHub Actions configuration
permissions:
contents: read # Minimal permissions
id-token: write # For OIDC federation only
steps:
# Pin to commit SHA, not tag
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
# Use OIDC instead of stored AWS credentials
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789:role/deploy
aws-region: us-east-1Build Isolation
Run builds in ephemeral, isolated environments and never reuse build containers. Separate build and deploy credentials so the build system does not have production access. Use hermetic builds where possible, meaning builds that don’t depend on external resources at build time. Log and monitor all build system activity for anomalous behavior.
Artifact Signing and Verification
Sigstore Ecosystem
Sigstore provides keyless signing infrastructure for open-source and enterprise software. Cosign signs and verifies container images and artifacts. Fulcio issues short-lived signing certificates based on OIDC identity. Rekor is an immutable transparency log recording all signing events. Gitsign signs Git commits using Sigstore.
Verification at Deployment
Enforce that only signed, verified artifacts can be deployed. For Kubernetes, use Kyverno or Connaisseur as admission controllers to verify image signatures. For AWS, use AWS Signer with CloudTrail audit trails. For Azure AKS, use Image Integrity with Ratify + Azure Policy + Gatekeeper. For container registries, enable image signing requirements in ECR, ACR, or Artifact Registry.
Regulatory Requirements
EU Cyber Resilience Act (CRA)
The CRA entered into force December 10, 2024, with phased compliance. Vulnerability reporting obligations take effect September 11, 2026. Full enforcement including SBOM requirements begins December 11, 2027. Fines go up to EUR 15 million or 2.5% of global turnover. The act applies to all products with digital elements sold in the EU market. Open-source stewards have limited obligations while commercial redistributors bear full responsibility.
US Federal Requirements
EO 14028 and NIST SSDF mandate SBOMs for federal software procurement. CISA expanded minimum SBOM metadata requirements in 2025. Federal contractors must attest to SSDF compliance for software sold to government agencies.
Getting Started
Generate SBOMs for your most critical applications today using Syft or Trivy in CI/CD. Pin and lock all dependency versions and enable automated vulnerability scanning. Sign artifacts with cosign using keyless signing via Sigstore, which requires no key management. Harden CI/CD by pinning action SHAs, minimizing permissions, and using OIDC federation. Monitor dependencies continuously by subscribing to advisories for your top dependencies. Evaluate SLSA Level 2 compliance since most organizations can achieve this quickly with GitHub Actions.