GCVE-BCP-11 - Community-Proposed Updates to Existing CVE Records
- Version: 1.0
- Status: Draft (for Public Review)
- Date: 2026-07-13
- Authors: GCVE Working Group
- BCP ID: BCP-11
This guide is distributed and available under CC-BY-4.0.
Copyright (C) 2026 GCVE Initiative.
Abstract
This Best Current Practice defines a mechanism for publishing collaborative proposals to correct, enrich, or extend existing CVE records.
A reserved GCVE Numbering Authority, GNA 65530, is dedicated exclusively to producing community-maintained update records associated with existing CVE identifiers. These records are intended to consolidate technically supported proposals that have not yet been incorporated into the authoritative CVE record.
Typical proposals include corrections to affected-product information, additional references, improved descriptions, Common Platform Enumeration (CPE) or Package URL (PURL) mappings, severity assessments, remediation information, and other structured extensions.
Records published by GNA 65530 MUST follow the GCVE container format defined in GCVE-BCP-05. They MAY use additional x_ extensions where information cannot be represented in the standard CVE Record Format or the core GCVE container.
The mechanism does not replace, override, or modify the authoritative CVE record. It provides an additional, openly available feed that CVE Numbering Authorities, vendors, researchers, vulnerability databases, and other consumers can use to identify and potentially integrate community-proposed improvements.
Introduction
Vulnerability information frequently evolves after the initial publication of a CVE record. Researchers, software distributors, downstream vendors, users, and vulnerability intelligence providers may subsequently identify:
- additional affected or unaffected versions;
- incorrect or incomplete product mappings;
- missing CPE or PURL identifiers;
- incomplete technical descriptions;
- new references, patches, or remediation information;
- corrections to severity or weakness classifications;
- ecosystem-specific information;
- machine-readable extensions that cannot be represented in the original record.
Ideally, such information is submitted to the responsible CVE Numbering Authority (CNA) and incorporated into the authoritative CVE record.
In practice, an originating CNA may be unavailable, no longer operational, unable to process community contributions, or unwilling to incorporate a proposed update. A CNA may also lack the tooling or resources required to collect and evaluate contributions from multiple independent communities.
As a result, relevant vulnerability information can remain fragmented across issue trackers, vendor advisories, distribution notices, security research, vulnerability databases, and informal discussions.
This BCP establishes a dedicated publication mechanism through GNA 65530 to consolidate these proposals into structured, reviewable, and machine-readable records.
Scope
GNA 65530 is reserved exclusively for records that propose updates to an existing CVE record.
Every record published by GNA 65530:
- MUST reference exactly one existing CVE identifier as its primary target;
- MUST represent a proposed correction, enrichment, extension, or consolidation of information related to that CVE;
- MUST use the GCVE container format defined in GCVE-BCP-05;
- MUST use the
updaterecord type; - MUST contain sufficient provenance to identify the sources supporting the proposed changes;
- MUST remain distinguishable from the authoritative CVE record.
GNA 65530 MUST NOT:
- allocate a new CVE identifier;
- publish a record for a vulnerability that has no existing CVE identifier;
- claim ownership of the referenced CVE;
- present its record as an authoritative replacement for the originating CNA record;
- modify or redistribute an existing CVE record without identifying the proposed changes and their provenance;
- publish unrelated advisories, analyses, or vulnerability records outside this defined purpose.
Where no CVE identifier exists, a normal GNA SHOULD allocate a regular GCVE identifier according to GCVE-BCP-04 instead of using GNA 65530.
Purpose of Reserved GNA 65530
The purpose of GNA 65530 is to maintain a collaborative update layer for CVE records.
This update layer has four primary objectives:
- Consolidation: Gather technically supported proposals from multiple communities into a single structured record associated with the relevant CVE.
- Preservation: Ensure that proposed corrections and enrichments remain publicly accessible even when they are not incorporated into the authoritative CVE record.
- Interoperability: Make the proposals available in a machine-readable format compatible with existing CVE and GCVE tooling.
- Upstream reuse: Enable the responsible CNA or another authorized CVE Program participant to review and automatically integrate accepted information into the authoritative CVE record.
GNA 65530 acts as a collaborative staging and publication mechanism. It is not an alternative CNA and does not supersede decisions made by the CVE Program or the CNA responsible for the original record.
Identifier Allocation
A GNA 65530 record MUST have its own GCVE identifier.
For a target CVE identifier using the format:
CVE-<YEAR>-<SEQUENCE>
the corresponding GNA 65530 identifier SHOULD use:
GCVE-65530-<YEAR>-<SEQUENCE>
For example:
CVE-2026-12345
would normally be associated with:
GCVE-65530-2026-12345
This deterministic mapping provides a simple one-to-one relationship between the original CVE and its community update record.
The GNA 65530 identifier:
- identifies the collaborative update record;
- MUST NOT be interpreted as a newly allocated vulnerability;
- MUST NOT be used as a replacement for the CVE identifier;
- SHOULD remain stable across subsequent revisions of the collaborative record.
Only one canonical GNA 65530 update record SHOULD exist for each CVE identifier. New accepted proposals SHOULD update the existing record instead of creating additional GNA 65530 identifiers for the same CVE.
Record Format
All GNA 65530 records MUST follow GCVE-BCP-05.
The GCVE container MUST include:
vulnId, containing the GNA 65530 identifier;recordType, set toupdate;relationships, containing a relationship to the target CVE.
The relationship to the target CVE SHOULD use the equal relationship type because the GNA 65530 record concerns the same underlying vulnerability while proposing updated or extended information.
Example:
{
"x_gcve": [
{
"vulnId": "GCVE-65530-2026-12345",
"recordType": "update",
"relationships": [
{
"destId": "CVE-2026-12345",
"type": "equal"
}
]
}
]
}
The complete published document SHOULD contain a consumable representation of the proposed updated CVE record rather than only an unstructured description of the changes.
Information that can be represented using standard CVE Record Format fields SHOULD use those fields. Information that cannot be represented in the standard format MAY be included through GCVE or x_ extensions.
Community Update Extension
A GNA 65530 record MAY contain an x_gcve_community_update extension to describe the update process, provenance, review status, and relationship with the authoritative CVE record.
An example structure is:
{
"x_gcve": [
{
"vulnId": "GCVE-65530-2026-12345",
"recordType": "update",
"relationships": [
{
"destId": "CVE-2026-12345",
"type": "equal"
}
],
"x_gcve_community_update": {
"targetId": "CVE-2026-12345",
"status": "active",
"baseRecordDateUpdated": "2026-05-12T09:30:00Z",
"contributors": [
{
"name": "Example Security Community",
"reference": "https://example.invalid/proposal/12345"
}
],
"changes": [
{
"path": "containers.cna.affected",
"action": "add",
"summary": "Add the affected package and corrected version range.",
"references": [
"https://example.invalid/advisory/12345"
]
},
{
"path": "containers.cna.descriptions",
"action": "replace",
"summary": "Clarify the vulnerability preconditions and impact.",
"references": [
"https://example.invalid/research/12345"
]
}
],
"review": {
"status": "reviewed",
"reviewedAt": "2026-07-13T12:00:00Z"
},
"upstream": {
"submissionStatus": "submitted",
"submittedAt": "2026-07-10T08:00:00Z"
}
}
}
]
}
The extension is OPTIONAL, but implementations are encouraged to provide equivalent provenance and review information.
targetId
The targetId field identifies the CVE record to which the proposed update applies.
It MUST be identical to the CVE identifier referenced in the relationships field.
status
The status field describes the lifecycle state of the collaborative record.
Recommended values are:
draft— proposals are being collected and have not yet completed review;active— the record contains reviewed proposals that have not been fully integrated upstream;submitted— the proposals have been submitted to the responsible CNA or another authorized CVE Program participant;partially_integrated— some, but not all, proposed changes have been incorporated into the authoritative CVE record;integrated— all relevant proposed changes have been incorporated into the authoritative CVE record;superseded— the collaborative record has been replaced by a newer mechanism or record;disputed— one or more material proposals remain subject to unresolved technical disagreement;withdrawn— the proposals were found to be incorrect, unsupported, or no longer applicable.
baseRecordDateUpdated
The optional baseRecordDateUpdated field identifies the version of the authoritative CVE record used as the basis for the collaborative update.
This field SHOULD contain the dateUpdated value from the source CVE record when available.
Consumers can use this value to detect whether the authoritative record has changed since the collaborative proposal was prepared.
contributors
The contributors array identifies individuals, organizations, projects, vendors, distributions, or communities that supplied information included in the proposed update.
Contributors SHOULD be credited when they consent to attribution.
Each contribution SHOULD include a public reference or another verifiable source whenever possible.
Anonymous contributions MAY be accepted, but the GNA 65530 maintainers MUST independently validate the associated claims before publication.
changes
The changes array describes material differences between the authoritative CVE record and the collaborative update.
Each change SHOULD include:
- the field or logical area affected;
- the type of action proposed;
- a concise explanation;
- supporting references or evidence.
Recommended action values are:
add;replace;remove;correct;extend;deprecate.
A machine-readable JSON Patch or another standardized difference format MAY also be included as an extension.
review
The review object describes the validation performed before publication.
A published active record SHOULD have received human review.
The review process SHOULD verify that:
- the target CVE exists;
- the proposal concerns the same underlying vulnerability;
- the supporting references are accessible and relevant;
- affected-product claims are technically supported;
- proposed identifiers correspond to the correct products or packages;
- the proposal does not introduce confidential or embargoed information;
- community disagreements are represented accurately.
upstream
The optional upstream object records interactions with the responsible CNA or other CVE Program participants.
It MAY include:
- whether the proposal has been submitted;
- when it was submitted;
- the submission channel;
- the response status;
- references to public discussions or issue trackers;
- whether the proposal was accepted, partially accepted, rejected, or left unanswered.
Sensitive correspondence or personal contact information MUST NOT be published without authorization.
Types of Proposed Updates
GNA 65530 records MAY include proposals concerning any technically relevant part of an existing CVE record.
Examples include:
Product and Version Information
Proposals may correct or extend:
- vendor names;
- product names;
- package names;
- affected versions;
- unaffected versions;
- fixed versions;
- version constraints;
- platform-specific conditions;
- downstream distribution information.
CPE and Package Identifiers
Proposals may add or correct:
- CPE identifiers;
- PURL identifiers;
- software package coordinates;
- repository identifiers;
- relationships between upstream projects and downstream packages.
Where an identifier cannot be incorporated into the standard CVE Record Format, it MAY be represented using an appropriate GCVE extension.
CPE-related proposals SHOULD follow the recommendations in GCVE-BCP-10.
Description and Technical Details
Proposals may improve:
- vulnerability descriptions;
- attack preconditions;
- impact statements;
- affected components;
- root-cause information;
- authentication or privilege requirements;
- distinctions between separate vulnerabilities.
The proposed description SHOULD remain factual and SHOULD distinguish verified information from assumptions or unresolved analysis.
Severity and Classification
Proposals may include:
- CVSS vectors and scores;
- CWE classifications;
- CAPEC references;
- ecosystem-specific severity ratings;
- exploitation prerequisites;
- prioritization information.
The source and version of each scoring or classification system SHOULD be identified.
Conflicting severity assessments MAY coexist when their sources and scoring assumptions are clearly documented.
References and Remediation
Proposals may add:
- vendor advisories;
- patches or commits;
- distribution advisories;
- technical analyses;
- proof-of-concept references;
- mitigations;
- workarounds;
- upgrade instructions;
- detection guidance.
References MUST be relevant to the target vulnerability and SHOULD use stable, publicly accessible locations.
Extensions
GNA 65530 records MAY include extensions that are not currently accepted or supported by the CVE Program.
Examples include:
- enhanced CPE or PURL relationships;
- AI-assisted annotations;
- structured provenance;
- community review metadata;
- detection artifacts;
- ecosystem-specific package information;
- richer vulnerability relationships;
- alternative severity or prioritization systems.
Extensions MUST follow the namespace recommendations in GCVE-BCP-05.
Contribution and Review Process
Community proposals SHOULD be accepted through an open and documented contribution mechanism.
A contribution process SHOULD support:
- submission of a proposed change;
- identification of the target CVE;
- submission of supporting evidence;
- discussion and technical review;
- resolution of duplicates or conflicting proposals;
- publication of accepted changes;
- preservation of the contribution history;
- submission of the consolidated proposal to the responsible CNA where possible.
A proposal MUST NOT be accepted solely because it has broad community support. Technical claims MUST be supported by verifiable evidence.
The review process SHOULD include subject-matter experts when proposals involve complex version ranges, package ecosystems, hardware products, protocol behavior, or other specialized domains.
Consolidation of Multiple Proposals
Multiple communities may independently propose updates to the same CVE.
GNA 65530 SHOULD consolidate compatible proposals into a single canonical record.
The consolidated record SHOULD:
- preserve attribution for each accepted contribution;
- remove duplicate information;
- identify conflicts between sources;
- avoid presenting unresolved claims as established facts;
- retain a history of material revisions;
- indicate which proposals have completed review.
When two proposals conflict, maintainers SHOULD attempt to resolve the disagreement using available technical evidence.
If no resolution is possible, the record MAY:
- document both positions;
- mark the relevant section as disputed;
- include the evidence supporting each position;
- avoid automatically replacing the corresponding authoritative CVE field.
Relationship with the Responsible CNA
The responsible CNA remains the authoritative party for the CVE record within the CVE Program.
Whenever practical, accepted GNA 65530 proposals SHOULD be submitted to the responsible CNA.
A CNA MAY consume the GNA 65530 feed to:
- identify pending community corrections;
- import additional references;
- update affected-product information;
- retrieve CPE or package mappings;
- review consolidated community evidence;
- automatically prepare an upstream CVE update.
The feed SHOULD be designed so that a CNA can compare:
- the current authoritative CVE record;
- the CVE version used as the basis of the proposal;
- the complete proposed record;
- the individual proposed changes;
- the supporting references;
- the review status.
When the CNA updates the authoritative CVE record, GNA 65530 maintainers SHOULD compare the upstream change with the collaborative proposal.
The GNA 65530 record SHOULD then be marked as:
integrated, when the relevant proposals have been incorporated;partially_integrated, when only some proposals have been incorporated;active, when material proposals remain outstanding;superseded, when the upstream record makes the collaborative record obsolete.
An integrated record SHOULD remain available for historical reference and attribution.
Orphaned and Unmaintained CVE Records
A CVE record may be considered operationally orphaned when:
- the originating CNA no longer exists;
- the originating CNA has left the CVE Program;
- the affected vendor or project is no longer maintained;
- no responsible party can be contacted;
- repeated technically supported update requests remain unanswered;
- responsibility for updating the record is unclear.
GNA 65530 provides a persistent location for improvements to such records.
The designation of a record as orphaned is operational and does not transfer ownership of the CVE identifier to GNA 65530.
Where another CNA or CVE Program participant assumes responsibility for the record, the GNA 65530 proposals SHOULD be made available to that organization for potential integration.
Publication and Distribution
GNA 65530 records MUST be published using the decentralized publication mechanisms described in GCVE-BCP-03.
The publication service SHOULD provide:
- a machine-readable API;
- a complete static dump;
- incremental updates;
- stable identifiers;
- revision timestamps;
- provenance information;
- an open redistribution licence;
- sufficient history to audit material changes.
Consumers SHOULD be able to query GNA 65530 records by their target CVE identifier.
A dedicated feed containing only active or unresolved community proposals MAY also be provided.
Consumer Guidance
Consumers MUST treat GNA 65530 records as community-proposed updates and not as authoritative replacements for CVE records.
Applications presenting information from GNA 65530 SHOULD clearly distinguish:
- information originating from the authoritative CVE record;
- information proposed by the community;
- information reviewed by GNA 65530 maintainers;
- information integrated by the responsible CNA;
- disputed or unverified proposals.
Automated systems MAY merge selected GNA 65530 information with CVE data, but SHOULD retain field-level provenance.
Security scanners and vulnerability management tools SHOULD avoid silently replacing authoritative affected-product information with a community proposal unless their policy explicitly permits this behavior.
Security, Trust, and Abuse Considerations
A collaborative update mechanism can be targeted by inaccurate, misleading, or malicious submissions.
GNA 65530 maintainers SHOULD implement controls to mitigate:
- false affected-product claims;
- malicious CPE or package mappings;
- reference spam;
- manipulated severity scores;
- attempts to associate unrelated vulnerabilities;
- removal of valid affected versions;
- unsupported claims of exploitation;
- impersonation of vendors or researchers;
- disclosure of confidential vulnerability information;
- coordinated attempts to influence automated vulnerability-management systems.
Material proposals SHOULD receive human review before being marked active.
Every accepted proposal SHOULD retain sufficient provenance to permit independent verification.
Corrections and withdrawals MUST remain visible in the revision history.
The publication mechanism SHOULD support cryptographic integrity protection and authenticated submissions.
Licensing
GNA 65530 records SHOULD be distributed under an open licence that permits reuse, modification, and redistribution.
CC0 is recommended for machine-readable vulnerability data where possible. CC-BY-4.0 MAY be used where attribution is required.
References and externally contributed content remain subject to their respective licences.
Summary of Requirements
A conforming GNA 65530 implementation:
- MUST publish only proposed updates to existing CVE records;
- MUST assign a stable
GCVE-65530-*identifier to each collaborative record; - MUST use the GCVE-BCP-05 format;
- MUST use
recordTypeset toupdate; - MUST reference the target CVE through
relationships; - MUST preserve provenance for material proposed changes;
- MUST distinguish its records from authoritative CVE records;
- MUST NOT allocate new CVE identifiers;
- MUST NOT claim to replace the responsible CNA;
- SHOULD maintain one canonical collaborative record per CVE;
- SHOULD consolidate compatible community proposals;
- SHOULD submit reviewed proposals to the responsible CNA;
- SHOULD track whether proposals were integrated upstream;
- SHOULD preserve integrated and superseded records for historical reference;
- MAY use GCVE extensions for information that cannot be represented in the standard CVE Record Format.