Two events define software supply chain security in 2026. On 4 August 2026, the ChainDrop worm poisoned 444 npm packages with roughly two billion monthly downloads in under four hours. Five weeks later, on 11 September 2026, the EU Cyber Resilience Act‘s Article 14 reporting duties became enforceable, adding a 24-hour early-warning clock and fines up to EUR 15 million (or 2.5% of global turnover).
The two events reframe the whole problem: the trust boundary has moved from your network to your build pipeline, and the trust signals you once relied on no longer establish safety. This page frames that shift, introduces each subtopic, and routes you to the detail.
In This Series
- The Software Supply Chain Is the New Perimeter
- ChainDrop, Shai-Hulud and the Anatomy of a Modern npm Worm
- Provenance Is Not Authorisation and What Trust Signals Actually Prove
- EU Cyber Resilience Act Article 14 Reporting Deadlines and Duties
- Open Source Risk Data, Ecosystem Comparisons and the Security Budget
What is the software supply chain perimeter, and why has the build pipeline become the attack surface?
Your supply chain perimeter is everything that can influence a shipped artefact: dependencies, package registries, build runners, signing keys and CI configuration. The old network perimeter assumed code was written once and shipped; the supply chain perimeter recognises code is assembled continuously from third parties. In 2026 that matters because one poisoned build reaches every downstream consumer of that artefact, a higher-leverage target than any single package.
Black Duck’s OSSRA 2026 found 87% of audited codebases carrying at least one open-source vulnerability, averaging 581 each. The 2026 shift is toward governing distribution infrastructure and the non-human identities that run it.
That is the trade-off you now weigh: velocity versus cooldowns, convenience versus install-script gating. The levers live in CI/CD, GitHub Actions and OIDC, and ChainDrop is the proof point. Read more on why the build pipeline is now the target.
What did the 2026 npm worm waves actually do, and why did they spread so quickly?
ChainDrop poisoned 444 npm packages in under four hours on 4 August 2026, by stealing publish credentials and republishing through the victims’ own trusted release workflows. The Shai-Hulud lineage has evolved since September 2025, and the May 2026 release of the worm’s source code democratised the playbook. The speed comes from a self-propagation loop: each compromised maintainer becomes a distributor, turning one victim into many.
StepSecurity enumerated all 444 packages and 2,212 versions, and Microsoft traced the same campaign as a Mini Shai-Hulud variant. The lineage reaches beyond npm into Docker Hub and VS Code extensions, a recurring pattern rather than a one-off.
The question you will need to answer is whether you are only a victim or also a distributor. That is the propagation-node test. The mechanism sits in a preinstall lifecycle script that runs on install, and domain blocklists keep failing because ChainDrop’s command and control resolves from a smart contract, a technique called EtherHiding. Get the full anatomy in what the 2026 npm worm waves actually did.
Why does a valid signature no longer mean a safe package?
A valid SLSA provenance attestation proves how an artefact was built and where it came from. It says nothing about whether the contents are safe. Every poisoned ChainDrop version carried valid provenance because the malware rode the maintainers’ legitimate signed pipeline, and a valid pipeline can still emit poison. ChainDrop’s lesson: treat provenance as a necessary but insufficient signal, and pair it with behavioural detection.
Osterling’s breakdown of SLSA puts it plainly: provenance attests to process, not to the safety of the result. If a build environment is subverted, the provenance records “built from clean commit X, by the official CI” and signs it anyway. That collapses the assumption that provenance means safe.
Provenance establishes where an artefact came from; authorisation establishes what it was permitted to do. An SBOM, SLSA provenance and Sigstore each answer a different question, and none of them answers “is this safe”. The containment shift is toward behavioural detection, and a credential blast radius sits behind any poisoned package. Read more on why a valid signature is no longer a safety signal.
What do the CRA Article 14 clock and the 2026 risk data mean for your budget and vendors?
Article 14 of the EU Cyber Resilience Act now obliges manufacturers to report actively exploited vulnerabilities: a 24-hour early warning, a 72-hour detailed notification and a 14-day final report, on pain of fines up to EUR 15 million or 2.5% of global turnover. OSSRA 2026 found 87% of audited codebases carry at least one open-source vulnerability, averaging 581 each. Together they force two decisions: stand up a reporting capability now, and spend where the leverage is highest.
The clock binds from 11 September 2026, ahead of the December 2027 essential requirements under Annex I and the CE-marking consequence. The ENISA reporting platform is live now. The trigger differs from NIS2 and GDPR, and the microenterprise carve-out changes who is caught. Read more on what the CRA Article 14 clock demands.
Reporting is only half of it, because the same pressure shows up in your dependency data. Black Duck’s OSSRA 2026 also compares ecosystems, npm versus PyPI, Maven and Go, and tracks AI-agent dependency ingestion. Fund where the leverage is highest first: deterministic installs, private registry proxying and automated remediation. Read more on what the risk data means for budget and vendors.
Resource Hub: Software Supply Chain Security in 2026 Deep Dives
Understand the Shift
- The Software Supply Chain Is the New Perimeter: why the build pipeline replaced the network, and how to tell if you’re exposed. 6 minutes.
Understand the Threat
- ChainDrop, Shai-Hulud and the Anatomy of a Modern npm Worm: how a self-propagating worm turns victims into distributors. 6 minutes.
- Provenance Is Not Authorisation and What Trust Signals Actually Prove: why a valid signature no longer proves a package is safe, and what each signal establishes. 6 minutes.
Build the Programme
- EU Cyber Resilience Act Article 14 Reporting Deadlines and Duties: what the reporting clock requires, how it differs from NIS2 and GDPR, and when it binds. 5 minutes.
- Open Source Risk Data, Ecosystem Comparisons and the Security Budget: what the 2026 risk data reveals about your exposure, and how to fund a credible response. 5 minutes.
Suggested reading order: start with the shift, move through the threat, then build the programme.
Where to start depends on what worries you and your team most. Wondering whether you’re exposed? Begin with the new perimeter.
Chasing the threat? Read the worm anatomy then what provenance proves.
Building the programme? Start with the CRA clock then the risk data and budget.
Frequently Asked Questions
What is the difference between an SBOM and SLSA provenance?
An SBOM is an ingredient list: it records what is inside an artefact. SLSA provenance is a build-integrity claim, a signed statement about how that artefact was built and from which source commit. They answer different questions, and neither proves an ingredient is safe. ChainDrop shipped valid provenance on every poisoned version, so treat both as necessary but insufficient signals.
Which SLSA build level should you actually target?
Target the level you can enforce, not the highest level you can generate. Higher levels buy stronger build-integrity guarantees, but they add pipeline friction and no level turns provenance into a safety guarantee. A level three pipeline that fails open under pressure is weaker than a level two pipeline you actually run. Map each level against what it buys you before committing.
What is a package cooldown, and would one have stopped ChainDrop?
A cooldown, sometimes called a minimum release age, delays installing a package version until it has been public for a set period, giving the community time to catch malicious releases. A cooldown would likely have caught the ChainDrop waves, because the poison was detected within hours. It is not a complete fix: fresh-install jobs can bypass pinning, so pair it with install-script gating.
How do you tell whether you are only a victim or also a distributor?
Run the propagation-node test: check whether your publish credentials, tokens or release workflows were used to push anything you did not authorise. If they were, you are a distributor, and everything downstream of your artefact inherited the risk. That is why credential rotation sequencing matters, and why the honest answer often requires a forensic reconstruction of your build logs.
Does a private registry stop a supply chain attack?
No, a private registry proxy is one control among several, not a complete defence. It governs what reaches your build, but it does not stop maintainer credentials being stolen upstream, and it will not detect malware that arrives through a legitimate signed pipeline. You still need install-script gating, egress allowlisting and credential rotation sequencing around it.
Where do you report an actively exploited vulnerability under the CRA?
Through the ENISA Single Reporting Platform, which routes your notification to the competent national CSIRT for each EU market where the product is available. The Article 14 duties became enforceable on 11 September 2026, so the 24-hour early-warning clock now runs from the moment you become aware of active exploitation, not from your internal triage.
Does the CRA apply if your company is based outside the EU?
It can, if you place products on the EU market. The CRA binds manufacturers whose products are made available in the EU, regardless of where the company is headquartered, so your business carries the Article 14 reporting duties if you sell into Europe. The microenterprise carve-out changes who is caught, so check your size and exposure.
What counts as an actively exploited vulnerability under the CRA?
Article 14 is triggered by a vulnerability that is being exploited in the wild, not by the mere existence of a flaw or a public proof of concept. The clock starts when you become aware of reliable evidence of active exploitation, and it is the manufacturer’s own awareness that matters, not the date a vendor advisory eventually lands.
What is the December 2027 CRA deadline, and does it matter now?
December 2027 is when the CRA’s Annex I essential requirements apply and CE marking follows, but it is not the deadline that should drive your plan. The Article 14 reporting duties bound from 11 September 2026, more than a year earlier, and they carry the same penalty exposure. Treat the reporting capability as the first priority and conformity as the longer build.
Is open source inherently less secure than commercial software?
No. The risk sits in the distribution layer. Proprietary stacks pull the same open-source dependencies from the same registries, so they inherit the same exposure. OSSRA 2026 found 87% of audited codebases carried at least one open-source vulnerability, averaging 581 each, a figure that reflects assembly practices rather than open source itself.
What should you do if you find a malicious package in your dependencies?
Contain first: stop the build, isolate the affected artefact and rotate any credentials the pipeline could reach, because a poisoned package carries a credential blast radius. Then reconstruct what shipped and where it went, and treat your own consumers as potentially affected. If the vulnerability is being actively exploited, the CRA reporting clock has already started.
Do AI coding agents make supply chain attacks more likely?
Yes, they widen the ingestion surface. Agent-driven workflows pull dependencies directly, often without a human review gate, and the OpenAI agent incident showed packages pushed to RubyGems and production workers reached in an operation METR and Redwood counted at 17,600 attacker actions. The fix is deterministic installs and a policy layer that constrains what an agent can introduce.
