SAN FRANCISCO — July 6, 2026. Open source now accounts for an estimated 70-90% of the code running in modern applications, and the volume of publicly disclosed vulnerabilities tied to that code has kept pace with its growth. In 2025 alone, the National Vulnerability Database and GitHub Advisory Database processed more than 40,000 new CVE and GHSA entries touching open source packages — a figure that has roughly tripled over the past six years. At the same time, npm, PyPI, and the broader package ecosystem crossed a grim milestone: security researchers tracked well over 15,000 confirmed malicious packages published to public registries last year, a category of threat that barely existed at scale a decade ago.
Those numbers are the backdrop for what the industry now informally calls "the state of open source security" — a running tally of how dependent modern software has become on code nobody at the consuming organization wrote, reviewed, or necessarily trusts. Safeguard's research team has spent the past two quarters compiling public advisory data, registry telemetry, and enforcement trends from CISA, ENISA, and major package ecosystems into a single picture. The takeaway is not that open source is getting less secure in absolute terms — tooling, maintainer awareness, and disclosure norms have all improved. The takeaway is that the attack surface is growing faster than most organizations' ability to triage it, and attackers have noticed.
The Numbers Behind the Headlines
The modern application is a dependency tree, not a codebase. Industry surveys consistently find that a typical enterprise application pulls in somewhere between 150 and 700 transitive dependencies for every one direct dependency a developer deliberately chose. Each of those transitive packages is a vector: a vulnerability introduced three or four levels deep in a dependency graph is just as exploitable as one in code an engineer wrote yesterday, but it is far less likely to be on anyone's radar.
This is the structural reason vulnerability counts keep climbing even as awareness improves. It is not that open source maintainers are writing worse code — if anything, static analysis and fuzzing coverage across popular projects has never been better. It is that the sheer surface area of "code an organization is implicitly responsible for" has expanded by an order of magnitude in the last five years, largely invisibly, through transitive dependency resolution that happens automatically on every npm install or pip install.
Malicious Packages: From Rare Event to Daily Occurrence
The most notable shift in the 2024-2026 window is the normalization of intentionally malicious packages as a distribution channel, rather than an occasional incident. Typosquatting campaigns, dependency confusion attacks, and compromised maintainer accounts used to be treated as isolated news stories — a single npm package hijacked, a single PyPI account phished. That framing no longer fits the data. Registry-monitoring research now finds malicious or actively-compromised packages published on a near-daily basis across npm and PyPI combined, with campaigns increasingly automated: attackers publish dozens of near-identical typosquats of popular package names in a single batch, then wait for misconfigured build pipelines or careless pip install commands to do the rest.
The March 2024 discovery of a deliberately planted backdoor in xz-utils — a compression library embedded in most Linux distributions — remains the reference case for how far a patient, socially-engineered supply chain attack can reach before detection. The xz-utils incident involved years of trust-building by a pseudonymous contributor before the backdoor was inserted, and it was caught largely by chance rather than by systematic defense. Two years on, it continues to shape how security teams talk about maintainer trust, build reproducibility, and the limits of relying on a project's reputation as a proxy for its safety.
The Remediation Gap: Disclosure Outpaces Response
Perhaps the least-discussed but most consequential trend in open source security is the widening gap between vulnerability disclosure and vulnerability remediation. Mean time to patch for critical open source vulnerabilities in production environments has hovered stubbornly in the 60-to-100-day range across multiple industry benchmarks, even as mean time to disclosure has shortened thanks to better scanning tooling. Organizations are finding out about their exposure faster than ever — and still taking months to act on it.
Part of this is simple alert fatigue. Security teams running standard software composition analysis (SCA) tooling routinely report backlogs of hundreds or thousands of open findings, the overwhelming majority of which are never triaged individually. When every dependency scan returns a wall of "Critical" and "High" severity findings, teams either drown in false urgency or — more commonly — start ignoring the queue altogether. The 2021 Log4Shell event, now more than four years in the rear-view mirror, remains instructive here: research conducted well over a year after public disclosure still found a meaningful share of internet-facing systems running vulnerable Log4j versions, not because organizations didn't know, but because they couldn't prioritize a fix among thousands of competing findings.
SBOMs Move From Compliance Checkbox to Operational Requirement
Regulatory pressure has been the other major force reshaping the landscape. The U.S. Executive Order 14028 and subsequent NIST and CISA guidance pushed software bills of materials (SBOMs) from a niche practice into a baseline expectation for anyone selling into the federal supply chain. The EU's Cyber Resilience Act, phasing in reporting obligations through 2026 and full enforcement in 2027, extends similar expectations to a much larger swath of commercial software vendors operating in or selling into Europe.
The practical effect has been a surge in SBOM generation across the industry — but generation alone has proven to be the easy part. Most organizations can now produce a CycloneDX or SPDX document for a given build. Far fewer can ingest SBOMs from their vendors, reconcile them against live vulnerability feeds, and turn that reconciliation into an actionable, prioritized list. An SBOM that sits in a compliance folder, unqueried, provides audit cover but no actual security benefit. The organizations extracting real value from the SBOM mandate are the ones treating it as a living inventory — continuously matched against new CVE disclosures the moment they're published — rather than a document generated once at release time and filed away.
Why Most Vulnerabilities Never Matter — And Why That's the Real Story
If there is a single insight that should reshape how security teams read any "state of open source security" report, it's this: the vast majority of disclosed vulnerabilities in a given dependency tree are never actually reachable by an attacker. A critical CVE in a logging library's obscure configuration-parsing function is irrelevant if the application never calls that function, never loads untrusted configuration, or never even imports that code path in its build. Multiple industry studies now put the share of "non-reachable" findings in a typical SCA scan at somewhere between 70% and 85% — meaning the standard vulnerability-count metric that drives most remediation prioritization today is, for the large majority of findings, measuring risk that doesn't exist in practice.
This is the gap between vulnerability presence and vulnerability exploitability, and it's the single biggest lever available to security teams trying to close the remediation gap described above without simply hiring their way out of the problem. A team that can confidently say "of our 3,000 open findings, only 140 are actually reachable from our application's entry points" has turned an unmanageable backlog into a tractable one — without changing a single line of code.
How Safeguard Helps
Safeguard is built around closing exactly this gap between raw vulnerability counts and actual exploitable risk. Our reachability analysis engine traces call paths through your dependency graph to determine which disclosed vulnerabilities are genuinely exercisable by your application's code, cutting through the noise that leaves most SCA backlogs unworkable. Griffin, Safeguard's AI-powered analysis agent, goes further — reasoning over code context, data flow, and exploit conditions to explain why a finding matters (or doesn't) in language your engineering team can act on immediately. Safeguard also generates and ingests SBOMs natively across CycloneDX and SPDX formats, turning your software inventory into a continuously reconciled feed rather than a static compliance artifact, and matching it automatically against new disclosures as they land. And when a fix is genuinely warranted, Safeguard doesn't stop at the finding: our auto-fix PR capability opens a ready-to-review pull request with the patched dependency version, letting teams close the loop from disclosure to remediation in minutes instead of the industry's typical two-to-three-month cycle.