What do teams get wrong about vulnerability data and attack simulation?

Why This Matters for Security Teams

Vulnerability scanners and attack simulation tools are often used as if they answer the same question, but they do not. A long list of findings does not prove a path to compromise, and a successful simulation does not mean every alert reflects real exposure. Security teams need evidence of chainability inside their own environment, not just disconnected indicators. That distinction is central to prioritisation and to board-level reporting.

The practical risk is overconfidence in coverage. Teams may close noisy findings while missing the small set of weaknesses that can be combined into privilege escalation, lateral movement, or secret theft. This is especially true when credentials are exposed or overprivileged, as shown in Ultimate Guide to NHIs - Key Research and Survey Results, which notes that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secrets managers in vulnerable locations. In practice, many security teams discover exploitability only after an attacker has already chained the conditions together, rather than through intentional validation.

Threat intelligence and external advisories help with context, but they should not be mistaken for environment-specific proof. The CISA cyber threat advisories and NHIMG research such as 52 NHI Breaches Analysis are most useful when they sharpen questions about reachable impact, not when they are used as stand-alone evidence.

How It Works in Practice

Effective prioritisation starts by testing whether a weakness is reachable, exploitable, and chainable. That means joining vulnerability data with identity exposure, segmentation, secret hygiene, and actual trust relationships. A critical but underused lens is non-human identity, because service accounts, API keys, and automation tokens often provide the shortest path from a low-severity issue to a high-impact compromise. NHIMG’s Ultimate Guide to NHIs - Why NHI Security Matters Now is especially relevant here because it frames NHI risk as a control-plane problem, not just a patching problem.

In practice, teams should validate three layers:

• Exposure: can the asset, secret, or service be reached from an attacker-controlled position?

• Abuse path: can the issue be combined with another weakness, such as weak role boundaries or leaked credentials?

• Outcome: does the chain lead to data access, code execution, privilege escalation, or persistence?

That approach aligns with adversary-focused models like the MITRE ATT&CK Enterprise Matrix and control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls, which both push teams toward observable attack paths and compensating controls. A simulation has value when it proves that a chain works under your conditions, with your credentials, and against your segmentation. These controls tend to break down when environments rely on sprawling service accounts, weak secret rotation, and inherited privileges because the real attack path becomes easier than the documented one.

Common Variations and Edge Cases

Tighter validation often increases operational overhead, requiring organisations to balance better signal against slower remediation cycles. The biggest edge case is when simulation tools are run in clean lab conditions and then treated as evidence for production reality. Current guidance suggests that this is unsafe for cloud estates, CI/CD pipelines, and agentic workloads, where access paths can change quickly and secrets may be reused across systems.

Another common mistake is assuming every severe vulnerability is immediately exploitable. That is not always true, especially when compensating controls block reachability or when the vulnerable component is isolated. The reverse is also true: low-severity issues can become critical if they expose a token, a misconfigured vault, or an automation path. This is why NHIMG’s Top 10 NHI Issues and JetBrains GitHub plugin token exposure matter operationally: they show how credential leakage and token misuse often outrank the original flaw.

There is no universal standard for turning simulation outputs into a single risk score yet. Best practice is evolving toward adversary emulation, attack path analysis, and business-context prioritisation. External reporting such as Anthropic - first AI-orchestrated cyber espionage campaign report also reinforces that automated attackers adapt quickly, so static scoring alone will miss the real operational risk.

Related resources from NHI Mgmt Group

• What do security teams get wrong about linking vulnerability data with asset inventory?
• What do security teams get wrong about using attack simulation to prioritise remediation?
• What do security teams get wrong about backup-based recovery?
• What do security teams get wrong about access reviews for sensitive data?