SAN FRANCISCO — July 6, 2026. Open source now accounts for an estimated 70-90% of the code running in modern applications, yet the security posture of that code has not kept pace with its adoption. Safeguard's research team compiled this year's edition of the State of Open Source Security Report by analyzing telemetry from thousands of scanned repositories, public vulnerability disclosures logged through Q2 2026, and dependency graphs pulled from npm, PyPI, Maven Central, and crates.io. The findings paint a familiar but worsening picture: more packages, more transitive dependencies, more disclosed CVEs — and organizations are still triaging almost all of them by hand.
This is the latest installment in Safeguard's annual State of Open Source Security Report series, which tracks how vulnerability volume, remediation velocity, and supply chain attack patterns evolve year over year. The goal isn't to repeat the now-familiar warning that open source carries risk — every security team already knows that. The goal is to quantify exactly where the risk concentrates, so remediation effort can be pointed at the handful of issues that actually matter.
The Numbers: Volume Is Still Climbing
The National Vulnerability Database and OSV.dev combined disclosed roughly 34,000 new open source vulnerabilities in the twelve months ending Q2 2026, continuing a multi-year upward trend that shows no sign of plateauing. Three data points stand out from this year's analysis:
- Transitive dependencies now account for the majority of exposure. Across the JavaScript and Java ecosystems specifically, more than 60% of vulnerable packages identified in scanned repositories were transitive — dependencies of dependencies that developers never explicitly chose and often don't know exist in their tree. Direct dependencies, the ones teams actually review before adding, made up a shrinking minority of total exposure.
- The average application now pulls in several hundred open source packages, and that number keeps growing as frameworks add more granular, single-purpose libraries rather than fewer, larger ones. Each additional package is another vector for a compromised maintainer account, a typosquat, or a quietly introduced vulnerability.
- Critical and high-severity findings are a small fraction of total volume, but consume a disproportionate share of triage time because most scanning tools surface them with identical urgency to everything else. Without a way to separate "technically present" from "actually exploitable," security teams end up spending their limited hours on paperwork instead of patching.
The Real Story: Reachability, Not Just Presence
The single most consistent theme across this year's findings — and the theme that has driven the sharpest divergence between mature and immature security programs — is the gap between vulnerability presence and vulnerability reachability. A CVE existing somewhere in a dependency tree is not the same as that vulnerable code path actually being invoked by the application at runtime. Industry-wide analysis consistently shows that a large majority of flagged vulnerabilities sit in code paths the application never calls, meaning the theoretical attack surface and the actual attack surface are very different sizes.
Teams that scan for presence alone are, in effect, generating a to-do list where 80-90% of the items are noise. This is the single biggest driver of alert fatigue reported by security and platform engineering teams this year, and it's a major contributor to a related trend: the widening gap between disclosure and remediation. Median time-to-remediate for high-severity open source vulnerabilities remains stuck in the multi-week range for most organizations — not because engineers are slow, but because they're forced to manually determine which of hundreds of alerts deserve attention before they can start fixing anything.
Supply Chain Attacks Are Maturing, Not Just Multiplying
Beyond raw CVE counts, the character of open source supply chain attacks continued to shift this year. Malicious package publishing — attackers uploading typosquatted or dependency-confusion packages designed to be pulled in by mistake — remained a steady background threat across npm and PyPI. But the more concerning pattern is the rise of compromised legitimate packages: attackers gaining access to a maintainer's publishing credentials or CI pipeline and pushing malicious code into a package that already has an established user base and a clean reputation. That technique bypasses the instinctive skepticism developers apply to unfamiliar new packages, because the package itself isn't new — only the payload is.
SBOM (software bill of materials) mandates continued to expand in scope this year, driven by regulatory pressure (including continued rollout of federal software supply chain requirements) and downstream customer demands in vendor security questionnaires. Yet Safeguard's data shows a persistent gap between organizations that can produce an SBOM on request and organizations that actively use SBOM data to drive remediation decisions. Generating the document has become table stakes; treating it as a live, queryable asset — one that flags immediately when a newly disclosed CVE lands in a component you ship — is still the exception rather than the rule.
What Mature Programs Are Doing Differently
A clear pattern emerged among the organizations in this year's dataset with the shortest remediation times and lowest alert volumes reaching human reviewers:
- They prioritize by reachability and exploitability, not CVSS score alone. CVSS measures theoretical severity in a vacuum; it says nothing about whether your application actually exercises the vulnerable function. Programs that layer reachability analysis on top of CVSS consistently report dramatically smaller "must fix now" queues.
- They automate the fix, not just the finding. Identifying a vulnerable dependency is the easy half of the problem. The organizations closing gaps fastest have pipelines that generate the version-bump pull request automatically, run tests against it, and route it for review — turning remediation into an approval click rather than a research project.
- They treat SBOM as infrastructure, not paperwork. Rather than regenerating a bill of materials for each audit or customer request, mature teams maintain a continuously updated inventory that can be cross-referenced against new disclosures the moment they land, and ingest SBOMs from vendors and acquisitions instead of re-scanning everything from scratch.
- They watch behavior, not just manifests. Static dependency scanning catches known-vulnerable versions; it doesn't catch a maintainer account being hijacked mid-release cycle. The most resilient teams pair traditional scanning with anomaly detection tuned to publishing behavior and build-pipeline activity.
Looking Ahead
If this year's trajectory holds, expect three things in the next report cycle: continued growth in transitive dependency counts as ecosystems fragment further into smaller packages; increased regulatory pressure pushing SBOM from "nice to have" to contractually mandated in more industries; and continued divergence between organizations that adopt reachability-based triage and those still working every CVE as if it were equally urgent. The gap between those two groups — measured in remediation velocity and analyst hours saved — is likely to widen further before it narrows.
How Safeguard Helps
Safeguard was built around the central finding of this report: that presence isn't risk, reachability is. Our platform performs reachability analysis on every dependency in your codebase, tracing whether vulnerable code paths are actually invoked so your team can act on the fraction of alerts that represent real exposure rather than triaging every CVE with equal urgency. Griffin AI, Safeguard's security reasoning engine, layers exploitability context and business impact on top of that reachability signal to rank findings the way a senior security engineer would. Safeguard generates and continuously maintains SBOMs across your codebase — and ingests third-party and vendor SBOMs directly — so your inventory stays current without manual re-scans every time a new CVE drops. And when a fix is needed, Safeguard opens an auto-fix pull request with the dependency bump, test results, and context already attached, turning what used to be a multi-week remediation cycle into a same-day merge.