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.
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.