Open Source Risk in 2026: What SCA Data Tells Us About Supply Chain Vulnerabilities

On September 8, 2025, attackers compromised the npm accounts of maintainers behind chalk, debug, ansi-styles, and strip-ansi — eighteen packages with a combined 2.6 billion weekly downloads. The malicious versions contained obfuscated JavaScript that silently intercepted cryptocurrency transactions. Any CI pipeline that pulled these packages during the window of compromise shipped tainted code into its build artifacts.

The attack was not that sophisticated — it started with a phishing email to a single maintainer. But chalk and debug are so deeply embedded in the JavaScript ecosystem that the blast radius was enormous: these are not optional add-ons but foundational utility libraries present in virtually every Node.js application, including those that have nothing to do with cryptocurrency.

This incident crystallized a problem that SCA reported for years. The risk in modern software is not primarily in the code team write — it is in the components it inherits. And in 2026, the scale of that inherited risk, the sophistication of the attacks targeting it, and the regulatory pressure to manage it have all reached a point where open-source dependencies demand closer oversight.

 

The Landscape in Numbers

The Verizon 2025 DBIR found that third-party involvement in breaches doubled year-over-year, rising from 15% to 30% of all confirmed breaches — driven by software supply chain compromises, credential exposures from partners, and misconfigured SaaS environments. This was the single largest shift in the entire report.

The underlying numbers explain why. Open-source components constitute 70 - 90% of the average commercial codebase, depending on the ecosystem. The Linux Foundation’s Census III found open-source code in 96% of commercial codebases surveyed. A typical npm project pulls in an average of 79 transitive dependencies — packages that nobody explicitly installed but that arrive as passengers of the packages someone did install. Each transitive dependency is a potential entry point, maintained by a person or team whose security practices your organization has never evaluated.

Sonatype’s data shows the scale of the problem: in Q4 2025 alone, they blocked over 120,000 malicious package uploads across npm, PyPI, Maven, and NuGet — 120,000 packages that were designed to be malicious from the start.

 

Where the Risk Concentrates

Different ecosystems face different threat profiles, and understanding the distinctions matters for prioritizing SCA coverage.

 

npm

The JavaScript ecosystem is the largest and the most aggressively targeted. The September 2025 compromise of 'chalk' and 'debug' was the highest-profile incident, but it was part of a broader pattern: throughout 2025, attackers used typosquatting (publishing packages with names like ‘lodahs’ for ‘lodash’), dependency confusion (publishing internal package names to public registries), and account takeover via phishing to inject malicious code into the npm supply chain. 

Research shows that 71% of malicious packages use long names with dashes, mimicking legitimate naming conventions. The depth of npm dependency trees — averaging 79 transitive packages per direct install — means that a single compromised package cascades into thousands of downstream applications within hours.

 

PyPI

Python’s ecosystem is growing fastest in AI and machine learning workloads, which brings a specific risk profile: many ML libraries are maintained by small academic teams with limited security resources, and the dependency chains in packages like torch or transformers are both deep and opaque. 

The 2022 'torchtriton' dependency confusion attack — where a malicious package named after PyTorch’s internal dependency appeared on the public PyPI registry and was automatically pulled into developer environments — demonstrated how fragile the boundary between private and public package registries can be. The MUT-8694 campaign, tracked by Datadog, simultaneously targeted both npm and PyPI with infostealer malware distributed through typosquatted packages.

 

Maven

Java’s Maven Central carries a different kind of risk: age. Many Maven packages have been maintained for a decade or longer, and a significant number are effectively unmaintained — still downloaded millions of times but no longer receiving security patches. 

This matters particularly for organizations migrating legacy COBOL or mainframe systems to Java, where the new Java codebase inherits both the modern framework dependencies and the older utility libraries that glue them together. The MavenGate attack vector — where attackers acquire expired domains previously used for Maven package verification — exploits this long tail of unmaintained packages.

 

Other ecosystems

RubyGems, NuGet, and Go modules each have their own vulnerability profiles, but the common thread across all ecosystems is the same: the attack surface is not the package you chose but the dependency tree it brought with it.

 

 

The False Positive Problem

A conventional SCA tool works by matching the components in a project against a vulnerability database. If an SBOM includes package X at version Y, and version Y has a known CVE, the tool reports a finding. The problem is that this presence-based detection generates an enormous volume of findings where the vulnerable function is never actually called in your code. A library might have a critical CVE in its XML parsing module, but if an application only uses its string formatting utilities, the vulnerability is technically present but not exploitable.

For teams that run SCA in CI/CD on every build — which is the correct practice — this might create alert fatigue at an industrial scale. Engineers stop trusting “critical” findings. Security review becomes a ritual of dismissing false positives rather than a process of identifying genuine risk.

Here’s where reachability and exploitability analysis come into play. The vulnerable function is called from a reachable code path in the application. The difference is obvious: a report that contains 400 findings (of which 12 matter) OR a report that contains those 12 findings from the start.

 

DerScanner’s hybrid SAST & SCA was built around this distinction. It combines static analysis of the application’s call graph with SCA vulnerability data to determine whether a vulnerable method in a dependency is actually invoked from your code. The result is a lower false positive rate — findings that represent genuine, exploitable risk rather than theoretical exposure. 

 

 

Beyond CVEs: Supply Chain Attacks Are a Different Threat Category

Traditional SCA focuses on known vulnerabilities in legitimate packages. But the fastest-growing threat category is intentionally malicious code published to look legitimate.

Typosquatting, dependency confusion, and starjacking (cloning popular repositories to build false credibility) are social engineering attacks against the software supply chain. A package named 'reqeust' instead of 'request' will not show up in a CVE database because it was never a legitimate package with a legitimate vulnerability. It was malware from the start.

Detecting these threats requires a fundamentally different analytical approach than matching against known CVEs. It requires evaluating package metadata: age, maintainer history, download patterns, domain ownership, naming similarity to popular packages, and behavioral signals in install scripts.

DerScanner’s SCA includes detection for these supply chain-specific attack vectors, including typosquatting, MavenGate (expired domain hijacking in Maven), and starjacking. Its open-source health scoring evaluates packages on eight security metrics beyond known CVEs — covering maintainer activity, project health, and indicators of supply chain manipulation. For teams that want to check packages before adding them to the codebase, HealthyPackage.ai offers a free quick-check service upon request.

 

 

What to Do About It

 

Run SCA on every build

Organizations that run SCA in CI/CD catch the compromised versions before they reach production > Organizations that scan quarterly — do not. The cadence of scanning determines the window of exposure.

 

Maintain SBOMs per release

When a new CVE is published and a regulator or customer asks whether it affects a specific shipped version, the answer should come from an archived SBOM — sadly, it’s too late for re-scanning. 

DerScanner generates SBOMs in CycloneDX format as part of each SCA scan; archiving them per release is a pipeline step. Under the EU’s Cyber Resilience Act, this becomes a legal obligation for products with digital elements from September 2026.

 

 

Prioritize by reachability

A CVSS 9.8 in a function your code never calls is less urgent than a CVSS 7.2 in a function that runs on every request. Reachability-based prioritization — which DerScanner’s hybrid SAST+SCA mode provides natively — is what makes the difference between an actionable report and noise.

 

Have a supply chain incident response plan

When the chalk/debug compromise hit, organizations that had a documented response process — pin dependency versions, check lockfiles, scan for compromised versions, roll back affected builds — contained the damage in hours. Those without one spent days figuring out whether they were affected. A supply chain incident is different from a server breach; an IR plan should reflect that.

Open-source software is not going away, and the economics that made it the foundation of modern development haven’t changed. What has changed is the threat landscape: supply chain attacks are scaling faster than traditional vulnerability disclosure, regulatory frameworks are mandating component-level visibility, and the tools to manage this risk have matured past the point where alert fatigue and false positives are acceptable excuses for inaction.

 

The organizations that treat SCA as a first-class part of the development pipeline — with continuous scanning, reachability-based prioritization, SBOM archival per release, and supply chain-specific threat detection — are the ones that will go through the next incident without losing a weekend to triage. The rest will find out about the compromise from their customers, or even worse — the news.