The 82% Context Gap: Why CVSS Is Failing Prioritization in 2026

The 82 Context Gap Why CVSS Is Failing Prioritization in 2026
Back to blog
The Core Flaw: CVSS Measures Severity, Not Risk
What the 2026 Data Actually Shows
Redefining Exploitability Scoring: CVSS, EPSS, and Runtime Context
EPSS adds "how likely," not just "how bad"
CVSS itself is evolving toward context
Runtime context via eBPF and AppSec agents
How to Prioritize GitHub Security Alerts Effectively
Operationalizing Context: Enforcing SLAs with InstaSLA
Conclusion: Stop Triaging by Score Alone
Sources
The 82% Context Gap: Why CVSS Is Failing Prioritization in 2026
If you're a security engineer or DevSecOps professional operating in 2026, your daily reality likely revolves around managing an endless, overwhelming stream of alerts. Automated tools, software composition analysis (SCA) scanners, and bots like Dependabot have become exceptionally good at one thing: finding vulnerabilities. Finding them is no longer the hard part. The hard part is figuring out which ones actually matter.

For nearly two decades, the Common Vulnerability Scoring System (CVSS) has been the default measure of vulnerability severity. But in 2026's cloud-native, AI-accelerated environments, that default is showing its limits. Security teams are drowning in "Critical" and "High" alerts, and it's costing them engineering velocity and credibility with developers.

The clearest evidence of this comes from Datadog's State of DevSecOps Report 2026, published in late February 2026. Analyzing telemetry across tens of thousands of applications, the report found that only 18% of vulnerabilities initially flagged as "Critical" remain critical once runtime exposure and reachability are factored in — meaning 82% can reasonably be downgraded. Notably, this isn't a one-off number: Datadog's 2025 report found the exact same 18% figure, which makes this less a curiosity and more a durable pattern in how static scoring overstates real-world risk.

This article walks through what the 2026 data actually shows, why the CVSS-vs-runtime-context debate has shifted from theory to standard practice, how to prioritize GitHub security alerts with that context, and how platforms like InstaSLA can turn the resulting signal into enforceable remediation deadlines.

The Core Flaw: CVSS Measures Severity, Not Risk
CVSS is designed to measure the theoretical severity of a vulnerability in a vacuum — attack vector, attack complexity, and potential impact on confidentiality, integrity, and availability. It does not, on its own, measure risk. Risk is severity multiplied by context: is the vulnerable code actually running, actually reachable, and actually exposed to an attacker?

When an SCA scanner flags a CVE with a 9.8 base score, it's implicitly assuming worst-case conditions: the library is deployed, loaded into memory, processing untrusted input, and reachable from the internet. In sprawling microservice environments, that assumption is frequently wrong. A team might import a large library for one small utility function, leaving the vulnerable module dormant on disk but never executed.

Relying on static CVSS scores alone produces three familiar, costly outcomes:

Alert fatigue. When everything is "Critical," nothing is. As Datadog's Andrew Krug, Head of Security Advocacy, put it: "When almost everything is labeled 'critical,' nothing is." Teams get paged for noise while real threats slip through.
Wasted engineering cycles. Patching, refactoring, and regression-testing for a vulnerability that can't physically be triggered is pure overhead.
Missed true threats. Time spent chasing phantom criticals in isolated batch jobs is time not spent on the exploitable RCE sitting on a public-facing API.
What the 2026 Data Actually Shows
Datadog's 2026 report is the most detailed public dataset yet on this gap, and it's worth grounding the discussion in what it actually says, not just the headline number.

87% of organizations are running at least one known exploitable vulnerability in a deployed production service, affecting roughly 40% of services overall.
Only 18% of vulnerabilities flagged "Critical" remain critical once runtime exposure and exploitability are applied — the same figure the 2025 report found, a year apart.
Exploitable-vulnerability rates vary sharply by language: Java (59%) and .NET (47%) are the most exposed, followed by Rust (40%) and JavaScript (35%), with Python (27%), PHP (23%), and Ruby (12%) lower down. Language choice is itself a meaningful attack-surface factor.
Services running end-of-life language runtimes carry an exploitable vulnerability 50% of the time, versus 31% for supported versions.
The median dependency is now 278 days out of date — 63 days further behind than in the 2025 report, meaning the aging problem is getting worse, not better.
Cutting the other way, 50% of organizations adopt a new library version within 24 hours of its release, before it's had any time to be vetted — a real vector for supply-chain compromise via malicious or accidentally-broken releases.
On CI/CD hygiene: only 4% of organizations pin all public GitHub Actions to an immutable commit SHA, and 71% leave marketplace Actions completely unpinned — a direct line to the kind of build-pipeline compromises seen in 2025 (tj-actions, Shai-Hulud, s1ngularity).
Put together, the report's framing is that risk is rising at both ends of the software lifecycle at once: aging, un-patched production dependencies on one side, and unvetted, fast-adopted new code and CI dependencies on the other — with static CVSS scoring able to explain almost none of it.

The three practical layers that separate a theoretical CVSS score from real exploitability are worth keeping in mind when triaging:

Not loaded — the vulnerable package sits in a manifest but is a dev-only dependency, or is on disk but never actually loaded into the running application.
Unreachable — the package is loaded, but the specific vulnerable function is never called by your code paths. Reachability analysis (call-graph and AST-based) is what determines this.
Unexposed — the vulnerable function is reachable, but the service itself has no realistic attack vector: no internet ingress, isolated network segment, or a compensating control like a WAF in front of it.
A vulnerability only earns "Critical" in practice when it clears all three layers.

Redefining Exploitability Scoring: CVSS, EPSS, and Runtime Context
EPSS adds "how likely," not just "how bad"
Where CVSS estimates theoretical impact, the FIRST-maintained Exploit Prediction Scoring System (EPSS) estimates the probability a CVE will actually be exploited in the wild in the next 30 days, using a model trained on real threat-intelligence signals and updated daily. EPSS v4, released in March 2025, improved on the model's earlier accuracy. FIRST's own research shows fewer than 5% of all published CVEs are ever exploited in practice — which is exactly why blending EPSS with CVSS matters. CVE-2024-4577, a critical PHP vulnerability, is a good real example: it carried an EPSS score near 94% days before NVD had even finished publishing its CVSS score, meaning teams relying solely on CVSS feeds were blind to an actively-exploited flaw during that window.

CVSS itself is evolving toward context
It's worth noting CVSS isn't static either. CVSS v4.0 (released November 2023, broadly adopted by scanners like Tenable, Qualys, and Rapid7 through 2025–2026) added a dedicated Threat metric group, including an "Exploit Maturity" rating of Not Defined, Attacked, Proof-of-Concept, or Unreported. "Attacked" reflects confirmed in-the-wild exploitation. As of early 2026, NVD publishes CVSS v4.0 scores alongside v3.1 scores for new CVEs — though the historical backlog isn't being retroactively rescored, so most of the vulnerabilities already sitting in your backlog still carry only a base score with no threat context attached.

Runtime context via eBPF and AppSec agents
The piece neither CVSS v4's threat metrics nor EPSS supplies is your environment's reachability and exposure. This is where eBPF-based runtime agents (the same technique used by Datadog Code Security, Falco, and similar tools) come in — tracing which functions actually execute and which services actually see network traffic. Overlaying EPSS and CVSS-Threat data with this runtime reachability produces the matrix that matters operationally:

High CVSS + High EPSS + Reachable at runtime + Internet-facing → true critical, immediate action.
High CVSS + Unreachable at runtime → technical debt. Track it, don't page for it.
Most vulnerability-management guidance in 2026 also recommends layering in CISA's Known Exploited Vulnerabilities (KEV) catalog as a fourth signal — it reflects confirmed exploitation verified by a human analyst, closing the gap in the day or two where a new campaign hasn't yet moved EPSS's probability score.

How to Prioritize GitHub Security Alerts Effectively
GitHub Advanced Security and Dependabot remain strong at finding vulnerable dependencies, but their default alerting is still built on manifest matching plus static CVSS severity — not runtime reachability. That gap has drawn public criticism in 2026: Filippo Valsorda, former lead of Go's security team at Google, publicly called Dependabot a "noise machine" for flagging packages regardless of whether the vulnerable code path is ever actually used. GitHub's own documentation for Dependabot confirms it has no built-in reachability analysis — a dev-only dependency or an unused code path gets the same alert as something live in production.

To close that gap, teams are layering in tools purpose-built for reachability:

Context-aware triage via APIs. Use Actions or webhooks to intercept new Dependabot alerts and query a runtime observability platform (Datadog, or similar) to check whether the flagged package is actually loaded and reachable in production before it's treated as urgent.
Dedicated reachability/SCA tooling. Products like Endor Labs (function-level reachability across 40+ languages, with the vendor reporting up to 97% average noise reduction), Snyk (reachability analysis for Java, JavaScript, and Python, plus a vulnerability database the vendor says surfaces CVEs an average of 47 days ahead of NVD), and Socket (behavioral detection of malicious and typosquatted packages) plug directly into GitHub and GitLab pull requests. For Go specifically, the free, official govulncheck tool will tell you directly whether a flagged advisory is actually reachable from your code — treat vendor noise-reduction percentages as marketing claims worth validating against your own environment, not universal guarantees.
Automated labeling and downgrading. When runtime or reachability data confirms a vulnerability is isolated, workflows can label the alert "Context: Unreachable" and downgrade its internal severity — some teams go as far as auto-closing it as accepted risk, provided that decision is logged for audit purposes.
Surfacing the confirmed 18%. When context confirms a Dependabot alert is both reachable and internet-facing, the same pipeline should escalate it automatically and tag it as a confirmed threat.
This ensures a developer receiving a security notification knows it's backed by empirical evidence — not a raw CVSS number applied uniformly across every deployment.

Operationalizing Context: Enforcing SLAs with InstaSLA
Identifying the true 18% is only half the job. The other half is making sure those vulnerabilities actually get remediated on a defensible timeline — which is where a dedicated SLA platform like InstaSLA fits in, rather than trying to force this workflow into a general-purpose Jira board.

Dynamic, context-based SLA policies. Instead of one blanket rule ("all Critical CVSS in 7 days"), InstaSLA lets teams define rules like: Critical + Reachable + Internet-facing → 48-hour SLA; Critical + Unreachable → 90-day or standard technical-debt cadence.

Automated pausing on mitigation. If a compensating control — a WAF rule, a network policy change — cuts off exposure to a vulnerability, InstaSLA can detect the change in runtime context and pause the SLA clock, giving engineering room to land a permanent fix without an artificial deadline.

Fix campaigns for real emergencies. When a widely-reachable vulnerability does surface (a Log4Shell-style event — CVSS 10.0 in 2021, and still one of the clearest illustrations of why "loaded and reachable" matters more than the base score), InstaSLA can group only the validated, reachable instances into a single fix campaign, rather than triggering a fire drill across every repository that merely imports the affected library.

Visibility and accountability. Dashboards show exactly which context-aware SLAs are breaching, and because the noise has already been filtered, "alert fatigue" stops being a valid excuse for non-compliance — while giving security teams a defensible, evidence-based record for auditors of why certain nominally "Critical" CVEs were intentionally deprioritized.

Conclusion: Stop Triaging by Score Alone
The 2026 security landscape is too fast-moving and too fragmented to rely on a severity score computed in a vacuum. CVSS — even the more context-aware v4.0 — remains a useful dictionary of technical flaws, but two consecutive years of Datadog's DevSecOps data confirm it's a poor compass for deciding what to fix today: 82% of "Critical" findings, on average, don't hold up once runtime reachability and exposure are applied.

The fix isn't to ignore CVSS, but to stop treating it as the whole answer. Combining CVSS (ideally v4.0 with its Threat metrics), EPSS's exploitation-probability signal, CISA's KEV catalog, and genuine runtime reachability data — then enforcing the result with context-aware SLAs — is what lets DevSecOps teams spend their limited engineering time on the vulnerabilities that can actually be exploited, instead of the ones that merely look bad on paper.

Sources
Datadog, State of DevSecOps Report 2026 and Key learnings from the 2026 State of DevSecOps study, February–March 2026
Datadog, 87% of Organizations Are Running Software With Known, Exploitable Vulnerabilities, press release, February 26, 2026
Help Net Security, Your dependencies are 278 days out of date and your pipelines aren't protected, March 2, 2026
Conversational Geek Stats, What the Datadog State of DevSecOps 2026 Report Says About Runtime Security
Barchart, Datadog's State of DevSecOps 2025 Report Finds Only 18% of Critical Vulnerabilities Are Truly Worth Prioritizing
The Register, Go lib maintainer: GitHub's Dependabot is a 'noise machine', February 24, 2026
SecurityScientist, 12 Questions and Answers About Dependabot, March 19, 2026
AppSec Santa, Best Dependabot Alternatives in 2026, June 10, 2026
Cloudsmith, CVSS vs EPSS: Smarter Vulnerability Risk Prioritization
isMalicious, CVSS 4.0 Explained: A Complete Guide to Vulnerability Severity Scoring in 2026, April 17, 2026