automated vulnerability remediation
unpatched vulnerabilities in production
DevSecOps statistics 2026
manage security debt GitHub
vulnerability remediation strategy
reduce attack surface engineering
Datadog DevSecOps report
open source security debt
burning down security backlog
SLA enforcement security
developer security debt
production vulnerability management
dependency backlog management
enterprise vulnerability strategy
Engineering VP security strategy
software composition analysis SLA
cross-repository patch management
legacy dependency updates
InstaSLA fix campaigns
actionable vulnerability metrics
Why 87 of Organizations Are Deploying Known Vulnerabilities and How to Be the 13
Back to blog
The Anatomy of the 87%: Why Software Is Aging Faster Than We Patch It
The Context Crisis: When Everything Is "Critical," Nothing Is
The Reckless-Adoption Problem Isn't Hypothetical — Ask npm
The 13% Strategy: Migrating to SLA-Driven "Fix Campaigns"
Why 87% of Organizations Are Deploying Known Vulnerabilities (and How to Be the 13%)
Datadog's State of DevSecOps Report 2026, released in February 2026 and built from telemetry across tens of thousands of applications, puts a hard number on a problem most engineering leaders already feel in their gut: nearly nine in ten organizations (87%) are running at least one known, exploitable vulnerability in a deployed service right now. Despite years of investment in shift-left tooling, automated scanners, and developer security training, the majority of engineering teams are still shipping unpatched risk into production.
This isn't a story about negligent developers. It's a structural problem with how modern software gets built. As delivery speeds up, becomes more automated, and leans harder on third-party components, risk has moved upstream into the supply chain itself — into the dependencies teams pull in, the CI/CD pipelines that assemble them, and the runtimes they execute on.
Breaking out of the 87% and into the 13% that keep their production environments genuinely secure requires rethinking how vulnerability remediation actually works: away from noisy, one-ticket-per-alert triage, and toward coordinated, SLA-driven "Fix Campaigns" that burn down security debt systematically.
The Anatomy of the 87%: Why Software Is Aging Faster Than We Patch It
The core driver isn't bad application logic — it's a breakdown in how third-party dependencies get managed. Software is aging faster than teams can keep it current, and the data shows the gap widening on multiple fronts at once.
Dependencies are getting older, not newer. The median dependency across the industry is now 278 days out of date, up from 215 days the year before — 63 days of additional drift in a single year. The picture varies sharply by ecosystem: Java services carry the heaviest lag, at a median of 492 days behind, and Java also tops the list for exploitable-vulnerability rate at 59% of services, ahead of .NET (47%) and Rust (40%).
Dead and abandoned libraries are everywhere. 42% of services rely on third-party libraries that are no longer actively maintained — packages that have effectively stopped shipping security fixes, leaving any vulnerability discovered in them permanently unpatched unless a team forks or replaces the dependency itself.
End-of-life language versions are a measurable multiplier of risk. About 10% of services still run on EOL language versions (with wide variance — 23% for Go, 13% for PHP), and those services show exploitable vulnerabilities in 50% of cases, compared with 31% for services on actively supported versions. Running an EOL runtime doesn't just mean missing features; it roughly doubles the odds of shipping a live, exploitable flaw.
Reckless adoption cuts the other way. In a bid to stay current, half of all organizations (50%) adopt new library versions within 24 hours of release. That leaves essentially no window for review, testing, or security validation — which matters enormously once a malicious or compromised release lands in a widely used package (more on that below).
CI/CD pipelines are barely pinned down. Only 4% of organizations pin all public GitHub Actions to a specific commit hash. Everyone else is trusting that a mutable tag or branch reference won't be silently swapped out from under them — which is exactly the mechanism several recent supply-chain attacks have exploited.
One nuance worth noting: it isn't uniformly bleak. Newer libraries are, on average, shipping with fewer vulnerabilities than they used to — packages released in 2025 averaged 1.3 known vulnerabilities versus 3.8 for 2023-era releases, partly attributable to a wave of Spring Framework CVEs skewing the older cohort. And deployment cadence matters: teams that deploy less than monthly carry roughly 70% more outdated libraries than teams deploying daily, which is a strong argument that continuous deployment is itself a security control, not just a velocity one.
The Context Crisis: When Everything Is "Critical," Nothing Is
If scanners are finding these issues, why aren't teams fixing them? Alert fatigue and a total lack of runtime context.
Legacy scanners flag findings against static severity scores like CVSS, with no awareness of whether the affected code path is actually reachable, internet-facing, or running in production at all. Datadog's report found that only 18% of vulnerabilities labeled "critical" remain critical once runtime context — reachability, exploit availability, active-attack signals — is applied. In .NET environments specifically, 98% of dependency vulnerabilities get downgraded from "critical" once that context is factored in.
Andrew Krug, Datadog's Head of Security Advocacy, put it bluntly: "When almost everything is labeled 'critical,' nothing is. Teams get paged for noise while threats that pose real risk slip through." He also named the underlying tension directly: "DevSecOps teams are caught between moving too slowly and moving too fast. Go slow, and outdated software accumulates known vulnerabilities. Go fast, and automation can introduce unvetted code. The real challenge, though, isn't speed — it's clarity."
That lack of clarity is what breaks trust in the security program. When developers get paged constantly for findings that turn out to be unreachable, sandboxed, or already mitigated by network controls, they stop trusting the pager — and the vulnerabilities that actually matter start slipping through with everything else.
The Reckless-Adoption Problem Isn't Hypothetical — Ask npm
The risk of 24-hour adoption cycles and unpinned pipelines isn't theoretical; it's been playing out in the npm ecosystem in real time since late 2025.
It started with s1ngularity, an August 2025 attack against the Nx build-tooling packages that harvested roughly 2,300 developer credentials from over a thousand systems — credentials that researchers believe seeded the next, much larger wave. On September 15, 2025, that wave arrived as Shai-Hulud, the first genuinely self-replicating worm observed in the npm ecosystem: it stole GitHub personal access tokens and cloud credentials, then used them to republish itself into every other package a compromised maintainer could touch. CISA's advisory put the initial toll at over 500 compromised packages.
Shai-Hulud didn't stop there. "Shai-Hulud: The Third Coming" followed in April 2026, then "Mini Shai-Hulud" — attributed to a threat actor tracked as TeamPCP — spread across two waves in April and May 2026, touching 169 packages. Most recently, on August 4, 2026, a variant called ChainDrop compromised the maintainer of the widely used keyv caching library and, within about an hour, self-propagated to more than 440 packages across 2,200+ versions — packages with a combined reach of over 2 billion monthly installs.
Each of these incidents spread the same way: through developers and CI pipelines that pulled a new package version within hours of release, over dependency references that weren't pinned to an immutable commit hash. It's the "reckless adoption cycles" and "unpinned CI/CD pipelines" findings from the Datadog report, playing out as live incidents rather than survey statistics.
The 13% Strategy: Migrating to SLA-Driven "Fix Campaigns"
The default remediation model — a separate ticket for every scanner alert — doesn't scale to this reality. If one outdated logging library affects 80 microservices, 80 individual tickets scatter the context, duplicate the investigative work, and guarantee some services fall through the cracks while developers chase copies of the same root cause.
Joining the 13% means restructuring remediation around scale and coordination. This is the operational idea behind "Fix Campaigns," run through SLA-management platforms like InstaSLA.
Group by root cause, not by alert. Instead of 80 isolated incidents, a Fix Campaign groups every instance of the same underlying issue — an outdated dependency, an unpinned GitHub Action — into a single unit of work. The task stops being "investigate 80 critical alerts" and becomes "update dependency X from v1.2 to v2.0 across these 80 repositories." That reframing alone cuts the cognitive load on developers and turns a chaotic backlog into a structured engineering task.
Apply runtime context before launching a campaign. Given that only 18% of "critical" findings hold up under runtime scrutiny, the first move before any campaign is filtering for what's actually internet-facing, handling sensitive data, or lacking compensating controls. That's how engineering time gets spent reducing real business risk instead of chasing a compliance dashboard number.
Attach non-negotiable, risk-based SLAs. A campaign is only as good as its deadline. Tools like InstaSLA let teams attach a hard, visible SLA to a campaign — "all critical, public-facing services patch this library within 72 hours" — as a tracked countdown, not a suggestion, giving security and engineering a shared source of truth on what's due and what's in breach.
Tie SLA compliance to CI/CD merge gates. To make the backlog actually shrink and stay down, breach status should block merges: if a repository is in active breach of a critical Fix Campaign SLA, the pipeline blocks new merges into it until the fix lands. That closes the loop between "we found it" and "it's actually resolved," instead of leaving remediation as a permanently deprioritized side quest.
Aging dependencies, 24-hour adoption cycles, and unpinned pipelines are producing structural vulnerabilities faster than most organizations can burn them down — and real-world incidents like the Shai-Hulud campaigns show exactly how that gap gets exploited. Filtering out false-critical noise, grouping root-cause fixes into coordinated campaigns, and enforcing deployment-blocking SLAs is what separates the 87% from the 13%.
Sources: Datadog, State of DevSecOps Report 2026 (Feb. 26, 2026); CISA Alert on the September 2025 npm supply chain compromise; Palo Alto Networks Unit 42 reporting on Shai-Hulud and related npm campaigns; Elastic Security Labs on the August 2026 ChainDrop/keyv incident; Cloud Security Alliance research note on Mini Shai-Hulud.
Top comments (0)