Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

EPSS: Early warning or not? EPSS is a predictive scoring model, and security teams assume it is an early warning signal. Nucleus research across 18% of CISA KEV-listed CVEs over 6 months found it isn’t.

NIST’s recent update to the National Vulnerability Database (NVD) marks a turning point for enterprise vulnerability management teams. It’s not broken; it hit scale limits that NIST was forced to address. Now, every vulnerability management program built around it has a problem.

Most vulnerability programs are built to act when risk looks obvious, such as when a vulnerability lands in CISA KEV, a public exploit emerges, or EPSS rises. This approach is rational because it provides a clear, defensible trigger for action. But it often comes with delay: by the time signals are strong enough to drive consensus, the window to get ahead of risk may already be closing.

Everyone is calling Claude Mythos a watershed moment. I’d like to offer a slightly different take. Not because the capability isn’t real, it is. But if Mythos is the moment that finally convinced your organization that rapid vulnerability discovery is an existential threat, you’ve been watching the wrong thing. We saw this coming. Vulnerability Management has been moving in this direction for years, and we built Nucleus with this trajectory in mind. What surprises me is the surprise.

For years, vulnerability management has followed a familiar pattern: discover assets, scan for CVEs, prioritize by severity, and remediate what you can. That model works, at least within the boundaries of systems you own. The problem is that most organizations no longer operate within those boundaries. Federal agencies especially depend on a complex ecosystem of SaaS platforms, software vendors, contractors, and open-source components.

The fastest way to reduce risk at enterprise scale is to standardize on a vulnerability and exposure management platform that unifies asset visibility, prioritizes what matters, and automates workflow to remediate. In this article, we’ll break down the nine essential requirements security leaders should insist on when evaluating an enterprise vulnerability management system, whether it’s an existing tool in their tech stack or a potential new capability.

AI is everywhere in vulnerability management right now. Technology vendors in all areas are adding new features and making bold claims about revolutionary capabilities. But here's the reality, especially for vulnerability and exposure management: more AI doesn't automatically mean less risk. The gap between AI's promise and its practical impact in enterprise vulnerability management is wider than most organizations realize.

Gartner released its 2025 Magic Quadrant for Exposure Assessment Platforms in November 2025. The new categorization detailed in the report is something we view as a natural progression in response to the way enterprise risk has evolved over the years. It’s a move away from viewing vulnerabilities in a vacuum and looking at a more complete picture of the risk today’s enterprises face.

During a recent video interview, we spent time unpacking a deceptively simple question: what actually makes a vulnerability critical? Severity scores, exploitability, and asset importance all factor into the answer. But one layer of context consistently changes the urgency of a finding more than most teams expect: internet exposure. The difference between a vulnerability that exists and one that matters often comes down to whether an attacker can reach it.

CISA recently published BOD 26-02, the latest Binding Operational Directive shaping how federal agencies manage cyber risk. While attention often gravitates toward highly visible directives like KEV, this one matters for a different reason: it raises the standard for how lifecycle risk must be tracked and sustained over time. BOD 26-02 is described as guidance on unsupported edge devices, which is accurate but incomplete.