Your DevSecOps Platform Calls Almost Everything Critical. Runtime Context Disagrees.
A pipeline scanner labels a finding critical from the artifact alone. It has no record of whether that package sits idle in a dormant image or runs a customer-facing service in production. That is the blind spot at the center of every DevSecOps platform runtime context gap: Datadog’s State of DevSecOps Report 2026 draws on telemetry across tens of thousands of applications. Published February 26, 2026, it found that only 18% of vulnerabilities labeled critical remain critical once runtime context is applied. The rest keep the same CVE label and lose the urgency that label implied.
Datadog’s head of security put the operational cost in plain language in Datadog’s press release on the report: when almost everything is labeled critical, nothing is. Teams get paged for noise while threats that pose real risk slip through. Without context, prioritization gets harder, burnout rises, response slows, and risk accumulates. Teams need better visibility into what actually requires action. That argument comes from a vendor with no CMDB product to sell. It is still the argument DevSecOps programs need when severity without estate context becomes the default operating model.
What DevSecOps finds versus what it records
DevSecOps platforms excel at finding. They scan images, dependencies, infrastructure as code, and pipelines. They attach CVSS-style severity to what the artifact contains. That is necessary work. It is incomplete work when the queue is sorted only by that score.
Runtime context answers different questions. Is the vulnerable component deployed? Is it reachable from the internet? Which business service depends on it? Who owns the CI? What else fails if that host or package is patched under emergency pressure? A finding on a never-deployed build is not the same work item as the same CVE on a production payment path. Scanners without that join keep both tickets in the same critical bucket.
The 18% figure is the size of the signal after context is applied. The other 82% did not vanish as CVEs. They stopped deserving the same page-now treatment. Programs that treat the full critical list as equally urgent spend scarce engineer hours on the 82% while the 18% waits in the same pile.
Why do critical vulnerabilities lose urgency after runtime context is applied?
Most critical labels come from artifact scanners that score the package or image alone. Runtime context adds deployment status, exposure, and service criticality. Datadog’s 2026 DevSecOps research found only 18% of critical-labeled findings stay critical once that context is applied, which shrinks the true emergency queue.
The volume problem makes context blindness dangerous
Severity noise would be manageable if queues were short. They are not. According to Pixee, which summarizes industry remediation benchmarks, OX Security’s 2026 Application Security Benchmark found that organizations average 865,398 open alerts each, up 52% year over year. Against that backlog, manual triage cannot re-rank every ticket by hand each week.
Dependency lag compounds the pile. Datadog reported that the median dependency now trails its latest major version by 278 days, up from 215 days the year prior. Old libraries keep generating findings. New scans keep adding rows. Time-to-exploit pressure makes delay costly: Mondoo’s 2026 figures, cited in the Pixee roundup, show average time-to-exploit shrinking from 63 days to 5 days. The window to sort signal from noise is shrinking while the alert count grows.
Context-blind severity scoring stops being merely imprecise under that load. It becomes dangerous. When every new critical looks identical in the queue, the human sorting function fails first. Burnout and slower response are not soft culture problems. They are predictable outcomes of volume without a runtime filter. That is also why teams increasingly reach for Reduce MTTR with Xurrent Ticketing & Virima Service Mapping instead of another severity plugin on the same scan data.
Help Net Security’s coverage of the same Datadog report ties supply-chain risk and security debt to the same pattern: more findings without better prioritization does not equal more safety.
Where the 82% goes, and why it matters
Datadog’s framing is the right one. The operational failure is not that 18% of critical findings deserve action. It is that the other 82% bury them. Vulnerability alert fatigue is the mechanism. Engineers learn that critical often means “scanner said so,” not “production will burn.” Real production risk then competes with dormant images and internal-only paths for the same response capacity.
Datadog also found that 87% of organizations run at least one exploitable vulnerability in a production service, affecting 40% of those services. Production risk is already present for most estates. Known-exploited backlog data tells a similar story on remediation completion. CNI Solutions’ 2026 patch management statistics cite Verizon’s 2025 DBIR finding that only 38% of catalogued known-exploited vulnerabilities were fully remediated. Finding is not the scarce resource. Finishing the right work is. Programs that want a starting point can review a Virima blog post on vulnerability data from NIST NVD lookups before layering more scanner output on top of an already-full queue.
When almost everything is labeled critical, the label stops allocating attention. The 18% that still matter after runtime context need a shorter path to the top of the queue. That path is not another severity plugin on the same artifact. It is a join to what is running, who owns it, and what breaks if it changes.
How does alert volume undermine DevSecOps vulnerability prioritization?
Organizations average hundreds of thousands of open security alerts, with year-over-year growth that outpaces manual triage. When scanners also mark most findings critical without runtime context, engineers cannot separate production-exposed risk from dormant or low-blast-radius noise, so real threats compete with false urgency.
What single input is missing from most DevSecOps severity scoring?
Vulnerability scanners answer whether a CVE exists in an artifact; they do not answer whether it is deployed, internet-reachable, or tied to a revenue-generating service. Closing that gap requires asset ownership, deployment status, and blast-radius context from a discovery-sourced CMDB, not another severity model layered on the same scan data.
Severity score versus runtime reality
The table below follows Datadog’s distinction between what the scanner records and what changes when runtime context is applied.
| Dimension | What the scanner records | What runtime context adds | What changes once it is applied |
|---|---|---|---|
| Exposure | CVE present in a package or image layer | Internet-facing versus internal-only path, network reachability | Same CVE may drop from emergency to scheduled if it cannot be reached from untrusted networks |
| Deployment status | Vulnerable component exists in a build artifact | Running in production versus dormant image, unused environment, or never-deployed tag | Idle artifacts leave the page-now list even when the CVE label stays critical on paper |
| Service criticality | Generic severity from the vulnerability database | Which business service, customer path, and owner depend on the CI | Identical CVEs on a lab host and a revenue service stop sharing the same priority band |
What closes the loop
A DevSecOps platform should keep doing what it does well: detect vulnerabilities in the pipeline and the estate it can see. The missing input is not another scanner brand. It is authoritative asset ownership, deployment and runtime placement, and blast-radius context that turns an 18%-signal into a queue humans can clear. Closing that gap follows three steps: confirm ownership, check deployment status, then map blast radius through service context, the sequence that turns generic severity scoring into critical vulnerability prioritization teams can actually act on.
That context lives in discovery-sourced inventory and a CMDB that stays current enough to trust, plus service dependency maps once service definitions are supplied. High-frequency discovery cycles refresh what is running and how it connects. Ownership and CI relationships tell responders who acts. Service maps show which customer-facing path sits behind a vulnerable host or package. Fed into the same prioritization workflow the DevSecOps tool already drives, those fields reorder work without asking security engineers to rebuild the CMDB in a spreadsheet every sprint. For SecOps teams running Datadog or Sysdig alongside ServiceNow, Jira, or Ivanti at 500-plus employee organizations, this is usually the missing layer, not a missing scanner. Teams standing up that workflow for the first time can start with a Virima blog post on keeping CMDB data accurate without manual updates.
Virima sits in that foundation layer, anchored in discovery-sourced runtime truth rather than another layer of scanner output. Hybrid agent-based and agentless discovery, CMDB population, and ViVID™ service maps (built after service definitions are supplied) form that foundation. Together they give vulnerability and DevSecOps workflows a clearer view of what is deployed, what it supports, and what else moves when you patch, the blast-radius vulnerability triage a severity score alone can’t provide. Virima does not replace the DevSecOps platform or the scanner. It reduces the chance those tools rank work against an incomplete estate. Virima integrates with ServiceNow, Jira, Ivanti, and many more that teams can explore on the integrations page.
When runtime and service context sit beside severity, the critical list shrinks toward the findings that still deserve the label. That is runtime context security teams can act on, not another severity plugin. Teams page less for noise and spend more cycles on the production risk already present in most organizations.
What data should feed a DevSecOps platform after scanners assign severity?
DevSecOps platforms need asset ownership, deployment and runtime placement, and blast-radius or service dependency context after scanners assign severity. Those fields separate production-exposed critical findings from dormant or low-impact noise so teams act on the minority of critical labels that remain urgent once runtime context is applied.
See the CMDB fields that turn an 18%-signal into a clean, ranked queue: deployment status, ownership, and blast radius, explained.
Closing the gap between scanner severity and production risk
DevSecOps platforms find more than teams can manually rank. Datadog’s 18% figure shows how much of the critical label evaporates when runtime context is applied. Alert volume, aging dependencies, short exploit windows, and incomplete remediation of known-exploited issues make context-free queues a liability. Feed the platform estate truth. Keep the scanner. Change the order of work.
If your critical queue still looks like the full scan export, start with what is running and what it supports, not with another pass of the same severity model alone.
Schedule a demo to walk through discovery-sourced inventory and ViVID™ maps as context for the DevSecOps and vulnerability tools you already run.
Frequently Asked Questions
Do DevSecOps platforms overstate critical severity on purpose?
Not as a product goal. Most critical labels come from artifact and CVE scoring without full runtime placement. Datadog’s 2026 research shows only 18% of those critical labels still look critical after runtime context, which means the scoring model is incomplete for production triage rather than intentionally inflated for marketing.
Can security teams triage hundreds of thousands of alerts manually?
Not at the scale reported in recent application security benchmarks, where organizations average well over 800,000 open alerts and year-over-year growth stays high. Manual re-ranking collapses when every new finding also arrives marked critical without deployment and service context.
Should teams replace their DevSecOps scanner with a CMDB?
No. Scanners detect vulnerabilities in pipelines and artifacts. A discovery-sourced CMDB and service maps supply ownership, deployment status, and blast radius so the same DevSecOps platform can prioritize the findings that remain urgent in production. The tools solve different layers of the same workflow.
Does Virima work alongside DevSecOps tools like Datadog or Sysdig, or does it replace them?
Virima does not scan code, images, or pipelines. It supplies the asset ownership, deployment status, and ViVID™ service map context that DevSecOps platforms lack, so the scanner’s output can be re-ranked against what’s actually running and who owns it.
