How the CVE contract scare exposed the public plumbing under every patching policy
For a day in April 2025, the program that names software flaws looked set to stop. It revealed that patching policies and audit evidence rest on three public layers, identification, enrichment and prioritization, each with its own failure mode.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On April 15, 2025, MITRE told members of the CVE program that its contract to run the Common Vulnerabilities and Exposures program would expire the next day. It warned that operations could be interrupted. The CVE system assigns the standard identifiers that vendors, scanners, patch tools and security teams use to refer to specific software flaws. Late on April 15, CISA said it had executed an option period on the contract to avoid a lapse, an extension that ran 11 months to March 2026. On April 16, a group of CVE board members announced a nonprofit CVE Foundation to pursue more independent governance. The scare came on top of a backlog at NIST’s National Vulnerability Database that had been growing since early 2024.
Few organizations list the CVE program in their risk register. It sits so deep in the security stack that it feels like a law of nature. The April 2025 scare showed it was a government contract with an expiry date and a single sponsor. For banks, health systems and agencies, the more useful exercise is to trace how their own vulnerability management, and the audit evidence built on it, depends on public infrastructure. That dependency has three layers. Identification gives each flaw a shared name. Enrichment adds the severity and product data that make the name useful. Prioritization turns both into decisions. Each layer is owned by someone different and degrades in a different way.
Identification: the shared name for a flaw
A CVE identifier is the key that links a vendor advisory, a scanner finding, a patch, a threat report and a line in a software bill of materials. Numbering authorities, including many large software vendors, assign identifiers under program rules. MITRE operated the program under the CISA contract, and by 2025 the network of numbering authorities exceeded 460 organizations, according to CISA.
Had identification stopped, existing records would have remained. New flaws would have lacked a common name. Vendors would have published under their own schemes, scanner vendors would have built mappings, and the same flaw could have appeared under several labels. The damage would have built over weeks, which is why it is easy to underestimate.
The second-order effects reach beyond the security operations center. Vendor security questionnaires, contract clauses that commit suppliers to patch critical CVEs within set periods, and software bills of materials all refer to flaws by CVE identifier. A gap in identification would have weakened procurement and vendor management language that most organizations never think to review.
Enrichment: the data that makes a name useful
An identifier alone says little. Enrichment adds a severity score, the list of affected products and versions, and a weakness classification. In the United States, much of this came from NIST’s National Vulnerability Database. Since early 2024, the NVD had struggled with a growing backlog of records awaiting analysis.
That backlog had already broken many patching policies before April 2025. A rule that says “remediate anything NVD rates critical within a set number of days” fails silently when new records have no NVD score. Teams that noticed had begun pulling scores from vendor advisories, CISA’s own enrichment work and commercial feeds. Teams that did not were applying their policy to a shrinking share of new vulnerabilities.
Product data matters as much as scores. Without an accurate list of affected products and versions, a scanner cannot match a new record to the assets that carry it. Some flaws then go undetected in the environment even though they are known to the world.
The fix is to treat enrichment as a supply chain with several sources and a stated order of precedence. A policy can say that the vendor’s own severity rating governs, the NVD score applies when the vendor gives none, and the security team assigns a provisional rating when both are missing. That sentence takes an hour to write and closes a gap examiners and auditors are starting to notice.
Prioritization: deciding what to fix first
The third layer belongs to each organization. It combines severity, evidence of exploitation, exposure of the affected asset and its business importance. CISA’s Known Exploited Vulnerabilities catalog has become a central input. Federal civilian agencies must meet its deadlines under a binding operational directive. Banks, health systems and state agencies use it voluntarily as the strongest public signal that a flaw is being used in attacks.
Prioritization inherits every weakness in the layers below it. If identification slows or enrichment thins out, the prioritization engine still produces a ranked list. It simply ranks incomplete data, and dashboards look healthy while coverage erodes. A useful control is a coverage metric: the share of new vulnerabilities in the environment that have a severity rating and an affected-asset match within a set number of days of publication.
Regulated organizations face a specific trap here. Examiners and auditors ask for evidence that critical vulnerabilities were remediated within policy timelines. If the policy is defined entirely by one external score and that score is missing, the organization cannot demonstrate compliance even when it acted correctly. Policies written around internal risk tiers, informed by several external sources and by the organization’s asset inventory, survive a disruption in any one source.
Across all three layers, the test is the same. Could the program still identify, enrich and prioritize if one public source went quiet for a month? Answering it requires tools that ingest vendor advisories directly, a written precedence order for severity, and an asset inventory accurate enough that exposure as well as severity drives the queue.
The exercise also clarifies ownership. Identification belongs to a public program, enrichment to a mix of public and vendor sources, and prioritization to the organization itself. Only the third is fully in its control. A program that invests there, in asset inventory, exposure mapping and exploitation intelligence, depends least on the first two.
With hindsight
The program did not lapse. In September 2025, CISA published a strategic vision describing a “quality era” for CVE and argued the program should remain publicly maintained and vendor-neutral. In March 2026, CSO Online reported that the contract had been renegotiated to remove the looming expiry, and a CISA official said the program was fully funded. In Europe, ENISA launched the European Vulnerability Database in May 2025 under the NIS2 Directive, adding a second reference service.
Enrichment proved the weaker layer. On April 15, 2026, NIST said the NVD would stop trying to enrich every CVE. It would prioritize CVEs in CISA’s KEV catalog, in federal government software and in critical software. Older backlogged records moved to “not scheduled.” Programs that had already written a precedence order for severity sources absorbed the change. Those keyed to NVD scores alone had to rewrite policy.