All right, general considerations on a spec. I will admit, I havenât processed BCP-02 to a point of understandingness, so I didnât really consider it when I whipped up a spec over here. My bad.
Also, that spec is trash, and should not be used. It was an experiment to see what GCVE would do with it, derived mostly from a reading of BCP-03, which states today, âGCVE-BCP-03 does not enforce a specific JSON format for vulnerability publication.â Challenge accepted!
That said, I would strongly advise against just piggy-backing on CVE JSONv5. There is a ton of stuff in there that is obtuse, occult, and difficult for newcomers to get a handle on.
Incidentally, itâs also encumbered by mysterious trademarks, which may or may not be enforceable in all kinds of jurisdictions around the world. OSVDB ran into this kind of problem in the long-ago. The current license appears very permissive, but who knows how long thatâll last.
GCVE seems to want to be a drop-in replacement for CVE in case Something Happens with CVE (namely, the infrastructure). This is laudable and noble. So, the name of the game is a format that is both compatible with CVE, and distinct from CVE, much like how Samba interoperates with SMB. Below are some philosophical options. Iâm sure there are goals and desires for GCVE that I havenât thought of.
(1) GCVE is a drop in replacement. A valid GCVE record is a CVE record natively, and no conversion is required. A well-formed CVE record is also a well-formed GCVE record. Backwards compatibility is guaranteed, but in practice, this is tricky if GCVE has MUSTs that CVE does not, since youâll break the GCVE spec with an otherwise valid CVE record.
(2) Post-processing CVEs into GCVEs. A valid GCVE record can be derived from a valid CVE record with some processing. A GNA would only need to convert once and publish that, and the conversion is trivially implementable. GNA-0 and GNA-1 could do it, and so could anyone else. This is appealing if you have additional musts, and itâs probably possible to encode those MUSTs in some of the free-form fields already present in CVE. It also means you can throw out a bunch of things that you donât care about (unless one of those things is required in CVE records).
(3) Ignore CVE altogether. This is what I did. It didnât work out well. Conversions between the two are bespoke, artisanal solutions per GNA. This would be intentionally breaking the relationship between GCVE and CVE records, and would certainly make it clear that GCVE is not CVE. GNA-1 can handle the conversion from CVE, publish how they do it, populate GNA-0âs corpus of vulnerabilities on the CVE Projectâs behalf. However, it would also reject those CVEs that donât meet GCVEâs requirements. Backwards compatibility is totally off the table, and while some overlap is expected, it wonât be perfect, and consumers who want both will need solutions to ingest both, and choose which GNA to believe.
Notionally, I like all of these. Iâd lean toward (2), but it means a bunch of work to make GNA-0 sensible, and youâre restricted on whatâs a reasonable MUST for GCVE.
Finally: itâs entirely possible that CVE infrastructure, the online services, and the day-to-day operational work that is conducted by the MITRE corporation and paid for exclusively by US taxpayers and via the US Department of Homeland Security is not going be disrupted by political forces in February of 2026. I have no hard evidence this sad fate is in the offing. Every current employee of DHS and MITRE Iâve spoken to as of this post in August of 2025 has assured me of their personal, continuing faith in the survivability of the CVE Program, irrespective of other unforeseen and unprecedented cancellations of public-good, well-established, and critically important US government programs.
This is all to say that itâs wise to at least maintain easy compatibility with CVE records. This means ensuring that GCVE records are easily translatable to CVE records, and vice-versa.
