They often assume that if a risk matters, it will appear in a database and receive equal analysis. In practice, many important issues are delayed, deprioritised or never scheduled at all. The mistake is treating vulnerability management as a complete map of exposure instead of one input into wider risk governance.
Why This Matters for Security Teams
CVE coverage is often treated as a proxy for security maturity, but that shortcut misses the real operational problem: exposure is broader than published vulnerabilities, and not every serious weakness is assigned a CVE quickly, if at all. Security teams that rely on coverage metrics alone can end up overconfident about patch posture, while missing configuration flaws, weak identity controls, exposed secrets, or agentic AI misuse pathways that never enter the scanner’s queue.
This matters because vulnerability management is usually consumed by patching teams, but risk is owned by the business. If reporting only measures what is catalogued, leadership gets a narrow picture that can hide the issues most likely to be exploited. Current guidance from CISA's Known Exploited Vulnerabilities Catalog reinforces that prioritisation should be driven by active exploitation, not just catalog membership. In practice, many security teams encounter their most damaging gaps only after an incident proves the asset was invisible, misclassified, or never tied to a tracked CVE.
How It Works in Practice
Effective vulnerability management starts by separating discovery from prioritisation. Discovery answers what exists across servers, endpoints, cloud services, containers, applications, identities, and AI-enabled workflows. Prioritisation then asks what is exploitable, exposed, and business-critical. A mature programme combines CVE data with asset context, exploit intelligence, threat exposure, and compensating controls. That means a high-severity CVE on an isolated test system may be less urgent than a lower-profile issue on an internet-facing identity plane or a privileged service account.
Teams also need to understand what CVE coverage cannot show. A missing patch can be measured, but an insecure default configuration, weak RBAC design, exposed token, or over-permissive AI tool access may never generate a CVE. For that reason, many organisations now pair vulnerability scanning with attack-path analysis, configuration management, and secrets discovery. The CIS Critical Security Controls are useful here because they push teams toward continuous inventory, secure configuration, and proactive remediation, not just issue counting.
In practice, the workflow should include:
- asset inventory that covers infrastructure, SaaS, cloud, identity systems, and AI services
- exploitability checks using threat intelligence and evidence of active exploitation
- business context such as crown-jewel systems, external exposure, and privilege level
- exception handling for issues that are known but not immediately fixable
- cross-checks for non-CVE risk, including misconfigurations, secrets, and identity abuse paths
For AI and agentic systems, teams should also track model and toolchain weaknesses that are outside classic CVE workflows, including prompt injection exposure and unsafe tool permissions. NIST’s AI Risk Management Framework is relevant where AI systems are part of the attack surface. These controls tend to break down when asset inventories are incomplete, because untracked systems and shadow services cannot be risk-ranked or remediated through any CVE process.
Common Variations and Edge Cases
Tighter CVE governance often increases operational overhead, requiring organisations to balance reporting simplicity against meaningful risk context. There is no universal standard for how much non-CVE risk should be folded into vulnerability reporting, so current guidance suggests being explicit about what the programme covers and what it does not.
Edge cases appear in cloud-native and identity-heavy environments. A container image may be clean at build time but become exposed through a bad deployment policy. A SaaS integration may have no CVE at all, yet leak secrets through an overly broad API token. In those cases, the right control objective is not “find every CVE” but “reduce exploitable exposure.” That is also why the MITRE ATLAS knowledge base and the OWASP Top 10 for Large Language Model Applications matter when AI systems are in scope: the threat may be procedural, architectural, or identity-based rather than CVE-based.
Teams should also watch for reporting distortion. Coverage dashboards can look healthy while real risk increases because exceptions accumulate, scanners miss ephemeral assets, or remediation is measured by ticket closure instead of exposure reduction. The practical test is whether the programme can explain residual risk when the problem is not in a CVE database at all.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and CIS Controls set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Vulnerability reporting must reflect risk governance, not just scanner output. |
| NIST AI RMF | GOVERN | AI systems add non-CVE attack surfaces that need formal oversight. |
| MITRE ATLAS | AI threat pathways often bypass classic CVE-centric vulnerability workflows. | |
| OWASP Agentic AI Top 10 | Agentic systems can fail through prompt or tool abuse without any CVE. | |
| CIS Controls | 07 | Continuous vulnerability management must extend beyond counted CVEs. |
Establish accountability for AI-related exposure, including tool access and prompt risk.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
