Modern applications are assembled more than they are written. A typical service pulls in hundreds of transitive packages, a base container image, third-party GitHub Actions and cloud-managed build tools, and an attacker can use any one of them as a way in. Software supply chain security is the practice of protecting every component, tool, person and process involved in building and delivering software: source code, open-source dependencies, CI/CD pipelines, artifact registries and the workloads running in production. SolarWinds, Log4j and a steady run of malicious npm and PyPI packages show the business impact. One poisoned update or library can reach thousands of downstream customers, expose cloud credentials and force weeks of rebuilds. As of October 2026, regulators, auditors and enterprise buyers expect vendors to prove what is in their software and how it was built. This guide covers how attacks happen, the main frameworks and the controls that work at each stage of the lifecycle.
Key takeaways
- ✓Software supply chain attacks target trust in dependencies, build systems and update channels rather than flaws in an application’s own code.
- ✓The most common entry points are compromised packages, typosquatting and dependency confusion, poisoned CI/CD workflows, and stolen pipeline secrets.
- ✓SLSA, NIST SSDF (SP 800-218), SBOM standards and Sigstore cover different layers, so organizations need to combine them rather than pick one.
- ✓Pinning dependencies by hash, signing artifacts and verifying provenance at deployment block most tampering before it reaches production.
- ✓Runtime monitoring catches the attacks that pass every pre-deployment check, such as a trojanized package making unexpected outbound connections.
How the software supply chain works
Source code and third-party components pass through six stages before they run as software, and each stage has its own attack surface. OWASP defines the supply chain as “a collection of steps that create, transform, and assess the quality and policy conformance of software artifacts.”
- Source: developers, repositories (GitHub, GitLab) and code review.
- Dependencies: open-source libraries, transitive packages and public registries (npm, PyPI, Maven, Docker Hub).
- Build and CI/CD: runners, build scripts, plugins and the secrets they hold.
- Artifact storage: container registries and package repositories.
- Deployment: Kubernetes clusters, serverless platforms and admission controls.
- Runtime: the processes, network connections and identities in production.
Teams often conflate software supply chain security with adjacent disciplines. The table shows where each one stops.
| Discipline | What it protects | What it does not cover |
|---|---|---|
| Software supply chain security | The integrity of every input, process and artifact from source to runtime | Business logic flaws in your own code |
| Application security | Your own code: injection, authentication, authorization flaws | Tampered builds or poisoned upstream packages |
| Open-source security | Known vulnerabilities and license risk in third-party packages | Build pipelines, signing and deployment |
| CI/CD security | Runners, workflows, pipeline permissions and secrets | What happens to artifacts after release |
| Code signing | Proof that an artifact came from a known publisher and was not altered | Whether the signed code was safe to begin with |
Software supply chain attack risks
The most common software supply chain risks are compromised dependencies, insecure build pipelines, malicious updates, vulnerable tooling, and weak visibility and access control. OWASP elevated Software Supply Chain Failures to A03 in its 2025 Top 10 because these issues now drive so many breaches. The matrix below maps each risk to the control that addresses it.
| Risk | How it happens | Primary mitigation |
|---|---|---|
| Compromised or malicious packages | Maintainer account takeover or a malicious version pushed to npm or PyPI | Pin by hash, quarantine new versions, use internal registry mirrors |
| Typosquatting and dependency confusion | Look-alike names, or public packages that shadow internal package names | Private registries, namespace scoping, explicit registry resolution |
| CI/CD compromise | Poisoned third-party actions, broad runner permissions, long-lived secrets | Ephemeral runners, actions pinned to commit SHAs, short-lived OIDC credentials |
| Artifact tampering | Images or binaries altered between build and deploy | Signing plus provenance attestation, verified at admission |
| Insecure container images | Vulnerable base or inherited layers carried into production | Minimal base images, digest pinning, rebuilds on base updates |
| Hidden transitive dependencies | Vulnerable components nobody knew were present | SBOMs tracked against vulnerability feeds |
| Malicious updates | A vendor’s update channel is compromised | Vendor attestations, egress controls, behavioral monitoring |
Software supply chain failures: real incidents and lessons
The most damaging supply chain failures broke trust in a component, tool or update path that defenders assumed was safe. Each one points to a specific control.
- ✓SolarWinds (2020): attackers inserted malicious code into a trusted product update. Lesson: verify build integrity with provenance and hermetic, isolated builds.
- ✓Log4j (December 2021): one flaw in a ubiquitous logging library hit systems everywhere. Lesson: an SBOM tells you where a library runs in minutes rather than weeks.
- ✓XZ Utils and 3CX DesktopApp: an upstream backdoor and a trojanized vendor application. Lesson: vetting a trusted supplier once is not enough, so monitor suppliers continuously.
- ✓Codecov: a tampered script exposed CI environment variables. Lesson: verify checksums of anything a pipeline downloads and keep secrets short-lived.
- ✓PyPI typosquat campaign (2026): packages imitating boto3, requests and numpy ran on import and stole AWS credentials, SSH keys and environment variables. Lesson: restrict installs to an approved registry.
- ✓GitHub Actions poisoned workflow (2026): a compromised maintainer account added a malicious step to a widely used Docker build action, which exfiltrated cloud credentials over DNS. Lesson: pin actions to SHAs and monitor runner egress.
- ✓Shai-Hulud npm worm: self-propagating malware spread through the package ecosystem. Lesson: block install scripts by default and rotate tokens quickly.
Software supply chain security frameworks
Organizations can improve software supply chain security with SLSA, NIST SSDF and related NIST publications, SBOM standards, in-toto and Sigstore. Each covers a different layer, so they work best together. In the US, Executive Order 14028 pushed much of this into procurement, and NIST’s software supply chain security guidance defines what federal suppliers must attest to.
| Framework or standard | Focus | How teams use it |
|---|---|---|
| SLSA (OpenSSF) | Build integrity and provenance | Progressive build levels: scripted builds with provenance, then hosted builds with signed provenance, then hardened, isolated builders |
| NIST SP 800-218 (SSDF) | Secure development practices | Practice groups (prepare, protect, produce, respond) used as the basis for secure development attestation |
| NIST SP 800-161 / 800-53 / 800-204D | Supplier risk, security controls, CI/CD pipelines | Supplier risk programs, control catalogs and DevSecOps pipeline guidance |
| SPDX and CycloneDX | SBOM formats | Machine-readable component inventories exchanged with customers and tools |
| in-toto | Attestation format | Signed statements about each pipeline step; SLSA provenance uses it |
| Sigstore / Cosign | Signing | Keyless, OIDC-anchored signing and verification of images and artifacts |
| S2C2F (OpenSSF) | Consuming open source | Maturity levels for ingesting, scanning and mirroring OSS packages |
SSDF describes what your development process should do, SLSA proves how an artifact was built, SBOMs list what is inside it, and Sigstore proves who produced it. Customers increasingly ask for all four.
Best practices across the lifecycle
Organize software supply chain controls by lifecycle stage, so that every hand-off between source, build, registry and runtime gets a verification step.
Source and dependencies
- ✓Enforce MFA and branch protection, and require reviews on every merge.
- ✓Run static code scanners (SAST) on first-party code in pull requests.
- ✓Use software composition analysis tools to track direct and transitive dependencies and license risk.
- ✓Pin dependencies with lockfiles and hashes (for example,
pip --require-hashesornpm ci), never floating “latest” tags.
Build and CI/CD
- ✓Use ephemeral, isolated runners and least-privilege workflow tokens.
- ✓Replace stored secrets with short-lived OIDC credentials scoped per job.
- ✓Pin third-party actions to commit SHAs and audit workflows with a tool such as zizmor. Our guide to CI/CD security tools covers more options.
- ✓Generate SLSA provenance and a CycloneDX or SPDX SBOM for every build, then sign both with Cosign.
Deployment and runtime
- ✓Reference images by digest and verify signatures and provenance with Kubernetes admission policies (Kyverno or OPA Gatekeeper).
- ✓Detect drift by alerting when a container runs binaries that were not in its image.
- ✓Monitor behavior for unexpected outbound connections, credential access or new processes.
Roadmap and metrics
- First 30 days: inventory repositories and pipelines, enforce MFA, pin actions and dependencies.
- By 90 days: generate SBOMs for all production services, sign images, move CI to OIDC credentials.
- By 12 months: reach SLSA Build Level 3 for critical services, enforce admission verification, run supplier attestation reviews.
Track progress with a short set of metrics: percentage of builds signed, provenance coverage, percentage of assets with SBOMs, percentage of dependencies pinned, time to patch critical dependencies and policy violations per release. A common mistake is generating SBOMs nobody queries, or signing images without enforcing verification at deploy time.
How Upwind supports software supply chain security
Upwind extends supply chain controls into production, where scanners and signatures stop and real attacker behavior starts. Its lightweight eBPF sensors see what is actually running, so teams can tell which vulnerable packages are loaded and reachable instead of chasing every CVE an SBOM lists. Upwind combines vulnerability management, Kubernetes security, CIEM and cloud detection and response on one platform. A trojanized dependency that steals credentials or opens an unexpected connection therefore appears as a runtime threat tied to the workload and identity involved. Its Agentic Pack AI agents investigate threats, validate exposure and generate fixes. Upwind is runtime-first, so teams that want a dedicated code-signing or build-provenance tool will still pair it with pipeline-level tooling.
- ✓Prioritize dependency CVEs by runtime reachability
- ✓Detect suspicious behavior from compromised packages in production
- ✓Correlate workloads, identities and cloud posture in one platform
Responding to a supply chain compromise
Trace every place the bad component reached, revoke trust in it and rebuild from a known-good state.
- Scope: query SBOMs and provenance to find every build, image and environment that includes the affected package or version.
- Contain: block the version in internal registries and admission policies, and isolate running workloads that show suspicious behavior.
- Revoke and rotate: rotate CI secrets, cloud credentials and signing keys the component could reach, and revoke compromised tokens.
- Rebuild: rebuild artifacts from verified sources on clean runners, re-sign them and regenerate SBOMs.
- Verify: confirm through runtime monitoring that no malicious processes or connections remain.
- Notify: inform affected customers with updated SBOMs and remediation guidance.
Can you answer “are we affected?” within an hour of a new advisory? If not, start with SBOM coverage.
Strong software supply chain security comes down to visibility, verification and hardening at every hand-off, starting with the first dependency a developer installs and ending with the process running in production.
FAQ
What is software supply chain security?
Software supply chain security is the practice of protecting every component, tool, person and process involved in building and delivering software, from source code and open-source dependencies to CI/CD pipelines, artifact registries and production workloads.
What are the most common software supply chain risks?
The most common risks are compromised or malicious packages, typosquatting and dependency confusion, poisoned CI/CD workflows, stolen pipeline secrets, artifact tampering, insecure container images, hidden transitive dependencies and malicious vendor updates.
How do SLSA, NIST SSDF, SBOMs and Sigstore differ?
SSDF defines what secure development practices your process should follow, SLSA proves how an artifact was built, SBOMs list what components are inside it, and Sigstore provides signing and verification to prove who produced it. The article recommends combining them because each covers a different layer.
Which controls block most software supply chain tampering?
The article highlights pinning dependencies by hash, using private registries and explicit registry resolution, running builds on ephemeral isolated runners, replacing stored secrets with short-lived OIDC credentials, signing artifacts, generating provenance and SBOMs, and verifying signatures and provenance at deployment.
Why is runtime monitoring still needed if builds and artifacts are verified?
Runtime monitoring catches attacks that pass pre-deployment checks, such as a trojanized package making unexpected outbound connections, accessing credentials or launching new processes in production.