Who is accountable when reachability data is missing from vulnerability reviews?

Application security and engineering leadership are accountable for deciding whether findings are assessed as reachable, exposed, and remediation-worthy. If reachability data is absent, risk acceptance becomes harder to justify because reviewers cannot show whether a flaw sits on a real request path, which weakens both governance and audit evidence.

Why This Matters for Security Teams

Reachability data changes a vulnerability review from “this could be bad” to “this flaw is actually on a live path and matters now.” When that data is missing, teams often default to broad severity scoring, which can overstate some issues and hide others that are truly exploitable. That leaves application security, engineering leadership, and risk owners debating evidence instead of fixing exposure.

This is especially important for non-human identities because service accounts, API keys, and automation paths often create the only route from an internet-facing entry point to sensitive systems. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which means a large share of review decisions are being made with incomplete identity and path data. NIST also expects security decisions to be tied to defined controls and evidence in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams discover the absence of reachability evidence only after a finding has already been escalated, argued over, or waived.

How It Works in Practice

Accountability sits with application security and engineering leadership because they control the review standard, the evidence threshold, and the remediation decision. In a mature process, vulnerability triage should not stop at severity. Reviewers should confirm whether a flaw is reachable from an exposed request path, whether authentication or authorization is required, and whether the vulnerable component is actually deployed in the affected environment.

That usually means combining scanner output with runtime or architecture evidence: route maps, dependency traces, service topology, logs, and request-level validation. For NHI-heavy systems, the question becomes whether the affected code path is behind a secret, token, or service-to-service trust edge. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Research and Survey Results both reinforce that visibility and lifecycle control are core to reducing exposure, not optional enhancements.

• Define a review rule: no reachability evidence means no automatic “low priority” outcome.
• Require the owner to show request path, deployment context, and identity boundary before accepting risk.
• Use compensating evidence when runtime proof is unavailable, such as architecture diagrams, reverse proxy logs, or code references.
• Separate “unreachable today” from “unverified,” because those are different governance states.

Current guidance suggests the most defensible model is evidence-based triage with explicit accountability for missing data, rather than assuming a finding is safe because it has not yet been observed in production. These controls tend to break down in highly distributed microservice environments where service discovery, ephemeral workloads, and incomplete telemetry make request-path validation difficult.

Common Variations and Edge Cases

Tighter reachability review often increases operational overhead, requiring organisations to balance faster triage against stronger evidence standards. That tradeoff becomes sharper when engineering teams own their own services, because security can set the policy but cannot manufacture missing runtime data after the fact.

There is no universal standard for exactly which artifacts must prove reachability. Some teams accept a code-level call chain and environment scope as sufficient; others require live traffic evidence or production tracing. The right answer depends on the business criticality of the system, the blast radius of the flaw, and whether the finding touches an NHI-backed execution path. For externally exposed systems, CISA guidance and CISA cyber threat advisories can help justify a stricter bar for exposure claims, while CIS Controls v8 supports asset and vulnerability management discipline.

Two edge cases matter most. First, legacy systems may lack the telemetry needed to prove reachability, so leadership must decide whether to invest in instrumentation or treat those systems as higher uncertainty. Second, environment drift can invalidate old reachability decisions, especially when secrets, service accounts, or deployment routes change without review. In those cases, the accountable owner is still the same, but the decision should be time-bound and revalidated when the environment changes.

Related resources from NHI Mgmt Group

• Who is accountable when inappropriate data access is detected in an identity security program?
• Who is accountable for documenting data flows and access paths in agentic AI systems?
• Who is accountable when AI tools in security operations update alerts or modify security data?
• Who is accountable when a cloud permission is abused to stage ransomware or exfiltrate data?