Non-reachable vulnerabilities: what should AppSec teams do first?

TL;DR: Scanner queues are overloaded by high-CVSS findings that are never reachable in a given environment, according to Nullify, and the answer is to score severity from deployment and exposure rather than score alone. That shifts triage from database-driven attention to evidence-driven priority, which is now essential as both defenders and attackers automate more of the work.

Editorial analysis by NHI Mgmt Group, based on content published by Nullify: “Stop Paying to Triage Vulnerabilities That Were Never Reachable”.

Key questions

Q: How should teams decide which security findings to fix first?

A: Prioritise findings that are both reachable and tied to active code paths.

Q: Why do high-severity scanner findings often turn out to be low priority?

A: Because scanners usually score the worst possible outcome, not the outcome in your environment.

Q: What are the signs that OT vulnerability triage is failing?

A: Common signs include long lists of critical findings with no remediation order, repeated arguments between security and operations, and tickets that omit asset role or production impact.

Practitioner guidance

• Require deployment evidence before escalating critical findings Do not let CVSS alone determine remediation priority.
• Map repositories to live cloud workloads Build and maintain an artifact-to-infrastructure graph that links images, buckets, and packages to the compute resources that really use them, including replicas and shared services.
• Suppress weak matches before they reach triage Drop speculative links below a clear confidence floor so name similarity does not become false evidence.

Bottom line: The article argues that vulnerability management breaks down when teams treat theoretical severity as if it were equivalent to environmental risk.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →