adulau | 2025-08-21 07:12:47 UTC | #1 In [BCP-03](https://gcve.eu/bcp/gcve-bcp-03/), we only describe the protocol and not the format. Nevertheless, we recommend using the [CVE Record Format](https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json). During some tests with a new GNA, we discovered areas for improvement, and [insightful feedback about the format was provided](https://infosec.exchange/@todb/115063174817497818). We actually added the `vulnId` field in the CVE Record Format to support GNA publication with their own IDs, which addressed an issue raised by one of the GNAs. BCP-05 will clarify this point, as well as the specific part about namespace usage in the format. This is particularly relevant for the Vulnerability Lookup implementation, which uses namespaces to avoid field collisions in case the format evolves. There are still some open questions, such as: - Should BCP-05 allow other formats? - Should extensions or additional information (similar to ADP) be permitted for CVEs? - Since Vulnerability Lookup allows forking an existing CVE into a local instance, should a GNA explicitly indicate when a vulnerability has been forked? @cedric what do you think about this? especially the last open question. ------------------------- ClausHoumann | 2025-08-21 08:51:26 UTC | #2 Hi Alex As we just discussed, in my thinking the following ideas could be considered: 1. Writing explicitly that 1 vulnerability identifier can be assigned maximum to 1 vulnerability, but with GCVE you can of course create multiple different forks for any needs to express different instances of the vulnerability. 2. Writing that identified or CVD'd vulnerabilities that are accepted MUST be assigned a vulnerability identifier, silent patching is not ok 3. 3 potential public data points for a CVD process, all 3 optional and filled out by the researcher disclosing: (1: Date disclosed to company X for product Y or similar, 2: Date accepted as a vulnerability, 3: Date agreement on impact reached) ------------------------- adulau | 2025-08-22 07:32:47 UTC | #3 Thanks for the ideas. For (1), we can add this recommendation to BCP-04 but also to BCP-02 (or clarify it, as it was already mentioned). For (2), it is a requirement. We have already mentioned this in [BCP-02](https://gcve.eu/bcp/gcve-bcp-02/#investigating-and-resolving-vulnerabilities), but we may want to expand it further. Regarding the timeline, it is indeed a recommended best practice in [BCP-02](https://gcve.eu/bcp/gcve-bcp-02). However, for the data format, we rarely see this implemented. It might therefore make sense to define an extended field that could include additional information, in addition to the default CVEv5 format fields: `datePublished`, `dateReserved`, and `dateUpdated`. ------------------------- todb | 2025-08-30 20:35:56 UTC | #4 So with point (2): > Writing that identified or CVD’d vulnerabilities that are accepted MUST be assigned a vulnerability identifier, silent patching is not ok. First off, I love it. I care a lot about the [hidden harm silent patches](https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/). That said, this is a pretty hefty must, and also lacks a time bounding. Can I express this in a GCVE record with a future date? Any bounding there, or can I conditionIrelease on the appearance of the rise of the [God-Emporer of Mankind](https://wh40k.lexicanum.com/wiki/Emperor_of_Mankind)? So, I do like requiring disclosure. I don’t like breaking the spec just because I haven’t disclosed yet. It’s a common practice in many places use CVE IDs as internal numbers pre-disclosure, since it’s easier than switching to a new identifier when you disclose, and some places wait until disclosure to assign. I’d prefer the former to be encouraged, and suggest at minimum, requiring some specific date, (ISO-8601 formatted). This can encourage tooling to either auto-disclose, or notify when the imagined future date is passed. @adulau mentioned that (2) is already a requirement, pointing at BCP-02. Ctrl-F’ing for all the “musts” in there turns up 6, and they’re not capitalized MUSTs, so may not be intended as RFC 2119 keywords. Anyway, this is about a disclosure requirement. I have other thoughts. More coming soon! ------------------------- todb | 2025-08-30 20:32:06 UTC | #5 All right, general considerations on a spec. I will admit, I haven’t processed BCP-02 to a [point of understandingness](https://www.youtube.com/watch?v=TDPBRUZOykY), so I didn’t really consider it when I [whipped up a spec over here](https://github.com/hugesuccessllc/gcve/blob/main/aha-gcve-schema.json). 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. ------------------------- adulau | 2025-08-31 07:09:47 UTC | #6 Thanks a lot for the insightful details. I think I fully agree with you on most points. That’s why we didn’t want to pursue option (3) (as the process is long and painful even if we manage to do it for one specific format in the past decade), as creating a new format was never really our objective. Another important aspect is that we wanted to maintain compatibility with the current CNA process for CVE records. This is already the case in Vulnerability-Lookup, since we use Vulnogram to edit, fork, or publish vulnerabilities. This setup allows anyone with a CNA API ID to publish their vulnerabilities as a GNA, either to the CNA CVE Program or to alternative models that may emerge due to geopolitical or technical or organisational instability. Concerning BCP-03, we will update it to reflect that the format description will be moved to BCP-05. The current model, of course, is to adopt the standard [CVE format as described](https://github.com/CVEProject/cve-schema/blob/main/schema/CVE_Record_Format.json). The only issue is the extension, particularly for the minimal identifier required for GCVE and GNA. One option would be to include a GCVE-specific field, which could then be stripped out to remain fully compatible when publishing as a CNA (in the CVE Program), for example. My optimistic approach would be to request a custom field from the CVE Program and ask them to include it in the specification. Nevertheless, knowing how complex it can be with standards committees (I won’t name any here), we could instead adopt the approach of stripping the field whenever we need to produce fully compliant JSON files, even if requesting the addition of a new field from a committee might take years. - **(Action 1)** To summarise, my plan for the document (unless there is a major technical disagreement) is to update BCP-03 and release a new version specifying that we adhere to the CVE Record Format, with details and extensions described in BCP-05. - **(Action 2)** Agreement on the current extended field in the CVE Record Format. We may need to have a discussion about the different approaches, especially regarding the current implementation in Vulnerability-Lookup (@cedric, I’m looking at you ;-)) if we keep the current strategy (fields mentioned at the beginning of this thread) or update it with a single dictionary. - **(Action 3)** Open an issue on the CVE Record Format repository for the field(s) described in the BCP-05 draft to explore whether inclusion is possible. This action might take years, but it’s not blocking us ;-) ------------------------- adulau | 2025-08-31 10:24:58 UTC | #7 As an example, I have included a GCVE vulnerability in the CVE Record Format, with the extended field. This can serve as a basis for discussion. ```json { "containers": { "cna": { "affected": [ { "defaultStatus": "unaffected", "product": "cerebrate", "programFiles": [ "‎src/Controller/UserSettingsController.php" ], "repo": "https://github.com/cerebrate-project/cerebrate/", "vendor": "cerebrate", "versions": [ { "status": "affected", "version": "1.27" } ] } ], "credits": [ { "lang": "en", "type": "finder", "value": "Jeroen Pinoy" } ], "descriptions": [ { "lang": "en", "supportingMedia": [ { "base64": false, "type": "text/html", "value": "Incorrect ACL for user settings edit, which previously allowed enumeration of usernames." } ], "value": "Incorrect ACL for user settings edit, which previously allowed enumeration of usernames." } ], "impacts": [ { "capecId": "CAPEC-118", "descriptions": [ { "lang": "en", "value": "CAPEC-118 Collect and Analyze Information" } ] } ], "metrics": [ { "cvssV4_0": { "Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "NONE", "attackVector": "NETWORK", "baseScore": 9.3, "baseSeverity": "CRITICAL", "privilegesRequired": "HIGH", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "HIGH", "subConfidentialityImpact": "HIGH", "subIntegrityImpact": "HIGH", "userInteraction": "ACTIVE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H", "version": "4.0", "vulnAvailabilityImpact": "HIGH", "vulnConfidentialityImpact": "HIGH", "vulnIntegrityImpact": "HIGH", "vulnerabilityResponseEffort": "NOT_DEFINED" }, "format": "CVSS", "scenarios": [ { "lang": "en", "value": "GENERAL" } ] } ], "problemTypes": [ { "descriptions": [ { "cweId": "CWE-203", "description": "CWE-203 Observable Discrepancy", "lang": "en", "type": "CWE" } ] }, { "descriptions": [ { "cweId": "CWE-204", "description": "CWE-204 Observable Response Discrepancy", "lang": "en", "type": "CWE" } ] } ], "providerMetadata": { "orgId": "00000000-0000-4000-9000-000000000000" }, "references": [ { "tags": [ "patch" ], "url": "https://github.com/cerebrate-project/cerebrate/commit/04fb2cd4bb45566308930029f63096942f658b86" } ], "source": { "discovery": "INTERNAL" }, "x_generator": { "engine": "Vulnogram 0.2.0" } } }, "cveMetadata": { "assignerOrgId": "00000000-0000-4000-9000-000000000000", "datePublished": "2025-08-22T12:33:00.000Z", "dateUpdated": "2025-08-23T07:55:10.950332Z", "requesterUserId": "00000000-0000-4000-9000-000000000000", "serial": 1, "state": "PUBLISHED", "vulnId": "GCVE-1-2025-0003", "vulnerabilitylookup_history": [ [ "alexandre.dulaunoy@circl.lu", "2025-08-22T12:33:56.492006Z" ], [ "cedric.bonhomme@circl.lu", "2025-08-23T07:47:34.139577Z" ], [ "cedric.bonhomme@circl.lu", "2025-08-23T07:55:10.950332Z" ] ] }, "dataType": "CVE_RECORD", "dataVersion": "5.1" } ``` ------------------------- adulau | 2025-08-31 10:42:50 UTC | #8 First proposal for (Action 1): https://github.com/gcve-eu/gcve.eu/commit/cb8840217d48af7d9427ab8f2e611f281ddf3056 Updates/improvement welcome ------------------------- cedric | 2025-08-31 22:17:34 UTC | #9 For the moment in **cveMetadata** we have added: - `.cveMetadata.vulnId` , and - `.cveMetadata.vulnerabilitylookup_history` Also, for your information it is possible to get the following metadata fields via **Vulnerability-Lookup**: - ``vulnerability-lookup:meta`` → meta information related to the vuln from sources like *vulnrichment* or *NVD* - ``vulnerability-lookup:linked`` → correlations with vulnerabilities from various sources (GHSA, PySec, CSAF, etc.) - ``vulnerability-lookup:bundles`` → related bundles - ``vulnerability-lookup:comments`` → related comments - ``vulnerability-lookup:sightings`` → related sightings Contrary to `vulnId` and `vulnerabilitylookup_history`, these fields are not really part of the CVE data, they are added dynamically. These fields are tied to Vulnerability-Lookup, and GCVE should be software-agnostic. So I do not think we should touch this. **Just an example:** ```bash $ curl --silent 'https://vulnerability.circl.lu/api/vulnerability/CVE-2025-2842?with_meta=false&with_linked=false&with_comments=true&with_bundles=true&with_sightings=true' \ -H 'accept: application/json' \ | jq '.["vulnerability-lookup:sightings"]' [ { "uuid": "81e07178-6279-4a63-b4ec-ef6b33d8227f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-2842", "type": "seen", "source": "https://bsky.app/profile/cve.skyfleet.blue/post/3lltgrtfeee2i", "creation_timestamp": "2025-04-02T12:56:47.602210Z" } ] ``` Now back to our main problem, putting `vulnId` in `cveMetadata` was a pragmatic choice at a precise moment, and the goal was to not touch the existing `cveId` field. With minor changes to the JSON schema of CVE v5. I still like this idea... But now I am thinking that we could as well have the field in: `.gcveMetadata.vulnId`. So we should maybe push to have our own **gcveMetadata** container where we can have `vulnId`. For example in this container we could also have: * a flag to indicate if the GCVE is a fork of a CVE or not * our own dates (`published`, `updated`, `reserved`). Dates from `cveMetadata` will remain the default. We only specify dates in .gcveMetadata if needed * state * ... This is just an example, but it would give us a structured way to extend GCVE without *polluting* the CVE metadata. GCVE could have it's own metadata ! About fork, actually if in the JSON there is a 'vulnId' and a 'cveId' the corresponding GCVE should logically be a fork. ------------------------- adulau | 2025-09-01 08:15:32 UTC | #10 Thanks, this sounds like a plan. Should we go ahead and create a `gcveMetadata` container in Vulnerability-Lookup to see how the implementation could work? Then we could share this implementation description with the CVE Program. ------------------------- cedric | 2025-09-01 19:52:43 UTC | #11 If you think it's a good idea, yes let's go for it. I'll see what must be updated in Vulnerability-Lookup (the bundled vulnogram web interface and the JSON schema for CVE v5). ------------------------- adulau | 2025-09-02 07:13:36 UTC | #12 I asked about the process of having a new container in the CVE Record format. https://github.com/CVEProject/cvelistV5/issues/110 ------------------------- adulau | 2025-09-17 04:33:53 UTC | #13 Some feedback concerning the request for the container format: we had a meeting with the CVE Program team. A specific approach was discussed that could be used to facilitate references to GCVE or other IDs in the CVE format (especially when pushed through the CNA publication process). It could also be applied to reference the actual publication from a GNA. The proposal is to introduce a new relationship format to describe the link between a given CVE and other publication systems (such as CSAF, GCVE, or custom ones). Following the discussion, [some notes](https://github.com/CVEProject/cve-schema/issues/451#issuecomment-3285648683) were added to the issue. So a potential format idea, could be the following with an array of relationships: ```json "relationships": [ { "source": "GCVE-65535-2025-000123", // the source (for example this GCVE) "relationship-type": "is-equivalent-to", // verb "target": "CVE-2025-12345" // destination to the related reference } ] ``` Some ideas of [relationships type are available in the MISP standard object format](https://www.misp-project.org/objects.html#_relationships). ------------------------- claudex | 2025-09-18 08:56:38 UTC | #14 I think the version should be referenced in the format reference instead of the main branch, this avoid confusion when it’s updated in the future. So using something like: https://github.com/CVEProject/cve-schema/blob/v5.2.0/schema/CVE_Record_Format.json I can make a PR if this seem ok for you. ------------------------- adulau | 2025-09-29 20:19:50 UTC | #15 As a reminder, we have a taxonomy for vulnerabilities, and we need to find a way to attach tags to CVE records: https://www.misp-project.org/taxonomies.html#_vulnerability_4 Should we have a dedicated field (an array) to attach these tags? # Vulnerability Taxonomy | Namespace / Predicate | Value | Description | |------------------------|--------|-------------| | **vulnerability** | - | Vulnerability namespace available in JSON format at this location. The JSON format can be freely reused in your application or automatically enabled in MISP taxonomy.
A taxonomy for describing vulnerabilities (software, hardware, or social) on different scales or with additional available information. | | **sighting** | - | Sighting information related to the vulnerability. | | vulnerability:sighting="seen" | Seen | The vulnerability was mentioned, discussed, or seen somewhere by the user. | | vulnerability:sighting="confirmed" | Confirmed | The vulnerability is confirmed from an analyst perspective. | | vulnerability:sighting="exploited" | Exploited | This vulnerability was exploited and seen by the user reporting the sighting. | | vulnerability:sighting="patched" | Patched | This vulnerability was successfully patched by the user reporting the sighting. | | vulnerability:sighting="not-exploited" | Not exploited | This vulnerability was not exploited or seen by the user reporting the sighting. | | vulnerability:sighting="not-confirmed" | Not confirmed | The user expresses doubt about the veracity of the vulnerability. | | vulnerability:sighting="not-patched" | Not patched | This vulnerability was not successfully patched by the user reporting the sighting. | | **exploitability** | - | Quantification of attack exploitability, providing a level of exploitation for the identified vulnerability.
**Exclusive flag set** – values below must be set exclusively. | | vulnerability:exploitability="industrialised" | Industrialised | Existing vulnerability with detailed attack methods; multiple tools are available for exploitation. | | vulnerability:exploitability="customised" | Customised | Existing vulnerability with a detailed attack approach and one known custom tool available for exploitation. | | vulnerability:exploitability="documented" | Documented | Existing vulnerability is documented with an attack approach, but tools for exploitation are not available. | | vulnerability:exploitability="theoretical" | Theoretical | Publication describes a theoretical vulnerability but no actual exploitation is reported. | | **information** | - | Complementary information related to the vulnerability. | | vulnerability:information="PoC" | Proof-of-Concept | Reference to a proof-of-concept for exploiting the vulnerability. | | vulnerability:information="remediation" | Remediation | Remediation to limit or block the exploitability of the vulnerability. | | vulnerability:information="annotation" | Annotation | Annotation or clarification to a vulnerability. | | **origin** | - | Origin of the vulnerability. | | vulnerability:origin="hardware" | Hardware | The origin of the vulnerability is hardware related. | | vulnerability:origin="software" | Software | The origin of the vulnerability is software related. | | vulnerability:origin="service" | Service | The origin of the vulnerability is service related. | | vulnerability:origin="procedural-implementation" | Procedural implementation | The vulnerability originates from procedural implementation issues, such as misconfigurations or insecure configuration defaults introduced post-deployment, rather than being inherent to the original software or hardware distribution. | ------------------------- adulau | 2025-10-02 05:41:59 UTC | #16 I'm drafting **BCP-05**, and my idea is to define an `x_gcve` dictionary where we place all GCVE-specific fields. As mentioned by Art Manion , the `x_` prefix is fully acceptable, especially if others later decide to adopt or align with it. For now, I plan to add only the `relationship` dictionary, and then we can submit our proposal to the CVE Program, updating it later if they want to integrate changes. The open question is how to handle the existing fields. Should we rename the current `vulnerability-lookup` dictionary to `x_vulnerability-lookup` and add a new `x_gcve` dictionary for all GCVE-related elements? The concern is that this might break compatibility with existing tools (e.g., ENISA). On the other hand, would it be better to make this change now rather than later? ------------------------- adulau | 2025-10-02 06:07:08 UTC | #17 First early draft of BCP-05 is available https://gcve.eu/bcp/gcve-bcp-05/ including a potential list of relationships - **`is-equivalent-to`** — The identifier corresponds directly to another identifier. - **`supersedes`** — The identifier replaces or updates a previous one. - **`is-superseded-by`** — The identifier has been replaced or updated by another. - **`duplicates`** — The identifier is a duplicate of another. - **`is-duplicated-by`** — Another identifier is a duplicate of this one. - **`refers-to`** — The identifier references related material without strict equivalence. - **`is-related-to`** — A weak or general relationship where the exact nature is undefined but relevance is established. - **`is-parent-of`** — The identifier describes a broader vulnerability or set that includes the target. - **`is-child-of`** — The identifier is a subset or more specific case of the target. - **`has-same-root-cause-as`** — The identifier shares the same root cause with another. - **`is-variant-of`** — The identifier represents a variant or closely related issue of another. - **`has-variant`** — The identifier has one or more related variants described elsewhere. - **`is-successor-to`** — The identifier is the successor in a chain of identifiers. - **`is-predecessor-of`** — The identifier is the predecessor in a chain of identifiers. - **`is-alias-of`** — The identifier is known under another name/namespace. - **`has-alias`** — The identifier has one or more alternate names/namespaces. ------------------------- cedric | 2025-10-02 07:10:14 UTC | #18 Yes, I think it's best to break everything now. The sooner, the better! ------------------------- claudex | 2025-10-02 07:47:37 UTC | #19 I’m not a fan of long identifies name in interoperable format. It’s prone to typo in implementations which can cause frustrating debugging session in other implementations. For example, `supersedes` can be easily written `superseeds`as a lot of people do https://en.wiktionary.org/wiki/superseed Also, there is the fact that they can be implementation variation, like framework which will automatically convert uppercase to lowercase until they don’t (since it’s not in json key, there will be more creativity in handling the value. So I’m in favor of having think like `is-equivalent-to` replaced by `==` for example. On the other hand, this will not cover all the case (or with very hard to read symbol), so it won’t be perfect either. ------------------------- adulau | 2025-10-02 10:25:02 UTC | #20 If you find alternative/synonyms names/verbs with less confusion, feel free to update the current draft in GitHub. Using algebra symbols is another way but it's difficult to describe all the potential ambiguity of ID allocation ;-) I actually followed what is currently used in other format such as MISP Standard or OASIS STIX 2.x. ------------------------- zmanion | 2025-10-02 15:01:11 UTC | #21 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. https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/blob/abfb1b62757359d8bddc0ed948e549ec0ef80f89/vxref/schema/vxref_schema_03.json#L52-L59 ------------------------- adulau | 2025-10-09 08:53:44 UTC | #22 @cedric I will adjust with the relationship with VRDX as proposed by @zmanion Any objection? ------------------------- cedric | 2025-10-11 06:42:27 UTC | #23 [quote="zmanion, post:21, topic:121"] https://github.com/FIRSTdotorg/vrdx-sig-vxref-wip/blob/abfb1b62757359d8bddc0ed948e549ec0ef80f89/vxref/schema/vxref_schema_03.json#L52-L59 [/quote] of course not, seems really relevant! ------------------------- adulau | 2025-11-02 11:50:46 UTC | #24 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. ------------------------- adulau | 2025-11-06 10:16:40 UTC | #25 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. ------------------------- cedric | 2025-11-06 10:21:43 UTC | #26 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. ------------------------- adulau | 2025-11-06 10:34:11 UTC | #27 New draft published for BCP-05 based on the last feedback: https://gcve.eu/bcp/gcve-bcp-05/ Feel free to comment ------------------------- zmanion | 2025-11-06 18:50:45 UTC | #28 And (effectively, not literally) `src_id` is `cveMetadata.vulnId` right? ------------------------- adulau | 2025-11-07 05:58:55 UTC | #29 Yes, it is. Maybe we should be more explicit about the source in the BCP document. ------------------------- adulau | 2025-11-08 15:22:46 UTC | #30 Document updated following the meeting at Brest (Unlock your Brain conference), https://github.com/gcve-eu/gcve.eu/commit/d2a824cc240f2b8938479aec62522028986abc86 ------------------------- adulau | 2025-11-11 06:49:03 UTC | #31 BCP-05 https://gcve.eu/bcp/gcve-bcp-05/ has been published and now the status is DRAFT for public review. ------------------------- jgamblin | 2025-11-19 17:08:00 UTC | #32 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 ------------------------- adulau | 2025-11-20 07:35:00 UTC | #33 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. : https://github.com/CVEProject/cve-schema/issues/451#issuecomment-3554323550 ------------------------- jgamblin | 2025-11-20 13:23:13 UTC | #34 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. ------------------------- cedric | 2025-11-21 10:00:03 UTC | #35 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: - A new ID that will be used by the GNAs. Currently "cveId" can only hosts ids for the CVE format. - A way to describe relationships with other vulnerabilities. And from various sources. 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_related` - `related` - `not equal` - `equal` - `superset` - `subset` - `overlap` An 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: ```json { "containers": { }, "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". ------------------------- adulau | 2025-11-24 09:10:54 UTC | #36 I suppose you mean in your example `equal` as it's the same document. ~~~ { "containers": { }, "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`](https://github.com/CVEProject/cve-schema/blob/main/schema/tags/reference-tags.json) 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. ------------------------- adulau | 2025-11-24 09:53:54 UTC | #37 The BCP-05 has been published including feedback from @jgamblin and @cedric. https://gcve.eu/bcp/gcve-bcp-05/ Now the GCVE metadata JSON is floating and can be attached to any format or ADP if GCVE become one at some point. ------------------------- claudex | 2025-11-27 09:50:26 UTC | #38 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 GCVE Both cases are not vulnerabilities, but I think they are valuable information that are interesting to have in the GCVE ecosystem. ------------------------- adulau | 2025-11-29 11:15:22 UTC | #39 Thanks a lot for the feedback. It's now updated https://github.com/gcve-eu/gcve.eu/commit/023aecda52e64c772084d44baf00509435a6aed0 if you see anything missing let us know. ------------------------- zmanion | 2025-11-29 19:02:26 UTC | #40 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: 1. 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. 2. “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. ------------------------- claudex | 2025-12-04 17:49:16 UTC | #41 Il was wondering if the usage of the verbs which are not security vulnerability means that there should be a property in the gcve to indicate that it's not a vulnerability but a comment/announcement/… another use case I see for this tag is announcing the end of support for a product for example. ------------------------- adulau | 2025-12-06 16:01:08 UTC | #42 Thanks @claudex . This is an excellent point and would also improve the ability to parse GCVE records reliably. Below is a proposal for a `record_type` field that would serve as a key within each GCVE record. Feel free to comment. @cedric I incorporated the idea concerning the sync of the comment (not sure if the most efficient way). ## Proposed update to BCP-05 (following the online workshop of 6th December in Belgium) The `record_type` field defines the semantic category of the content submitted by a GNA through the synchronization endpoint. It enables producers and consumers of GCVE data to distinguish between different kinds of records associated with a GCVE identifier (e.g., the primary security advisory, supplemental information, or community-provided additions). A value **MUST** be provided for every record. In case of parsing failure, the `record_type` `advisory` **MUST** be assumed. GNAs **SHOULD** use the most specific `record_type` available. Consumers **SHALL** ignore unknown types and treat them as opaque extension values to ensure forward compatibility. ### Recommended `record_type` Values ## `advisory` The authoritative security advisory or vulnerability description produced by the GNA. Contains core details such as impact, affected products, references, and remediation. This type **MAY** include a `relationships` table. ## `update` Follow-up information that updates or extends parts of the original advisory which is mentioned in the `relationships` table. (e.g., additional affected versions, revised severity, new patches). This type **MUST** include a `relationships` table. ## `analysis` Technical analysis, exploitation insights, detection notes, or other analytical content that complements another advisory. May be authored by the GNA or trusted partners working with the GNA. This type **MUST** include a `relationships` table. ## `metadata` Structured or machine-generated supplemental information (e.g., tags, product mappings, enrichment fields). Not intended to modify the original advisory text referenced in the `relationships` table. This type **MUST** include a `relationships` table. ## `reference` Pointers to external documents, vendor bulletins, technical writeups, repositories, or other relevant resources. Not intended to modify the original advisory text referenced in the `relationships` table. This type **MUST** include a `relationships` table. ## `comment` Non-authoritative free-text remarks or annotations. May come from the community or other contributors managed by a GNA. This type **MUST** include a `relationships` table. ## `statement` Official statements from stakeholders (e.g. an operating system distribution, an open source co-author) or vendors (e.g., “not affected,” “end-of-life,” “mitigation available”). This type **MUST** include a `relationships` table. ## `remediation` Standalone information on patches, mitigations, workarounds, or configuration guidance when provided separately from the advisory and published by the GNA issuing that GCVE record. This type **MUST** include a `relationships` table. ## `deprecation` Marks an advisory as superseded, withdrawn, or otherwise deprecated (e.g., merged into another GCVE ID or determined non-vulnerable). This type **MUST** include a `relationships` table. ## `detection` Detection guidance such as YARA, Snort, or Sigma rules. This type **MUST** include a `relationships` table. ## `translation` Non-authoritative translations of an advisory with an additional GCVE `language` field specifying the language of the GCVE record. This type **MUST** include a `relationships` table. # Sample JSON ```json "x_gcve": [ { "vulnId": "GCVE-1-2025-0018", "record_type": "advisory" "relationships": [ { "destId": "CVE-2025-65095", "type": "equal" } ] } ], ``` ------------------------- adulau | 2025-12-10 05:18:34 UTC | #43 BCP-05 has been updated including the `recordType` field and updated following the similar structure used for the other description of the fields. https://gcve.eu/bcp/gcve-bcp-05/#recordtype-field https://gcve.eu/files/bcp/gcve-bcp-05.pdf Feel free to comment. ------------------------- adulau | 2025-12-20 06:59:46 UTC | #44 New release of vulnerability-lookup includes a implementation of the GCVE BCP-05 including relationships: https://github.com/vulnerability-lookup/vulnerability-lookup/releases/tag/v2.20.0 If the tests conclude successfully and the final 2025 workshop takes place in Luxembourg, BCP-05 will be published in its first non-draft version. It can, however, be safely revised in later versions. ------------------------- adulau | 2026-01-02 13:17:17 UTC | #45 Following the missing references to `Bundle`, we added a new `recordType`: https://github.com/gcve-eu/gcve.eu/commit/bdfb3ec4b86e1c066a81dece37882ff8a4b90fa9 @cedric if you see something missing, freel free. -------------------------