What is software supply chain security?
Updated November 14, 2026
Software supply chain security is protecting everything your software is built from that isn't your own code: open-source packages, container images, build and CI systems, and the vendors and services you run on. Attackers target the supply chain because one compromised package, build step or vendor reaches every team downstream at once. Defending it takes three things: knowing what you depend on, checking it before it ships, and finding out fast when something you already run turns out to be compromised.
What the software supply chain includes
- Dependencies: the open-source packages in your lockfiles, and the packages they pull in.
- Container images: base images and everything installed in them.
- Build and CI/CD: GitHub Actions and other CI steps, build tools, and the secrets your runners hold.
- Artifacts and registries: the packages, binaries and images you publish, and where they're stored.
- Runtimes and infrastructure: language runtimes, databases and managed cloud services, each with an end-of-life date.
- Vendors and services: the SaaS and APIs your code calls, which hold your keys and data.
- People and machines: maintainers' accounts, and developers' laptops, where packages get installed first.
How supply chain attacks happen
Each kind of attack below has happened, at scale. The links go to the official record.
| Attack | Real example | What it reached |
|---|---|---|
| A malicious version of a real package | event-stream (opens in a new tab), npm, 2018: a new maintainer added a dependency carrying code aimed at a bitcoin wallet app | Every project that installed the update |
| A self-spreading worm | Shai-Hulud (opens in a new tab), npm, 2025: stolen tokens were used to publish infected versions of the victims' own packages; CISA counted over 500 compromised packages | Developers' and CI's tokens and credentials |
| A backdoor from a trusted contributor | xz-utils (opens in a new tab), 2024: malicious code in the release tarballs from xz 5.6.0, found before it reached most stable Linux releases | liblzma, and through it SSH on some Linux systems |
| A compromised build system | SolarWinds Orion (opens in a new tab), 2020: a backdoor inserted into the product's build shipped to customers in signed updates | Government agencies and companies running Orion |
| A tampered CI tool | Codecov (opens in a new tab), 2021: its Bash Uploader script was modified without permission | Credentials, tokens and keys passing through customers' CI |
| A hijacked GitHub Action | tj-actions/changed-files (opens in a new tab), 2025: tags v1 to v45.0.7 were pointed at a malicious commit that exposed secrets in workflow logs | CI secrets of every repository using the action by tag |
| An exploited dependency vulnerability | Log4Shell (opens in a new tab), 2021: remote code execution in Apache Log4j 2 through attacker-controlled log messages | Java applications that logged attacker-controlled input |
| A breached vendor | Qubole, 2026: its access to customer AWS accounts was abused to steal secrets and data | Customers' AWS accounts |
How to secure the software supply chain
- Know what you run. Keep an inventory of each repo's packages, images, actions and runtimes, and an SBOM for what you ship. You can't check what you don't know you have.
- Check dependencies before they land. Scan for known vulnerabilities, put the ones attackers already exploit first (CISA KEV), check new packages for malicious behavior, and let brand-new releases age a few days before update bots propose them (Renovate vs Dependabot shows how).
- Harden CI. Pin third-party actions to a commit SHA, give workflows only the permissions they need, and keep long-lived secrets out of runners where you can.
- Sign what you ship. Signatures and build provenance let your users verify an artifact came from your build.
- Protect maintainer and developer accounts. Phishing-resistant MFA on GitHub and package registries, and short-lived publishing tokens where the registry supports them.
- Plan the response. Decide before an incident who owns each repo, how they'll hear about it, and how secrets get rotated.
Software supply chain security tools lists the tools for each of these jobs, with their free options.
Frameworks and standards
- SLSA (opens in a new tab) (Supply-chain Levels for Software Artifacts): levels for how tamper-resistant your build and its provenance are.
- NIST SSDF, SP 800-218 (opens in a new tab): the Secure Software Development Framework, the practices US federal agencies expect from their software suppliers.
- CISA's recommended practices (opens in a new tab): Securing the Software Supply Chain, written for software customers, with companion guides for developers and suppliers.
- OWASP Software Supply Chain Security Cheat Sheet (opens in a new tab): technical controls across the development lifecycle.
- OpenSSF Scorecard (opens in a new tab): automated checks of an open-source project's security practices.
When an attack hits your stack
Prevention lowers the odds; it doesn't make them zero. When a package, action or vendor you use is compromised, the work is the same every time: find every repo and machine with the affected version, tell the people who own them, rotate the secrets those environments could reach, and pin a safe version. Without an inventory, that takes days of grepping and Slack threads.
Pharon keeps that inventory from a local scan of each repo (names, versions and file paths only), matches it against new incidents from OSV.dev, CISA's Known Exploited Vulnerabilities list, endoflife.date and security news, and alerts the team that owns the repo within minutes by email, Slack or webhook. /pharon:check-incident then checks a machine read-only and names the secrets to rotate. Checking against any public notice is free with no account; alerts start at $12 a month, with a 7-day trial and no card.
Questions
- What is software supply chain security in simple terms?
- Making sure the packages, tools and services your software is built from haven't been tampered with, and finding out quickly when one of them has.
- What is a software supply chain attack?
- An attack that compromises something your software depends on, such as an open-source package, a build tool, a CI action or a vendor, so that it reaches you and everyone else who uses it.
- What is a secure software supply chain?
- One where you know every component you use, check components before they're built in, can prove where your own artifacts came from, and can find and fix every affected place quickly when a component turns out to be compromised.
- Is an SBOM enough?
- No. An SBOM lists what went into a build. It doesn't say whether a component is malicious, whether a laptop installed a bad version, or which secrets to rotate. It's a useful record, not a defense on its own.
- What is SLSA?
- Supply-chain Levels for Software Artifacts, an OpenSSF framework with levels for how tamper-resistant a build is and how well its provenance is recorded.
See the latest supply chain incidents, or the tools for each job.