Runtime reachability makes critical vulnerability triage meaningful

At a glance

What this is: Pixee argues that runtime reachability can downgrade most critical vulnerability findings because exploitability in production is often far lower than static severity scores suggest.

Why it matters: This matters because IAM, AppSec, and cloud teams need to prioritise reachable exposure, not just theoretical severity, or triage capacity will be consumed by non-actionable alerts.

By the numbers:

• 98% of critical .NET vulnerabilities weren't exploitable in production.
• 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.

Context

Runtime reachability is the difference between a vulnerable code path that exists somewhere in a repository and one that an attacker can actually reach in the running environment. In AppSec, static severity scores often treat those as the same problem, which is why triage queues fill with findings that are technically real but operationally irrelevant.

The article's central point is that this gap is now a governance issue, not just a tooling issue. Development velocity, dependency sprawl, and production architecture all change exploitability, so security teams need a way to separate theoretical risk from reachable exposure before remediation capacity is exhausted.

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. Check call paths, authentication barriers, deployment exposure, and live traffic before assigning top-priority remediation. That first pass prevents teams from burning engineering time on vulnerabilities that cannot be exercised in the running environment.

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. When severity is filtered by production context, teams stop treating every critical as equally urgent and can focus scarce time on issues that change real risk.

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. If the majority of top-severity findings disappear once production context is checked, the scoring model is overestimating operational exposure.

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.

Technical breakdown

Why CVSS overstates exploitability in production

CVSS is designed to rate vulnerability severity using a generic worst-case model, which makes it useful for comparability but weak for operational triage. It does not know whether the vulnerable code is behind authentication, isolated inside an internal service, or shielded by a WAF and input validation. Runtime reachability analysis adds environmental context by testing whether the vulnerable path is actually callable, which is why a critical score can collapse once the production control plane is considered.

Practical implication: Use runtime context to re-rank critical findings before they enter the remediation queue.

How reachability analysis changes the triage model

Reachability analysis asks three practical questions: can the code be invoked, under what privileges, and through which production paths. That shifts security from speculative severity to evidence-based exposure, because an internal-only batch process and a public API gateway do not carry the same attack surface. The article also shows why this matters at scale: if most critical alerts are unreachable, the triage function becomes a filtering problem rather than a detection problem.

Practical implication: Build triage around call paths, privilege requirements, and live traffic data instead of static labels.

Why dependency velocity turns prioritisation into governance

Out-of-date dependencies, unpinned build actions, and malicious packages all widen the gap between scanning and fixing. When release cycles are daily but remediation runs quarterly, security debt accumulates faster than teams can clear it. The underlying problem is not discovery. It is deciding which findings deserve engineering time, and that decision has become a governance control in its own right.

Practical implication: Set policy that ties remediation effort to real exploitability, not alert volume alone.

Threat narrative

Attacker objective: The attacker seeks to turn a theoretical code flaw into a reachable production exploit that affects real services or data.

1. Entry begins when vulnerable code exists in production but the actual attack path is blocked by deployment context, authentication, or upstream controls.
2. Credential access and privilege escalation are often irrelevant at this point because the vulnerable function cannot be reached or invoked in the live environment.
3. Impact occurs only when a finding is both reachable and exploitable, which is why runtime analysis can downgrade many theoretical criticals without changing the code itself.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Critical alert inflation is a backlog management problem disguised as a severity problem. When most criticals are unreachable, teams are not short of findings, they are short of discrimination. That creates a false sense of urgency that drains engineering time from attack surface reduction, identity hardening, and supply-chain controls that would lower real risk. The practitioner conclusion is to govern queue volume by exploitability, not by raw scanner output.

Dependency age is a security debt signal, but reachability tells you where the debt matters. Long-lived dependencies and unpinned build actions expand the number of places where exploitability might exist, yet only live paths should drive urgent work. This is where AppSec, platform engineering, and IAM intersect: production reachability depends on how services, identities, and build systems are actually wired. Teams should use that intersection to decide which risks deserve immediate remediation.

Exposure management has to outgrow the old assumption that every critical finding deserves the same response. The article shows that teams can spend most of their time on issues that are technically real but operationally inert. That assumption failure is exactly what creates triage collapse. The practical lesson is to make reachability part of the control set, because a finding that cannot be exercised in production should not consume the same response path as one that can.

From our research library:

• 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.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Reachability creates a cleaner security decision boundary: once teams can distinguish callable code from dead or shielded code, triage stops being a volume problem and becomes a risk-governance problem. That boundary is especially important in environments where identity, service exposure, and deployment topology all shape whether a vulnerability matters.

The operational signal to watch is not the number of findings alone but the proportion that survive a runtime check. When a large share of criticals downgrade after production context is applied, teams should rework SLAs, exception handling, and engineering allocation so that reachable exposure gets the fastest path to fix.

For practitioners

• Implement runtime reachability triage gates Require a reachability check before a critical finding enters the highest-priority remediation lane. Use call graphs, deployment topology, authentication requirements, and traffic evidence to determine whether the issue is exposed in the running environment.
• 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. That ranking should drive SLAs, escalation, and engineering allocation.
• 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. If most criticals are non-exploitable, the queue is not a vulnerability problem, it is a prioritisation problem.
• Reduce dependency and build-supply exposure Pin build dependencies, review stale components, and remove unused libraries that keep feeding unreachable alerts into the backlog. This lowers the number of code paths that need runtime verification in the first place.

Key takeaways

• Runtime context can turn a severe-looking vulnerability into a low-priority issue when the attack path is not reachable in production.
• The article shows that alert overload is often a prioritisation failure, not a discovery failure, because teams know about too many issues and cannot separate signal from noise.
• Security programmes should treat exploitability in the live environment as the main input to remediation decisions, or critical queues will continue to crowd out the work that actually reduces risk.

Key terms

• Runtime Reach: The total set of identities, repositories, tools, memory paths, and services an autonomous system can actually access while executing a task. It is broader than the workflow that was originally approved, and it determines the real governance boundary for agent behaviour.
• Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
• Triage Inflation: The condition where security teams receive findings faster than they can determine which ones matter. In AppSec, it usually signals weak context, poor prioritisation, or incomplete asset understanding, which causes remediation to slow even when tool coverage is high.
• Dependency Velocity Mismatch: Dependency velocity mismatch is the gap between how quickly software changes and how slowly security remediation happens. It creates accumulating exposure because new packages, builds, and releases arrive faster than teams can validate, patch, or retire risky components.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is useful for practitioners who need to connect governance discipline to access, lifecycle, and risk decisions across modern environments.