How should security teams prioritise vulnerabilities when code scans and runtime data disagree?

Why This Matters for Security Teams

When code scans and runtime telemetry disagree, the risk is not academic. Static analysis can surface real defects that are never exercised in production, while runtime evidence can expose paths that scanners miss because of configuration, feature flags, or dynamic dispatch. Security teams that prioritise by “most findings” instead of “most reachable exposure” often waste scarce remediation effort on issues that do not change actual attack surface. NHI Management Group’s research shows how often visibility gaps distort decision-making, with only 5.7% of organisations reporting full visibility into their service accounts in the Ultimate Guide to NHIs — Key Research and Survey Results. That matters because the same pattern applies to vulnerability triage: without runtime context, teams confuse theoretical exposure with exploitable exposure. The NIST Cybersecurity Framework 2.0 reinforces that risk decisions should be tied to business context and observed conditions, not scan volume alone. In practice, many security teams encounter the true priority only after an alert has already become an incident, rather than through intentional validation.

How It Works in Practice

A defensible prioritisation process starts by treating static findings as candidate risk, not final severity. The first pass is advisory enrichment: map the scanner result to package versions, exploitability data, reachability, and asset criticality. The second pass is code-path validation: confirm whether the vulnerable function is actually invoked, whether the input is attacker-controlled, and whether compensating controls exist. The third pass is runtime confirmation: use telemetry, application tracing, or WAF and service logs to determine whether the vulnerable path is executed in production and under what conditions.

This approach is especially useful for NHI-backed services, where a vulnerable component may exist in a build but never be exercised by the service account or workflow that currently runs it. NHI Management Group’s research highlights how often organisations lack complete visibility into identity-connected assets, and that same blind spot can hide the difference between dormant code and active exposure in the State of Non-Human Identity Security. For implementation, teams should combine scanner output with policy decisions from runtime enforcement points, not treat either source as authoritative on its own. Useful controls include:

• Mark findings “reachable,” “unreachable,” or “unconfirmed” before assigning SLA priority.
• Require runtime proof for internet-facing or privilege-sensitive paths before escalation.
• Promote only issues that are both present and observed in use, unless exploitability is otherwise obvious.
• Retain dormant findings for backlog hygiene, but separate them from active remediation queues.

Current guidance suggests that runtime evidence should win when both sources disagree, but teams still need a manual review path for edge cases such as dormant admin functions, batch jobs, and feature-flagged code. These controls tend to break down when telemetry is incomplete across ephemeral containers and short-lived jobs because absence of evidence can look like evidence of absence.

Common Variations and Edge Cases

Tighter prioritisation often reduces wasted remediation, but it also increases the overhead of evidence collection, so organisations must balance speed against confidence. There is no universal standard for this yet, especially in environments with sparse telemetry or aggressive release cadence. In highly dynamic systems, a finding that is unreachable today may become reachable after a configuration change, dependency update, or new agent workflow, so “defer” should never mean “forget.”

One practical edge case is when static scan data flags a high-severity issue in shared code, while runtime confirms only a narrow execution path. In that case, remediation can be narrowed to the live path first, while the broader defect stays on the roadmap. Another edge case is when runtime logs show execution but the scanner cannot reproduce the path because of environment-specific inputs or secrets. That usually warrants elevated attention, not dismissal, because runtime evidence may be revealing a real but poorly modelled exposure. For teams building governance around this process, the operational lesson from NHI management is to pair visibility with revocation discipline, not to assume the scan is the source of truth. The Ultimate Guide to NHIs — Key Research and Survey Results is useful here because it shows how often organisations struggle with incomplete identity visibility and delayed remediation. Runtime-confirmed exposure should usually outrank static-only findings unless the code path is safety-critical, externally reachable, or already tied to an active threat campaign.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How do security teams know if identity controls are drifting into custom code?
• How should security teams decide which vulnerabilities matter when runtime data is available?
• How should security teams govern non-human identities at scale?