If you have ever worked on a large software project, you already understand the basic shape of how Congress moves major legislation. So let’s analogize!
First off, there’s been a “bill” floating around that aims to change how CVE is funded and operates. But, this isn’t a normal “Schoolhouse Rock” style bill-becomes-a-law story with a simple introduction to passage narrative. “The CVE bill” is actually an amendment to the National Defense Authorization Act (NDAA), which itself is a collection of hundreds of proposals to fund America’s defense infrastructure. Imagine the NDAA as a very large, critically important Git repository with thousands of contributors, competing branches, review requirements, and a painfully Byzantine merge window. And, best of all, it happens every year. The NDAA has been passed every year since 1961, and it is considered one of the must-do pieces of legislation on the congressional calendar.
Think of the NDAA process like this: The House creates a branch of the existing U.S. Code. The Senate creates another branch. Both branches start from some common baseline, but each adds its own commits, in the form of edits and updates around new authorities, program changes, reporting requirements, funding guidance, policy changes, and amendments from individual members.
The Congressional pull request #
The U.S. House of Representatives Armed Services Committee (HASC) is preparing its own large pull request, right now. It reviews proposed changes submitted from members of the House, accepts some, rejects others, and produces a first version of this year’s NDAA. The Rules Committee then decides what amendments are allowed onto the House floor, much like how a software maintainer decides which pull requests are eligible for review.
On June 29, 2026, the House Rules Committee approved a rule allowing consideration of H.R. 8800, the FY2027 NDAA, including a set of amendments. One of the amendments was Amendment 812, which is all about the CVE program. Then, on June 30, the House rejected the rule (House resolution 1398) governing NDAA consideration.
Because that vote failed, the House never reached the stage where members debated and voted on the amendments. So, Amendment 812 wasn’t rejected, but it wasn’t merged. In other words, it got kicked back to draft status. Presumably, this will be resolved, eventually. Meanwhile, the Senate version is chugging along.
Note that the Senate version doesn’t directly mention CVE at all, so we’re not going to worry about that end of the process for now. That said, there’s some language in the Senate-proposed version around Cyber Command hiring on contractors that’s been generating some buzz lately. It’s section 1604, Scaling Cyberspace Access Generation and Maintenance Capabilities, and that, too, will have to be reconciled in upcoming conference negotiations, since there’s no direct correlation in the House version of the NDAA, but I digress.
Merge conflicts are normal #
Once the NDAA gets out of committee, and the House and Senate versions of the NDAA eventually come together, there will be conflicts. This is normal, since the House version will have some things, like the CVE overhaul, and the Senate version will lack those analogs. This is where conference negotiations happen.
For technical provisions like Amendment 812, this stage is often where the real engineering happens. Committee staff are effectively acting as maintainers, taking two large feature branches and deciding what the final release should contain. The important thing to understand is that the NDAA process has many opportunities to modify language before the final "release build" ships.
Amendment 812 and CVE #
So, now that we basically know how the NDAA is built and shipped, let’s take a look at what’s actually being proposed in Amendment 812 for CVE. I’m not a lawyer or Congressional scholar, but I am something of a CVE expert, so this is what jumps out for me.
Governance and the operating entity #
The amendment legally codifies and restructures the CVE program, officially changing the operating authority to the U.S. government under CISA, within the Department of Homeland Security. This is probably the most significant change; today, CISA is “merely” the program sponsor, while MITRE is the effective Operating Entity. This amendment also establishes a formal CVE Board to govern the program, establish its bylaws, and provide overall strategic direction.
So, today, CVE is a global, international volunteer effort, with a self-governing CVE Board to provide guidance and direction for the program. The fiddly technical bits are handled by MITRE, and all of this gets paid for by CISA (thanks to the U.S. taxpayers) on a year-to-year basis. This amendment significantly alters the terms of the deal, placing the CVE program and CVE Board directly and explicitly under the control of the U.S. government. Everything else in this amendment flows from this premise.
Composition of the Board #
The amendment proposes that the new CVE Board will be strictly capped at 15 members, balancing permanent and rotating seats in an effort to maintain a diverse, multi-stakeholder ecosystem. There will be a maximum of seven permanent members, which includes the Director of CISA (or delegate), the Director of NIST (or delegate), and designated Top-Level Root CVE Numbering Authorities. The remaining rotating members must possess relevant expertise, and are imagined as representing a cross-section of the cybersecurity community. This explicitly includes foreign government officials, CVE Numbering Authorities, academics, independent security researchers, proprietary and open-source software experts, and operational technology (OT) professionals.
This is significantly different from today’s organization: The CVE Board has 21 full members and three liaisons, and grew rather organically; it’s currently pretty heavy with U.S.-based software vendors, with a scattering of researchers (hi, it’s me, I’m the problem), a couple open-source people, a few international representatives, and no international governments. Most of these folks will be kicked to the curb if the current amendment language is included in the final bill. Many will not. Who will make the cut? That brings me to…
CISA's role in selecting board members #
The text grants the CISA Director significant appointment powers while introducing guardrails to protect the board's organizational independence. The CISA Director formally appoints all rotating members, but is legally required to seek and give consideration to recommendations from Congress, the Secretary of Commerce, industry, academia, nonprofit organizations, and the defense community. To ensure long-term continuity, the initial rotating seats are staggered, with roughly half serving three-year terms and the rest serving five-year terms. Furthermore, at least five of these initial members must be drawn from the pre-existing CVE Board in place prior to the enactment of this legislation. To prevent political interference, the CISA Director is explicitly barred from removing any member except for specific causes such as inefficiency, neglect of duty, malfeasance, or a violation of established board bylaws.
Today, CISA has no powers of appointment. But, they pay for everything, so that and the fact that they have 3 of the 24 existing board seats means that they effectively already have outsized influence on the program. This amendment gives them real, codified authority over who gets on the board, even if they’re constrained on who gets kicked out.
Modernization #
A major focus of the amendment targets long-term system stability and technical modernization for federal vulnerability management. CISA and NIST must jointly develop a comprehensive 10-year (!!) strategic plan to modernize both the CVE program and the National Vulnerability Database, focusing on data quality, seeking to significantly improve the completeness, accuracy, and timeliness of vulnerability records. It also focuses on scaling up "vulnerability enrichment," which means adding vital threat context beyond basic descriptions, such as risk severity, active exploit intelligence, and the specific tactics, techniques, and procedures (TTPs) associated with the vulnerabilities. Today, CISA runs Vulnrichment, while NIST runs the National Vulnerability Database (NVD), and many cybersecurity companies and enterprise IT shops operate their own risk assessments on day-to-day vulnerabilities. The CVE program encourages CVE Numbering Authorities to provide their own enrichment, to various levels of success. This effort is intended to smooth all that out to a common baseline of risk and threat assessments.
Notably, the modernization bits don’t really talk about more modern innovations, like federation publishing, dealing with vulnerability reports at scale (hello, AI vuln discoverers), or preserving references, all of which are bedeviling the program. But, it doesn’t exclude these technical aspects, either. And to be honest, you probably don’t want to defer these problems to a 10-year plan.
Funding and appropriations #
And finally, we get to the topic that started this whole legislative effort, funding. The proposal establishes a financial framework intended to secure the program's operations over the long term. Any funds appropriated to carry out the CVE program are authorized to be made available until expended, ensuring that budgets do not abruptly expire at the end of a single fiscal year. This is unusual for Congress, where most budgets tend to be use-it-or-lose-it, which is how taxpayers end up buying $600 hammers (side note, that anecdote isn’t exactly true, but end of year spending is very real in government nonetheless).
Interestingly, since the CVE catalog functions as a global public utility, the legislation explicitly directs the CISA Director to encourage maximum international and private sector participation, and explicitly authorizes voluntary foreign funds and services.
It’s complicated #
Please do not take our word on this. Read the text yourself, especially if you’re somehow trained in both legalese and infosecisms. I’m not a lawyer, the devil is in the details, and specific wording can have wildly unintended consequences. For example, will the board become incredibly political given this new structure? Cybersecurity, like most industries, is at its best when it’s less political and more focused on the end result.
I think there’s a lot to like in this amendment. For example, as a CVE board member, I am desperate for some actual board authority to direct the Operating Entity to update their website and ratchet up the data quality requirements for vulnerability descriptions and machine-readable data, and actually see it happen in my lifetime. I’m also quite certain that my own future on the CVE board is far from guaranteed, and incidentally, won’t be a lifetime appointment anymore (I’ve been on the CVE Board since 2017, so coming up on 10 years). This is likely very healthy for the program, but does hurt my feelings 😣 (just a little).
There’s also a lot of worry around it. If the CVE program is explicitly (rather than implicitly) a function of the U.S. Government, that might end up encouraging our international friends to find their own solutions, and ultimately re-Balkanizing the whole vulnerability-numbering space that we just now mostly got under control after 25+ years of effort. That would stink. Then again, the international community seems to have no problem with cooperating with NOAA, NASA, and other explicit U.S. government programs, and CVE could well be up there with these other American-but-also-international science and tech initiatives.
Why this matters today #
The CVE ecosystem is at a unique point in history, right now. The program has operated for decades as a globally coordinated vulnerability identification and disclosure ecosystem. It is relied upon by vendors, researchers, defenders, governments, and countless security tools.
However, “operational importance” and “legal permanence” are different things, which is ultimately what this amendment is aiming to do. Congress is now considering, and likely resolving, questions around funding, governance, modernization, sustainability, and the relationship between U.S. government authority and the international CVE community. Because this is already part of the NDAA build process, these details now matter, quite a bit.
A statutory framework can provide stability, but it can also create unintended consequences if it does not reflect how vulnerability coordination actually works in practice. That’s why input from people who understand CVE is important. If you’ve read this far, this is probably you!
What you can do #
If you care about the future of CVE, now is the time to engage. If you live in the United States, you should take some time this summer to reach out to your Representative or Senator, especially if they’re on the House Armed Services Committee or Senate Committee on Armed Services. If you’re outside the U.S., pick your favorite committee member and write to them. Pro tip: Representative Ramirez from the House Homeland Security’s subcommittee on Cybersecurity and Infrastructure Protection and Representative Whitesides from the House Armed Services Committee’s subcommittee on Cyber, Information Technologies, and Innovation jointly introduced this amendment.
Going forward, the best way to track progress of this merge saga is to flip back and forth between the Rules Committee page and the Congressional Actions page for HR8800.
In September and beyond, it gets a lot harder to edit Amendment 812 as the language becomes fixed. I implore you to not assume that someone else is explaining the technical or operational details of the CVE program. Congressional staff are good at many things, amazing even, but they cannot automatically know the ground realities of running a global vulnerability ecosystem unless the people who understand it from firsthand experience explain it to them, plainly and directly. The NDAA is still in the merge queue. There is still time to influence the language (code) that ships.
