Notifications
Clear all
Topic starter
16/09/2026 9:21 am
TL;DR: Traditional vulnerability management can miss exposure that appears between scans, leaving teams with a point-in-time view while threats change daily, according to Hadrian. The practical issue is verification, not just discovery: security programmes need continuous testing that confirms whether a weakness is still exploitable, not merely recorded.
NHIMG editorial — based on content published by Hadrian: Six Months Later: Vulnerability Management Has a Verification Problem
Questions worth separating out
Q: How should security teams verify that a vulnerability is still exploitable after a scan?
A: They should re-test high-risk findings against the current runtime state, not the original scan snapshot.
Q: Why do point-in-time pentests miss important risks in fast-changing environments?
A: Because the environment often changes faster than the test cycle.
Q: What do security teams get wrong about vulnerability management in complex environments?
A: They often treat the software flaw as the whole problem.
Practitioner guidance
- Build continuous exploitability checks Validate whether high-risk findings are still reachable after configuration changes, not only during scheduled scans.
- Tie vulnerability review to change events Trigger re-verification when workloads, permissions, or network exposure change so the finding is reassessed against current state rather than stale baseline data.
- Separate discovery from proof Treat asset discovery, vulnerability identification, and exploitability validation as distinct stages with different owners and outputs.
What's in the full report
Hadrian's full blog covers the operational detail this post intentionally leaves for the source:
- How the verification gap shows up in real pentest and exposure-management workflows.
- The specific operational differences between static scanning, manual testing, and agentic-powered validation.
- Examples of asset-context signals that reduce false positives and improve remediation prioritisation.
- Why the vendor argues automation changes the cadence of security validation.
👉 Read Hadrian's analysis of the vulnerability management verification gap →
Vulnerability management is a verification gap now?
Explore further
16/09/2026 9:21 am
Verification failure, not discovery failure, is the real governance gap. Many programmes can produce a list of vulnerabilities, but they cannot always prove which ones are still exploitable under current conditions. That is a control problem, not a reporting problem. In NIST-CSF terms, the issue sits between identify and protect, where validation should confirm that risk treatment still matches reality. The practitioner conclusion is that exposure management must prove current exploitability, not just document historical findings.
A question worth separating out:
Q: How should teams prioritise remediation when verification and scan results disagree?
A: Prioritise the issues that are both exploitable now and exposed through a live path to impact. If verification shows the vulnerability is no longer reachable, downgrade it; if it remains reachable through identity or network paths, keep it at the top of the queue.
👉 Read our full editorial: Vulnerability management now has a verification problem
