You have seen the headline. Black Duck‘s 2026 Open Source Security and Risk Analysis, the OSSRA report, found 87% of audited codebases contain at least one open source vulnerability, averaging 581 per codebase. It is the kind of stat that reaches a board deck and becomes a single instruction: fix security. It is the beginning of the question.
The landscape has moved past that question. Sonatype’s Q2 2026 malware index shows npm absorbing 96.6% of malicious package counts, and Docker found 77% of organisations experienced a supply chain incident in the past year. A worm that poisoned 444 npm packages turned “malicious package” into a live campaign. This article interprets the data, compares the ecosystems, and sizes a budget and vendor test you can defend, as part of a broader guide to software supply chain security in 2026.
What does the 2026 OSSRA report reveal about open source vulnerability risk per codebase?
The short answer: 87% of audited codebases carried at least one open source vulnerability, averaging 581 each, and 78% carried high-risk ones. Those figures record vulnerability presence, not reachable or exploitable risk. A CVE says a flaw exists; the Exploit Prediction Scoring System (EPSS) estimates the chance it will be actively exploited, and reachability analysis checks whether your code actually calls the vulnerable path.
Two categories hide behind the 87%, 581 and 78% figures. Zombie components are abandoned or end-of-life dependencies still shipping after support ends; with no maintainer to fix them, they never clear through normal upgrades. Licence laundering is quieter: code embedded under a permissive licence when its true terms are copyleft, pushing licence conflicts to 68% of audited codebases, up from 56% a year earlier.
Black Duck publishes the 2026 OSSRA report and supplies these figures. For authoritative trend statistics, pair vendor research from Black Duck, Sonatype and Docker’s Omdia survey with advisory feeds like the NVD and programmes from CISA and the OpenSSF. The strategic reading of these figures belongs to the broader supply chain story.
Is npm riskier than PyPI, Maven, or Go module ecosystems?
The per-codebase figure shifts depending on where your dependencies come from, and on that measure npm is the most exposed. Its open, high-churn publish model and install-time script execution make it the path of least resistance: packages run preinstall and postinstall scripts before a human reviews them. Sonatype’s Q2 2026 data shows npm holding 96.6% of malicious package counts. Partly a volume artefact, since npm is the largest registry, but the open model makes the concentration real.
The answer gets nuanced from there. Of the malicious packages outside npm, 48.5% landed in PyPI and 38% in NuGet, with PyPI recording the most exfiltration and dropper events. Maven Central, operated under Sonatype, carries heavier curation but its own supply risk. Go modules are fetched directly from version-control repositories rather than a central registry, and Crates.io enforces strict size and file-type limits, so both report lower malware volume; the structure explains part of the gap, but lower volume still leaves exposure.
AI coding agents change that exposure across every ecosystem, ingesting dependencies faster than human review can match and getting it wrong: across 36,780 upgrade suggestions from leading AI tools, 27.8% pointed to versions that were non-existent, deprecated or unsafe. To see whether you are exposed, start by assessing your own perimeter. Once you know where you are exposed, the next question is what it costs to close that gap.
How should you budget for supply chain security as you move from hands-on work to strategy?
As day-to-day security responsibility shifts toward strategy, the budget has to carry controls that run without you touching them. Spend where the leverage is, and frame it as a multiplier of engineering time and risk reduction.
The highest-leverage investment costs almost nothing. Version pinning and lockfile-driven installs give you deterministic builds, so a build cannot silently pull a poisoned release.
Private registry proxying is the control that becomes a recurring budget line. Route every install, on laptops and in CI, through a governed gateway like Artifactory, Nexus or Verdaccio, and you get an audit trail, caching, and one place to enforce allow and block lists. Unit 42’s guidance is clear: never let a developer machine or CI runner talk directly to the public registry.
Automated remediation is the force multiplier. Dependabot and Renovate open tested upgrade pull requests, reducing mean time to remediate and clearing the backlog. Manual remediation costs thousands of dollars per vulnerability and takes months; automation cuts it to days. Anchor the ask in benchmarks like cyber taking 6.7% of the IT budget, and report against engineering velocity, not CVE totals. The broader story sits in the 2026 supply chain landscape.
What should I look for when evaluating a supply chain security vendor?
Test the vendor against how your organisation is actually attacked. Four things separate a credible vendor from a scanner.
First, coverage of the whole build pipeline, not just dependencies; a vendor that only reads your manifest cannot see what happens at install, build, or inside the CI runner. Second, behavioural detection over purely static analysis: watch what a package does at install, build and runtime. Third, CI runner control, where StepSecurity’s Harden-Runner enforces network egress allowlists and records per-job telemetry, so a malicious package cannot phone home. Fourth, hardened distribution: Chainguard builds minimal, zero-CVE images from verified source with a contractual remediation SLA. For ecosystem intelligence, Sonatype’s research and stewardship of Maven Central are the benchmark.
Adopt the cheap structural controls before you buy anything. A cooldown, or minimum release age, blocks a package version until it has existed for a few days; most malicious releases are caught and pulled within hours, so a three-to-seven-day delay would have prevented most of them. Then buy only what closes the gap, and remember that provenance is not authorisation.
Making the argument to leadership
Open source risk is structural, shaped by the ecosystem you build on, and ultimately a resourcing question. The 87% and 581 figures, the npm 96.6% concentration, and the vendor market all point the same direction: the highest-leverage spend is the controls that multiply engineering time, and the right vendor is the one whose model matches your threat model.
When your leadership asks what the security spend buys, the answer is engineering velocity and reduced reachable risk. Deterministic builds, a private registry, automated remediation and a cooldown all run without you. The goal shifts from counting CVEs to resourcing a programme, and the wider 2026 supply chain picture shows where that programme fits.
Frequently Asked Questions
Where can I find authoritative statistics on software supply chain attack trends?
Combine vendor research with government and ecosystem programmes rather than relying on a single source. Black Duck’s annual OSSRA report anchors per-codebase risk, Sonatype publishes ecosystem malware data, and Docker’s Omdia survey tracks incident rates across organisations. Pair those with advisory feeds such as the GitHub Advisory Database and NVD, plus programmes run by CISA and the OpenSSF. Treat each as one signal, and check the methodology before quoting a headline to your board.
What is a zombie component, and how do I find them?
A zombie component is a dependency that is abandoned, unmaintained or past end-of-life but still ships inside your codebase. Because no maintainer is patching it, it will never clear from a vulnerability backlog through normal upgrades. Find them by flagging packages with no release or commit activity for twelve to eighteen months, or a deprecated registry notice. Then decide to replace, fork, or formally accept the risk with a documented exception.
What is licence laundering, and why should I care?
Licence laundering is embedding code under a permissive licence when its true terms are copyleft or otherwise restrictive, usually because a maintainer copied from another project. It sits inside the OSSRA data alongside vulnerabilities but creates legal rather than technical exposure. The risk is quiet: it surfaces during due diligence or acquisition, not in a scanner alert. Maintain a software bill of materials and review licence changes on upgrades.
Is a CVE count a good measure of my actual risk?
No. A raw CVE count measures vulnerability presence, not exploitability. Most reported CVEs never fire in production because the vulnerable path is unreachable, behind a default setting, or requires an attack scenario you do not face. Use EPSS to understand the likelihood a vulnerability is exploited in the wild, and contextual or reachability analysis to see whether your code actually calls it. Prioritise accordingly instead of chasing zero.
Does provenance or package signing prove a dependency is safe?
No. Provenance and signing prove where an artefact came from and that it has not changed since, not that the code is benign. A maintainer can sign a malicious release with valid credentials, as recent registry attacks showed. Treat trust signals as one input and still validate behaviour at install, build and runtime, because authorisation is not the same as safety. Signing narrows the attack surface but never removes it.
What is a cooldown, and how does it reduce supply chain risk?
A cooldown, sometimes called minimum release age, blocks a registry from installing a package version until it has existed for a set period, often a few days. Most malicious releases are detected and pulled within hours, so the delay lets the ecosystem catch them before they reach your builds. It is cheap to configure in npm, Renovate and most registry proxies, so treat it as a structural control you adopt before buying anything.
Do I still need a vendor if I pin versions and proxy my registry?
Usually yes, but only for the gap those controls leave open. Pinning and proxying remove resolution drift and force installs through a governed gateway, yet they cannot see malicious behaviour inside a legitimate, correctly versioned package. A vendor earns its place by covering the whole build pipeline, detecting behaviour rather than only scanning artefacts, and controlling CI runners. Adopt the cheap structural controls first, then buy to close what remains.
How do AI coding agents change my supply chain risk?
They accelerate dependency ingestion far beyond what human review can match. An agent can add, upgrade or hallucinate packages across dozens of files in seconds, and it does not check provenance or maintainer history. That means unreviewed code reaches your build before anyone sees the manifest, and hallucinated or typosquatted package names become a real attack path. Gate agent-generated dependency changes through the same registry proxy and review rules as human ones.
What is dependency confusion, and does it affect every ecosystem?
Dependency confusion, or namespace confusion, exploits a package manager resolving a private internal name against a public registry when an attacker publishes a higher version of that name publicly. It affects any ecosystem that mixes private and public sources with the same resolver, including npm, PyPI and NuGet. Mitigate it by scoping private packages, configuring registry priority, and routing installs through a proxy that refuses unknown public matches.
Where should the first dollars go if I have almost no budget?
Start with deterministic builds and a cooldown, because both cost nothing but configuration time. Version pinning and npm ci eliminate resolution races, and a minimum release age filters out packages pulled within hours of publication. Next, stand up a private registry proxy using Artifactory, Nexus or Verdaccio so every install, on laptops and in CI, passes through one governed gateway. Spend money only once a gap remains.
How do I know whether our supply chain security programme is working?
Track reachable risk and time to remediate, not CVE totals. Two practical measures are the percentage of dependencies passing through the registry proxy and the median time from a fix being available to it being merged. Automated remediation tools such as Dependabot and Renovate move that second number directly. Report both alongside engineering velocity, so the board sees spend converting into faster, safer delivery rather than another scanner dashboard.
Do I need a software bill of materials, and what does it actually give me?
A software bill of materials, or SBOM, is a machine-readable inventory of the components and versions inside your software. It gives you fast, accurate answers when a new vulnerability or malicious package is disclosed: instead of scanning every repository, you query the inventory. An SBOM does not reduce risk on its own, but it shortens the time between disclosure and knowing whether you are affected, which is often the difference that matters.
