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.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “87% Run Exploitable Code in Production, and 98% of "Critical" Alerts Downgrade at Runtime”.
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.
- Security teams spend 80% of their time on triage rather than fixes.
Key questions
Q: What should teams do first when critical vulnerabilities are not exploitable in production?
A: Start by separating findings that are actually reachable from those that only look severe in a generic scanner.
Q: Why do runtime and reachability checks reduce vulnerability triage overload?
A: Because they convert a broad list of theoretical weaknesses into a smaller set of findings that an attacker can genuinely reach.
Q: What are the signs that vulnerability severity scoring is failing your programme?
A: Common signs include critical queues that never shrink, repeated escalations that end in downgrades, and engineering teams losing trust in security tickets.
Practitioner guidance
- Implement runtime reachability triage gates Require a reachability check before a critical finding enters the highest-priority remediation lane.
- Re-rank findings by live exploitability Separate findings that are reachable in public or authenticated production paths from those that only exist in test, dead code, or internal-only utilities.
- Track alert inflation as a governance metric Measure the share of criticals that are downgraded after runtime analysis and report that ratio alongside mean time to remediate.
Bottom line: Runtime context can turn a severe-looking vulnerability into a low-priority issue when the attack path is not reachable in production.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:28 pm
Runtime reachability is now a prioritisation control, not a scanning enhancement. Static vulnerability scores are useful for cataloguing weakness, but they cannot tell a team where production exposure actually exists. Once reachability data is available, the question changes from 'what is vulnerable?' to 'what can an attacker reach today?', which is the level at which remediation decisions should be made. Practitioners should treat that as a governance shift, not a tuning exercise.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations prioritise exploitable production exposure over raw vulnerability counts?
A: Yes. Raw counts describe inventory, not risk. Organisations should prioritise vulnerabilities that are reachable in production, exposed through real authentication paths, or already tied to live traffic. That approach aligns remediation effort with actual attack surface instead of alert volume.
👉 Read our full editorial: Runtime reachability makes critical vulnerability triage meaningful