I did not carefully consider each reference type, but the list feels long to me, even considering there are ādoubleā entries for each direction of the relationships. Iām not sure this matters, actual use would probably show which types are useful.
Here are the types from vxref, Iām not claiming they are a better set but some collective thought went into them.
of course not, seems really relevant!
Following a recent discussion in the GCVE working group, we were wondering whether a GNA could create vulnerabilities only for the EoL references of an existing vulnerability. How is this supposed to work in practice? Would the GNA fork existing vulnerabilities, or should it create entirely new entries with relationships?
Itās maybe where the relationship plays a bigger role than originally expected.
During the GCVE working group in Paris, we decided to go for the following format for the relationships in BCP-05:
"x_gcve": {
"relationships": [
{ "dest_id": "CVE-2025-4444", "type": "equal" },
{ "dest_id": "CVE-2025-4443", "type": "subset" }
]
}
The relationship types will initially follow the VXREF set proposed by @zmanion, but they are not limited to those. The recommended types can be extended if new relationship categories are required.
I think that, in practice, a GNA could fork an existing vulnerability to add information for EoL products and also reference the vulnerability using one of the references mentioned above. The idea of a GNA maintaining only EoL products is interesting as well, but itās not mandatory. Since GNA organizations remain free to publish whatever they consider relevant. For me having the information in the metadata about the EoL products is the most important.
New draft published for BCP-05 based on the last feedback:
Feel free to comment
And (effectively, not literally) src_id is cveMetadata.vulnId right?
Yes, it is. Maybe we should be more explicit about the source in the BCP document.
Document updated following the meeting at Brest (Unlock your Brain conference),
BCP-05
has been published and now the status is DRAFT for public review.
Hi everyone,
First off, this is a really interesting draft, and I appreciate the work going into defining these structures.
I wanted to jump in with a few thoughts and suggestions from my perspective as a member of the CVE Quality Working Group (QWG). We spend a lot of time discussing the future of the record format, and I see a potential risk with relying heavily on the x_ tag structure (specifically x_gcve) that I think is worth discussing now before this BCP is finalized.
1. The future of x_ tags Currently, there is limited adoption of x_ tags in the wild, and critically, there is no central repository to manage or de-conflict them. Because of this, the QWG has actually been discussing the possibility of removing x_ tag support entirely in the next major version of the CVE JSON schema to streamline the format.
If that happens, the custom data structures defined here (like the relationships logic) would effectively become non-compliant, potentially forcing a rewrite of the standard down the road.
2. The ADP alternative I would strongly suggest that the GCVE project look at becoming an Authorized Data Publisher (ADP) as soon as possible.
Transitioning to an ADP role would solve the schema issue by allowing you to publish this data within the official adp container. This has a massive downstream benefit: instead of tools needing to write a custom parser for a āModified CVE Record Format,ā any tool that already supports the standard CVE JSON 5.0 schema (and existing ADPs like CISA) would be able to ingest GCVE data immediately.
It feels like the most robust way to āfuture-proofā the great work being done here.
Cheers, Jerry
Thanks a lot for the insightful comment, it indeed makes sense. Do you know what the actual process is to become an ADP? It seems that only CISA is one, and the procedure to obtain ADP status is neither clearly specified nor documented including how long the process takes. Do you have any insights on this?
We decided to proceed with BCP-05 and use the existing CVE format to facilitate data reuse and integration with the current CNA process. I hope we can continue to go in that direction.
I updated the GitHub issue if someone from the CVE Program board can have a look too. :
You arenāt wrongāthe ADP launch hasnāt been super smooth, and to my knowledge, there isnāt clear public documentation yet on the specific process to become one. To give you some context, as a member of the EPSS SIG, we actually tried to become an ADP back in 2024 when CISA launched theirs. We were told āfurther guidance was coming soon,ā and obviously, that has been a slow process.
That said, I firmly believe that GCVE and other alternative numbering schemes like EUVD absolutely should be ADPs. This is the correct path forward because it allows the CVE record to become the āpinnacle recordāāthe single source of truth where we can track and correlate all these other identifiers.
I am willing to bring this up in the next AWG/QWG meetings to help shepherd the process, as this use case feels like exactly what the ADP role was designed for.
Thanks all for your inputs. Decentralization and ID correlations are indeed important.
We had a discussion this morning; here are a few meeting notes.
As already explained, the main needs currently are:
The different types of relationships mentioned by Art are quite interesting. For example, we can use the type related to link a CVE ID to a GCVE ID.
For reference, the possible types are:
possibly_relatedrelatednot equalequalsupersetsubsetoverlapAn important question is the appropriate place of the x_gcve container in the JSON document.
GCVE is all about decentralization, and as Jerry mentioned, being an ADP seems the best approachāespecially to correlate identifiers, which is also fundamental in Vulnerability-Lookup. Vulnerability-Lookup is using a set of specific feeders that are able to find the correlations from advisories from various sources. Now thinking only about CVE, only a single feeder could be (in the future) able to find the correlations in the same CVE record.
However, today it is not possible to use a CNA or an ADP container. We want to continue with a pragmatic approach and, for now, focus on the content of the x_gcve container. Itās content may be moved in the future, in a ADP container.
We are currently thinking about a structure like this:
{
"containers": {
<snip>
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2025-65095",
"datePublished": "2025-11-18T15:33:00.000Z",
"dateUpdated": "2025-11-18T20:39:45.579295Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED"
},
"x_gcve": [
{
"vulnId": "GCVE-1-2025-0018",
"relationships": [
{
"destId": "CVE-2025-65095",
"type": "related"
}
]
}
],
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
Note: destId does not have to be equal to cveId. Here itās trivial because itās referencing the same vulnerability.
The example is close, but not compatible, to what is already implemented in Vulnerability-Lookup (except the ārelationshipsā part).
It focus on the GCVE identifiers and provide a way to express relationships.
It does not mention any specific software like Vulnerability-Lookup. But why not having a way to specify this information as well?
The publishing GNA entity can simply be deduced from the āvulnIdā. In this example itās 1 - āCIRCLā.
I suppose you mean in your example equal as itās the same document.
{
"containers": {
<snip>
},
"cveMetadata": {
"assignerOrgId": "00000000-0000-4000-9000-000000000000",
"cveId": "CVE-2025-65095"
"datePublished": "2025-11-18T15:33:00.000Z",
"dateUpdated": "2025-11-18T20:39:45.579295Z",
"requesterUserId": "00000000-0000-4000-9000-000000000000",
"serial": 1,
"state": "PUBLISHED"
},
"x_gcve": [
{
"vulnId": "GCVE-1-2025-0018",
"relationships": [
{
"destId": "CVE-2025-65095",
"type": "equal"
}
]
}
],
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
The issue is the lack of aliases or original references in the CVE record format. Although the current format uses a vulnId, including an alias would violate the standard JSON schema validation of the CVE program.
For instance, GitHub security advisories (GHSA) are published first in their native format and subsequently as a CVE record. However, the original GHSA reference/ID is not included in the resulting CVE record, which is a significant gap. The only reference mechanism mentioned to address this is an older CVE schema issue using the related tag within the reference section.
The major gap in the current CVE record format is its inability to describe sources with different original IDs, which is necessary for formats like CSAF and for sources such as GitHub. This limitation appears to be tied to the CVE programās current centralized model.
I will update the BCP-05 with your example and the ability to attach the metadata in ADP (if possible in the future), x_ namespace or other format which could arise later.
The BCP-05 has been published including feedback from @jgamblin and @cedric.
Now the GCVE metadata JSON is floating and can be attached to any format or ADP if GCVE become one at some point.
Some propositions for additional verbs for the relationships:
opposes: indicate that the GNA does not agree with the status of the referenced GCVE. The idea is that if a GCVE is published about a product managed by another GNA, the GNA can say that they consider that the vulnerability is not considered as valid for them (for example, because itās an expected behavior or a known discouraged configuration option for compatibility)not_applicable: this means that the referenced GCVE is not applicable in the context of the product reference by this GCVE. For example, a Linux distribution which provides a packages with specific compilation option or other settings which means that the package was never vulnerable to the referenced GCVEBoth cases are not vulnerabilities, but I think they are valuable information that are interesting to have in the GCVE ecosystem.
Thanks a lot for the feedback.
Itās now updated
if you see anything missing let us know.
If Iām reading correctly, BCP-05 supports ADP containers (which are at least initially the same as CNA containers), which I think is simple and a good idea for future-proofing.
On the topic of GCVE or EUVD or OSV or anyone becoming an ADP:
Procedurally ADP has been moving very slowly. Supplier ADP (SADP) is the very likely next step. There is general consensus to further enable and expand ADP.
āOther vul DBā ADP has been discussed, but IMO not seriously enough. The discussion doesnāt have to wait for SADP, but I suspect any testing or implementation will, simply due to resource constraints. This probably warrants separate discussions, maybe even one within and focused on GCVE. My concerns are at-scale data architecture, maintaining copies of data, or references, how is this all designed, does evertying really ābelongā within the CVE corpus (whether original data or copies of/references to data maintained elsewhere).
I expect weāll learn something about how to properly implement external references during the SADP pilot (and I donāt mean just URLs) and this will help inform other ADPs.
Iād also support/contribute to a proposal for a GCVE as ADP pilot, and this would require details.