Notifications
Clear all
Topic starter
20/08/2026 5:48 pm
TL;DR: Runtime analysis can cut through CVSS noise by showing that only 18% of “critical” vulnerabilities stayed critical in production, while 87% of organisations still run at least one exploitable vulnerability, according to Pixee. The governance problem is not finding more issues, but separating theoretical risk from reachable exposure before triage capacity collapses.
NHIMG editorial — based on content published by Pixee: Runtime reachability makes critical vulnerability triage meaningful
By the numbers:
- Only 18% of vulnerabilities labeled critical stayed critical after runtime analysis.
- 87% of organizations run at least one exploitable vulnerability in production.
- Dependencies average 278 days out-of-date, up from 215 days last year.
Questions worth separating out
Q: How should security teams prioritise CVEs in production environments?
A: Prioritise CVEs by verified exposure, not just severity.
Q: Why do severity-based vulnerability queues fail in modern environments?
A: Severity-based queues fail because they sort by theoretical impact instead of practical exploitability.
Q: What do security teams get wrong about runtime vulnerability scoring?
A: They often treat runtime analysis as an optional refinement instead of a governance control.
Practitioner guidance
- Implement reachability checks before severity escalation Require analysts to confirm whether the vulnerable code path is internet reachable, privilege gated, or blocked by upstream controls before assigning urgent remediation.
- Cross-reference findings with deployment and auth boundaries Use deployment manifests, service mesh policies, and authentication middleware to determine whether a flaw sits behind a meaningful access barrier.
- Track runtime exposure alongside dependency age Measure how long critical dependencies remain deployed in exposed services, not just how long they have been unpatched.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- The five-question runtime reachability check in more implementation detail for real triage workflows.
- The dependency velocity data by stack and how it affects backlog management.
- The analysis of why CVSS overstates risk in production environments.
- The specific remediation-capacity arguments behind the triage automation case.
👉 Read Pixee's analysis of runtime reachability and critical vulnerability triage →
Critical alerts that are not exploitable: what teams should do?
Explore further
20/08/2026 6:28 pm
Runtime reachability is becoming the missing control plane for vulnerability governance. Static severity scoring cannot tell teams whether a flaw is reachable through the actual service boundary, authentication path, or deployment topology. That gap turns vulnerability management into a volume exercise instead of a risk exercise. Security leaders should treat reachability as a control signal, not an optional enhancement.
A question worth separating out:
A: Reassess it in the context of the access boundary, then map compensating controls before escalating remediation. If the flaw sits behind strong authentication, internal-only routing, or a blocked input path, the response should reflect that reduced exposure. The issue still matters, but not at the same priority as a public exploit path.
👉 Read our full editorial: Runtime reachability makes critical vulnerability triage meaningful
