The Challenge
Between 2020 and 2023, CVE submissions grew 263%. Last year alone, NIST enriched almost 42,000 CVEs—a 45% year-over-year increase. Then NIST announced it would no longer analyze every vulnerability. From now on, only CVEs meeting Executive Order 14028 criteria get the full treatment.
For security teams, this wasn't just a policy change. It was a capability gap appearing overnight. If your team had been using NIST's National Vulnerability Database (NVD) as your primary source for vulnerability severity ratings, exploitability analysis, and impact scoring, you suddenly had incomplete data for your risk decisions.
One enterprise security team—let's call them the reference case—found themselves with 847 open CVEs in their asset inventory when NIST made the announcement. Of those, 312 had no CVSS score, no enrichment data, and no clear path to prioritization. Their existing runbook said "check NVD for severity, patch critical within 15 days." That process broke immediately.
The Environment and Constraints
This team operated under SOC 2 Type II controls requiring documented vulnerability management procedures. They also had PCI DSS v4.0.1 obligations for cardholder data environments, where Requirement 6.3.1 mandates security vulnerabilities are identified using reputable sources.
Their constraints were typical:
- Three security engineers covering 2,400 production instances
- Monthly compliance reporting to customers
- No budget allocated for additional vulnerability intelligence feeds
- Existing tooling (Qualys, Dependabot, Snyk) all pulling from NVD as the canonical source
When NVD enrichment stopped for lower-priority CVEs, their tools didn't fail gracefully. Vulnerabilities appeared in scans with "severity: unknown" or missing CVSS vectors. The team couldn't answer basic questions: Is this exploitable remotely? Does it require authentication? What's the impact?
Their compliance manager flagged the issue immediately. Without documented severity ratings from a "reputable source," they couldn't demonstrate they were meeting their own vulnerability management policy. Customer audits were six weeks out.
The Approach Taken
The team made three decisions in the first week:
First, they separated federal-criteria assets from everything else. Executive Order 14028 applies to software used by federal agencies. The team identified which of their components might qualify—anything touching government contracts, anything in critical infrastructure categories. Those assets would still get NIST enrichment. For everything else, they needed a new process.
Second, they implemented a hybrid scoring system. When NVD data was incomplete, they used:
- Vendor advisories (GitHub Security Advisories, product security bulletins)
- EPSS (Exploit Prediction Scoring System) for exploitability likelihood
- CISA's Known Exploited Vulnerabilities catalog as an override—anything on that list became automatic priority regardless of CVSS
They documented this hierarchy in their vulnerability management procedure and had it reviewed by their auditor before the next assessment cycle.
Third, they automated the gap detection. They wrote a script that compared their scan results against NVD entries. Any CVE without a CVSS base score after 14 days triggered a manual review. During that review, an engineer would:
- Check if the CVE appeared in CISA KEV (if yes, immediate remediation)
- Pull EPSS score (>10% probability = high priority)
- Review vendor advisory for exploitability details
- Assign an internal severity rating based on their environment
This wasn't elegant, but it was defensible. They could show auditors the decision tree and the data sources.
Results and Metrics
After 90 days with the new process, the team had:
- Cleared the backlog of 312 unscored CVEs
- Reduced mean time to severity assignment from "waiting for NVD" (indefinite) to 3.2 days
- Maintained SOC 2 compliance through two customer audits
- Identified 23 CVEs that would have been missed under the old "wait for NIST" approach—8 of which were actively exploited according to CISA KEV
The manual review process added approximately 4 hours per week of engineering time. They absorbed this by deprioritizing lower-value activities, specifically stopping the generation of monthly "top 10 CVEs" reports that no one read.
Their compliance manager noted one unexpected benefit: the new process forced engineers to understand vulnerability context rather than just reacting to CVSS numbers. When you have to read the vendor advisory and assess exploitability yourself, you learn your attack surface faster.
What They Would Do Differently
The team's retrospective identified three areas for improvement:
They should have integrated commercial threat intelligence earlier. Six months in, they finally budgeted for a vulnerability intelligence feed that provided enrichment data for CVEs outside NIST's scope. This reduced manual review time by 60%. They wish they'd made that investment in month one rather than trying to build everything internally.
Their automation was too reactive. The 14-day wait before triggering manual review meant some exploitable vulnerabilities sat in limbo. In hindsight, they should have set the threshold at 7 days and accepted the higher false-positive rate.
They underestimated the AI-assisted discovery problem. As Vincenzo Iozzo noted, AI is increasingly identifying vulnerabilities. The team started seeing CVEs from automated analysis tools that had minimal context—just "potential memory corruption in function X." These required different handling than traditional researcher-submitted CVEs, but their process treated them identically. They're now developing separate workflows for machine-generated vulnerability reports.
Takeaways for Your Team
NIST's decision isn't a crisis—it's a forcing function. Here's what you should do this quarter:
Audit your vulnerability data dependencies. Map every tool in your pipeline that relies on NVD. What happens when enrichment data is missing? Does your scanner fail? Does your ticketing system break? Does your SLA calculation stop working? Test this by manually removing CVSS scores from a sample of CVEs and running your process.
Document your alternative sources now. Before your next audit, update your vulnerability management policy to specify what you'll use when NVD data is incomplete. CISA KEV, EPSS, vendor advisories—whatever your hierarchy is, write it down and have it reviewed. This is required for PCI DSS v4.0.1 Requirement 6.3.1 and similar controls in ISO 27001.
Prioritize exploitability over severity. CVSS scores were always a rough proxy. EPSS gives you the probability of exploitation in the next 30 days. CISA KEV tells you it's already happening. Both are more actionable than a CVSS base score. Integrate these into your remediation prioritization.
Budget for intelligence. If you're managing more than 1,000 assets, the manual review burden will exceed your team's capacity. Commercial vulnerability intelligence feeds cost less than a senior engineer's salary and provide enrichment data, exploit availability, and threat actor activity. This is no longer optional for mid-market teams.
Rethink security-by-design incentives. NIST's move pushes vulnerability analysis back to manufacturers and developers. If you're building software, this means your security team needs to produce the enrichment data that NIST won't. Invest in secure development training, threat modeling, and internal security advisory processes. The alternative is shipping vulnerabilities that your customers can't properly assess.
The decentralization of vulnerability management is complete. NIST gave you the problem. What you do with it determines whether your security posture improves or degrades over the next two years.
