Guest blog courtesy of WatchGuard.
Vulnerability management has never been just about finding flaws. It is about understanding which flaws matter most, which ones attackers are likely to exploit, and which ones security teams need to prioritize before they become a real business risk.That is why CVEs, CVSS scores, and vulnerability enrichment matter so much. They give defenders a shared language for tracking, discussing, prioritizing, and remediating security issues across tools, teams, vendors, and industries.But what happens when that shared context becomes harder to rely on?In Episode 377 of The 443 Podcast, Marc Laliberte and Corey Nachreiner discuss the potential impact of the U.S. National Institute of Standards and Technology, or NIST, stepping back from its previous role in enriching CVE records. The change raises an important question for security teams: if less independent vulnerability context is available, how should defenders prioritize risk?This is where context becomes critical. A high-severity vulnerability on an isolated system may not carry the same urgency as a slightly lower-scored vulnerability on an exposed, business-critical asset. Severity matters, but exposure and exploitability often determine urgency.
CVEs need context to be useful
A CVE is valuable because it gives security teams a common reference point. Without that shared identifier, organizations can quickly run into the same problem seen with malware naming conventions, where different vendors and tools use different names for the same threat.CVEs help bring consistency to vulnerability tracking. They support vulnerability scanners, patch management tools, penetration testing workflows, detection logic, risk dashboards, and compliance reporting. In other words, CVEs are not just labels. They are part of the operational foundation that many security programs rely on.The challenge is that a CVE alone does not tell the full story.Security teams also need enrichment. That includes details such as severity, exploitability, affected products, attack complexity, required privileges, user interaction, and whether a vulnerability is being actively exploited. Without that context, teams may know that a vulnerability exists, but still struggle to understand how urgently they need to act.Why NIST’s role has mattered
Historically, NIST has played an important role through the National Vulnerability Database by enriching CVE records with additional information, including CVSS scores. These scores are not perfect, but they help defenders triage large volumes of vulnerabilities.As Marc notes in the episode, CVSS scoring is not always a perfectly precise science. It can feel like an art form because complex vulnerabilities are distilled into a set of standardized metrics that produce a score from zero to ten. Even two critical vulnerabilities with similar scores may present very different real-world risks depending on exposure, exploitability, and environment.Still, independent scoring has value.Without NIST providing that additional layer of analysis at the same scale, organizations may need to rely more heavily on Certified Numbering Authorities, vendors, researchers, or other third parties. That creates a potential trust and consistency issue. Vendors may be perceived as having an incentive to downplay severity, while researchers may be perceived as having an incentive to emphasize impact. Independent enrichment helps balance those perspectives.The real problem is prioritization
The volume of disclosed vulnerabilities continues to grow, and security teams already face more issues than they can patch immediately. That means the central question is not simply “What is vulnerable?” The better question is “What should we fix first?”A strong vulnerability management program should look beyond CVSS alone and evaluate multiple risk signals, including:- Whether the vulnerability is being actively exploited
- Whether the affected asset is internet-facing
- Whether the vulnerable system supports critical business operations
- Whether attackers can exploit the flaw remotely
- Whether authentication or user interaction is required
- Whether compensating controls are already in place
- Whether a patch or mitigation is available




