What Is Software Supply Chain Security? A 2026 Guide
What is Software Supply Chain Security? Explore the rise of software supply chain attacks and discover the pivotal factors driving these breaches.
Larry Pesce
VP of Services
TL;DR: Software supply chain security is the practice of protecting every component, tool, and process that touches your code, so nothing gets tampered with or slips through with a known flaw. Open source now appears in 98% of codebases, and the attacks against it are automated. From 11 September 2026, EU rules require manufacturers to report actively exploited vulnerabilities within 24 hours.
From 11 September 2026, anyone selling connected products into the EU has 24 hours to report an actively exploited vulnerability. That covers products you shipped years ago, and you cannot report what you cannot find.
Most software isn't written. It's assembled. Your team pulls in open-source libraries, vendor SDKs, and build tools, then ships the result to customers. Every one of those parts is a door.
Software supply chain security is how you make sure none of those doors were left open, or propped open by someone else.
This guide covers what the chain contains, how attacks work now, what September requires, how to triage, and why the software you scanned isn't the software you shipped.
What is software supply chain security?
Software supply chain security protects everything and everyone that touches your code, from development through the build pipeline to what actually ships, against tampering, malicious components, and known vulnerabilities.
It works by giving you two things you can't defend without: visibility and proof. First you build an accurate inventory of every component in a product, including the ones buried deep in dependencies. Then you check that inventory against known vulnerabilities, license risk, and tampering, and you keep checking as new flaws surface. A software bill of materials (SBOM), a machine-readable list of the ingredients inside your software, is the backbone of that inventory. Our guide to SBOMs and software supply chain security covers how to build and use one.
The chain is bigger than most people picture. It includes your own code, third-party and open-source libraries, the registries you pull from, your CI/CD pipeline, and the build and signing steps that turn source into a shipped artifact. A weakness in any one of those links becomes a weakness in the finished product.
The scale is measured, not estimated. Black Duck's 2026 Open Source Security and Risk Analysis report audited 947 codebases across 17 industries between November 2024 and October 2025, and found open source in 98% of them. The direction of travel matters more: mean open-source vulnerabilities per codebase rose 107% in a single year, from 280 to 581. That is the first doubling in the report's eleven-edition history.
Each link fails differently, and each has its own first line of defense. For a ranked view of what is hitting connected products, see our roundup of the top software supply chain threats.
| Threat | How it works | First line of defense |
|---|---|---|
| Vulnerable or outdated components | A known flaw sits in a library you shipped and never patched | Continuous inventory plus exploitability-based prioritization |
| Transitive dependency attacks | A flaw or backdoor hides in a dependency of a dependency | An SBOM that captures transitive dependencies, not just top-level ones |
| Malicious packages | An attacker publishes a poisoned package, or typosquats a real one, in a public registry | Package validation, checksums, trusted sources |
| CI/CD pipeline compromise | Attackers tamper with the build system so malicious code enters during the build | Least-privilege access, signed builds, build integrity checks |
| Code-signing and update hijacking | A trusted update channel is subverted to deliver malicious code | Provenance verification, signature checks |
What does a software supply chain attack look like in 2026?
A software supply chain attack compromises a trusted third party so the attacker reaches the real target indirectly, riding in on software the victim already trusts. Because the code arrives from a trusted source, it walks past defenses built to stop outsiders.
Most people still picture SolarWinds: a patient operator, a signed update, one compromised vendor. That picture is four years old, and it produces the wrong defenses.
What is running now is automated. In September 2025, a self-replicating worm called Shai-Hulud began spreading through the npm registry after a maintainer phishing campaign. It harvests credentials, runs secret-scanning tools against the machine it lands on, queries cloud metadata endpoints, and publishes what it finds to public GitHub repositories. Then it uses the stolen npm token to authenticate as the compromised developer, inject itself into that developer's other packages, and republish them. No operator required. CISA issued an alert on 23 September 2025.
It has not stopped escalating. Shai-Hulud 2.0 moved execution from post-install to pre-install, so malicious code ran before any test or security check, and it reached more than 25,000 malicious repositories while compromising maintainer accounts at Zapier, PostHog, and Postman. In May 2026, a variant became the first campaign to hit npm and PyPI in one coordinated operation. A wave in August 2026 compromised more than 1,300 package versions representing two billion monthly downloads, including caching libraries like keyv and flat-cache.
One detail matters more than the numbers. Pulling the compromised package does not end the compromise. Credentials stolen while it was installed stay valid, so cleanup means rotating tokens and auditing CI/CD runners, not just bumping a version.
SolarWinds in 2020, Log4Shell in 2021, and the XZ Utils backdoor in 2024 remain the reference cases. Shai-Hulud is what the reference case looks like when nobody has to be at the keyboard.
What changes on September 11, 2026?
Most coverage of the EU Cyber Resilience Act points at December 2027. That is the wrong date to plan around.
The CRA is Regulation (EU) 2024/2847, in force since 11 December 2024. Its full product security requirements do apply on 11 December 2027. But Article 14, the vulnerability reporting obligation, starts on 11 September 2026, and it runs on a clock:
- 24 hours from becoming aware: early warning to your national CSIRT and ENISA through the CRA Single Reporting Platform
- 72 hours: a full notification with technical specifics
- 14 days after a corrective measure is available: the final report
- One month for the final report on severe incidents
You file once, through the Single Reporting Platform, which the European Commission confirmed in June 2026 would be operational for the September date.
Two details decide how much work this is. The obligation triggers on actively exploited vulnerabilities and severe incidents, not on every CVE in your scanner. And under Article 69(3) it covers products already placed on the EU market, so you cannot scope it to next year's launches.
The trap sits in the gap between the two dates. SBOM obligations are formally part of the December 2027 requirements, which is why many teams have parked component inventory until then. But a 24-hour clock means knowing that day which products contain the affected component and which versions shipped where. You can breach Article 14 by never knowing there was something to report. Inventory is a September 2026 problem wearing a 2027 label. Automated, evidence-backed compliance exists to close that gap before the clock starts.
How do you decide what to fix first?
Prioritize by real exposure, not raw severity. Ask whether a vulnerable component is actually reachable and exploitable in your product, then fix what an attacker could actually use.
The arithmetic forces the question. NVD published 41,812 CVEs in 2025, up 28% on 2024. A mid-sized enterprise carries 3,000 to 8,000 open CVEs in any given week against a team of three to twelve people who can action them. No amount of process discipline closes that gap.
Severity scores don't close it either, and this is where most programs go wrong. In one month-long analysis, only 2.3% of CVEs rated CVSS 7 or above were observed in an actual exploitation attempt. Sorting by severity means working a list where roughly 98 findings in 100 are not being used against anyone.
Reachability analysis asks a sharper question: given how this component is used in this product, can the vulnerable code be reached and executed at all? If it can't, it drops down the list. Findings from Endor Labs, Semgrep, and practitioner deployments consistently put 60% to 80% of dependency CVEs out of reach from application code. That is the idea behind reachability analysis, and it turns triage from guesswork into a ranked plan.
Exploit intelligence tightens the list further, with one caveat worth knowing before you build policy on it. EPSS is not an early-warning signal on its own. Nucleus Security studied CVEs added to CISA's Known Exploited Vulnerabilities catalog between October 2025 and March 2026, and found the median EPSS score moved 121 times more after KEV listing than before it. Layer KEV, EPSS, and reachability together rather than trusting any one of them, which is the approach behind exploitability-based prioritization.
One more number is worth keeping in view: 81% of CVEs first exploited in 2025 had been disclosed before 2025. Attackers favor proven paths over novel ones, which means your inventory matters more than your zero-day anxiety.
Why what you ship isn't always what you scanned
Seventeen percent of open-source components enter codebases outside standard package managers, arriving as copy-pasted snippets, direct vendor inclusions, and AI-generated code. Also from the 2026 OSSRA, these are components manifest-based scanners cannot see.
Your scanner reads a dependency file and reports what it declares. Anything that entered the build another way is invisible, and your vulnerability assessment inherits the gap.
Compiled software makes this worse. C and C++ have no standardized manifest, and code is statically linked or copied straight in, so the list a scanner infers is not the list that got compiled.
For a connected device the shipped artifact is firmware, where the gap becomes a product security problem. One image carries a bootloader, an RTOS such as FreeRTOS, Zephyr, or VxWorks, third-party libraries, communication stacks, and crypto components, much of it arriving from suppliers as binaries with no source. Scanners flag CVEs in the OS and applications, not in the bootloader.
That's the case for binary-level software composition analysis: inspect the artifact you shipped, not the code you think you shipped. We go deeper on the trade-offs in source code vs binary analysis.
The pressure is increasing. 85% of organizations use AI coding assistants, and 76% of companies that ban them say developers use them anyway. More code, faster, through more paths than your manifest knows about.
No single control fixes this. Defense in depth does, split across two owners. Our guide to implementing software supply chain security best practices turns this into a rollout plan.
| Organizational controls | Engineering controls |
|---|---|
| Assess supplier security posture, tier one first | Maintain an SBOM for every release |
| Least-privilege access and MFA across repos and build tools | Scan what ships, including binary analysis |
| Hold vendors to contractual security terms | Sign build artifacts and verify provenance |
| Patch continuously, not on an annual cycle | Gate releases on security checks inside CI/CD |
Design, verify, prove. That is the loop that keeps connected products secure without turning every release into a scramble.
Ready to see what's actually in what you ship? Request a demo and we'll walk your team through it.
FAQ
Is software supply chain security the same as application security?
No. Application security protects your code itself against attacks and vulnerabilities. Software supply chain security covers everything and everyone that touches that code, including third-party components, registries, build pipelines, signing, and distribution. Scanning your own source leaves most of the chain unexamined.
Isn't the EU Cyber Resilience Act deadline 2027?
Full product security requirements apply on 11 December 2027. Vulnerability reporting under Article 14 starts earlier, on 11 September 2026, and covers products already placed on the EU market. You get 24 hours to file an early warning once you become aware of an actively exploited vulnerability.
We removed the malicious package. Are we clean?
Not yet. Credentials harvested while the package was installed stay valid after you remove it, which is how recent npm worms kept spreading after cleanup. Rotate npm tokens, GitHub personal access tokens, and cloud credentials from any affected machine, then audit your CI/CD runners for injected workflows.
Do we need an SBOM if we only use commercial third-party software?
Yes, and you should be requesting SBOMs from your suppliers as well. Whatever they shipped you is now part of your product, including the components they inherited from their own suppliers. Without that visibility you cannot answer whether a newly disclosed flaw affects you.
Where should a team start with software supply chain security?
Start with inventory grounded in the artifact you ship rather than the source you reviewed. Prioritization comes next, so your team works the findings that carry real exposure. Evidence comes third, generated as a byproduct of shipping rather than assembled in the weeks before an audit.
