MITRE is a Federally Funded Research and Development Center (FFRDC), which is a distinct type of federal contractor with strict conflict of interest regulations. They are owned by the federal government, but operated by contractors and are specifically structured and regulated to minimize conflicts of interest, so are distinct from "private industry" in many regards.
Yes, you are correct, I should have typed "runs". But the point is that MITRE runs the U.S. National Cybersecurity FFRDC that maintains the CVE system, and FFRDCs are deliberately structured to minimize potential conflicts of interest (GP comment) and are definitely distinct from private industry (parent comment).
I am quite hesitant to trust the DOD to keep track of software vulnerabilities.
Some parts are developing and exploiting vulnerabilities.
And given a fresh feed of what people find, and usually a delay from notification until publication, which may sometimes just be a bit longer of a delay, would
allow the DOD to weaponize the vulnerability for their own use as well.
This contract is funded by CISA, which is an agency within the Department of Homeland Security, not DoD. As far as I'm aware, there are no components of DHS with Title 10 or Title 50 authorities to conduct cyber operations, unless you count the Coast Guard but they normally operate under Title 14. So there really should be no conflicts of interest as no one in the DHS is authorized to exploit vulnerabilities as part of cyber operations.
This illustrates a misunderstanding of how CVE functions. It's a repository of data about disclosed vulnerabilities (even if some disclosures are embargoed and not yet published - if anyone but the bughunter and dev team that owns the fix knows about it, it's disclosed :P). The actual vulnerability discovery process is external and done by individual researchers, teams and businesses who report vulnerabilities to the appropriate groups called CVE numbering authorities (CNA) who manage the assignment and publication of CVE data through their scopes. There is not much technical advantage in terms of advance disclosure since the CNA controls what data goes to CVE.
As an example, a CNA like Mozilla, Apple, or Microsoft is unlikely to disclose vulnerability data via CVE until they have remediated the issue or have public guidance, and their embargo processes are likely separate from CVE publication.
I'm the opposite — and I think this might be the "4D chess"† interpretation of this move as well.
In peacetime, I think everyone is generally alright with something centralized like the CVE database.
But in what increasingly seems like the lead-up to wartime... I'm hesitant to trust a CVE database operated or funded unilaterally by a single government — or even multilaterally, if the governments are all ones that all would end up on the same side of a hot war.
(Why? Strategic censorship of reports while the DB's patron takes advantage of the exploit, for one. Such a database becoming a high-priority cyberwar target, for another. Strategic wasting of enemy cybersecurity resources with false announcements, for a third.)
IMHO, the ideal form for the organization managing CVE, is one analogous to IANA and its Regional Internet Registries (RIRs).
IANA slices up the keyspace of IPs to assign to RIRs, and arbitrates disputes — but both at such a high level that their work is effectively in a de-facto state of "done until something comes up". The RIRs do all the actual everyday work.
This means that in a hot war that different RIRs end up on opposing sides of, where at least some of the RIRs can no longer trust the ownership of IANA to act in their best interests, the RIRs can just ignore IANA for a while, and keep on doing their own thing (managing allocations from their previously-agreed parts of the IP keyspace), and everything will still work.
And RIRs that control parts of IP space contended over by opposed states? They can just be split up, under obvious rules (every current allocation goes to the sub-RIR associated with the state that controls the gov/mil/corp/org entity currently holding that allocation.)
That's not the case with the CVE database under its current ownership. There's no established way to namespace it, no obvious way to split it up and keep it all working.
And I think that this problem would be obvious to the DoD. Which is precisely why paying to host a single-source-of-truth CVE database loses its lustre when that same DoD is aware that such a split might soon have to happen.
---
† I dislike the term "4D chess", because it implies one chess master who's really good at predicting non-obvious outcomes — rather than an entire military-industrial-complex acting as "see something, say something" inputs to an intelligence apparatus that does a lot of hard work and simulation analyzing potential outcomes, to produce easily-digested suggestions and action items. There just needs to be one guy in the Pentagon / the military / wherever, who realized this and sent a (classified MILNET) email about it.
> That's not the case with the CVE database under its current ownership. There's no established way to namespace it, no obvious way to split it up and keep it all working.
Work on supply chain security has lead to the introduction of standardized SBOMs, as an artifact required by some large customers to accompany software binaries. It should be possible to associate each software binary CVE with a vendor SBOM and organization country code. Large multinationals might have geo-specific binaries to confirm with regional regulations like the EU CRA.
You aren’t worried about the conflict of interest with a government run system, given the desire of governments to be able to intercept all communication?
