GCVE-BCP-11 - Community-Proposed Updates to Existing CVE Records

adulau · July 30, 2026, 5:44am

GCVE-BCP-11 — Community Contribution Fragments for Existing CVE Records

Version: 1.1
Status: Draft (for Public Review)
Date: 2026-07-30
Authors: GCVE Working Group
BCP ID: BCP-11

This guide is distributed and available under CC-BY-4.0.

Abstract

This Best Current Practice defines a mechanism for publishing community-proposed corrections, enrichments, and extensions to existing CVE records.

GNA 65530 is reserved for these contributions. Each target CVE is associated with one deterministic GCVE-65530-* umbrella identifier. Individual proposals are published as separately identifiable JSON contribution fragments rather than being merged directly into one continuously rewritten record.

Each contribution fragment contains the proposed structured information, provenance, evidence, review status, and optional upstream-submission information. The technical content of a published contribution is immutable. A correction is published as a new contribution that supersedes the previous one. Conflicting contributions may coexist.

A complete merged CVE representation is not normative. Implementations MAY generate a resolved community view that combines the current authoritative CVE record with selected reviewed contributions under an explicit policy.

The design separates contribution storage from record reconciliation, keeping the core implementation small, auditable, and decentralized.

Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Introduction

Vulnerability information frequently evolves after a CVE record is published. Researchers, vendors, software distributions, open-source projects, users, and vulnerability intelligence providers may later identify:

additional affected or unaffected versions;
incorrect product or package names;
missing CPE or Package URL identifiers;
incomplete descriptions;
additional references, patches, or remediation information;
alternative severity assessments;
corrected weakness classifications;
downstream package information; or
structured extensions not represented in the authoritative CVE record.

Ideally, this information is submitted to the responsible CVE Numbering Authority (CNA) and incorporated into the authoritative CVE record.

In practice, the CNA may be unavailable, no longer operational, unable to evaluate the contribution, or unwilling to incorporate it. Useful information can therefore remain fragmented across advisories, issue trackers, repositories, research reports, and vulnerability databases.

BCP-11 separates three activities:

Contribution — publishing a supported technical assertion.
Review — evaluating the assertion and its evidence.
Resolution — optionally combining selected assertions with an authoritative CVE record.

BCP-11 defines contribution and review. Resolution is an implementation policy and does not modify the authoritative CVE record.

Design Principles

One assertion, one contribution

A contribution SHOULD contain one technical assertion or one coherent set of closely related assertions.

Unrelated changes SHOULD be published separately so they can be reviewed, superseded, withdrawn, disputed, or integrated independently.

Append instead of rewrite

A new proposal SHOULD create a new contribution fragment.

The technical content of an existing published contribution MUST NOT be silently rewritten.

Preserve provenance

Every material assertion MUST retain sufficient attribution and evidence for independent verification.

Permit disagreement

Conflicting contributions MAY coexist. A contribution does not become authoritative merely because it was published or reviewed.

Keep merging optional

The normative data is the set of contribution fragments. A complete corrected CVE document is an optional derived view.

Do not replace the CNA

The responsible CNA remains authoritative for the CVE record within the CVE Program. GNA 65530 does not claim ownership of, or authority over, the target CVE.

Scope

Every BCP-11 contribution:

MUST reference exactly one existing CVE identifier;
MUST concern the same underlying vulnerability as that CVE;
MUST use the GCVE container format defined in GCVE-BCP-05;
MUST use recordType set to update;
MUST contain a globally unique contributionId;
MUST contain sufficient provenance and evidence;
MUST remain distinguishable from authoritative CVE information; and
MUST NOT claim to replace the authoritative CVE record.

GNA 65530 MUST NOT:

allocate new identifiers beside the umbrella identifier in the BCP-11 scope;
publish a contribution for an issue without an existing CVE identifier (except for the rejected CVE);
claim ownership of the target CVE;
silently redistribute a modified CVE record as authoritative;
publish unrelated advisories through this mechanism; or
publish confidential or embargoed information without authorization.

If no CVE identifier exists, an eligible GNA SHOULD allocate a regular GCVE identifier according to GCVE-BCP-04.

Terminology

Target CVE

The existing CVE identifier to which a contribution applies.

Umbrella identifier

The deterministic GCVE-65530-* identifier associated with one target CVE. It groups all BCP-11 contributions concerning that CVE.

The umbrella identifier does not identify a new vulnerability and does not replace the CVE identifier.

Contribution fragment

A standalone JSON document containing one proposed assertion or one coherent set of closely related assertions about one target CVE.

Technical content

The proposed vulnerability information in the contribution’s content, targets, baseRecord, and optional patch fields.

Administrative metadata

Workflow information such as review status, upstream status, publication state, revision number, and timestamps.

Resolved community view

A generated representation combining an authoritative CVE record with selected contributions according to a declared policy.

Identifier Model

Umbrella identifier

For:

CVE-<YEAR>-<SEQUENCE>

the associated GNA 65530 identifier SHOULD be:

GCVE-65530-<YEAR>-<SEQUENCE>

Example:

CVE-2026-12345
GCVE-65530-2026-12345

Only one umbrella identifier SHOULD exist for each target CVE.

Contribution identifier

Every contribution MUST contain a globally unique contributionId.

A UUID URN is RECOMMENDED:

urn:uuid:0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d

UUID version 7 is RECOMMENDED when supported.

The umbrella identifier groups contributions. The contributionId identifies one contribution.

Relationship

A contribution SHOULD use:

{
  "destId": "CVE-2026-12345",
  "type": "proposes_update_to"
}

proposes_update_to extends the non-exhaustive relationship vocabulary defined by GCVE-BCP-05.

Contribution Fragment Format

A standalone contribution fragment contains exactly one GCVE object in x_gcve.

Minimal example

{
  "x_gcve": [
    {
      "vulnId": "GCVE-65530-2026-12345",
      "recordType": "update",
      "relationships": [
        {
          "destId": "CVE-2026-12345",
          "type": "proposes_update_to"
        }
      ],
      "x_gcve_community_contribution": {
        "contributionId": "urn:uuid:0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d",
        "targetId": "CVE-2026-12345",
        "datePublished": "2026-07-30T08:00:00Z",
        "dateUpdated": "2026-07-30T08:00:00Z",
        "revision": 1,
        "state": "active",
        "intent": "add",
        "areas": [
          "references"
        ],
        "summary": "Add a missing vendor advisory.",
        "contributors": [
          {
            "name": "Example Security Community",
            "type": "community",
            "reference": "https://example.invalid/community"
          }
        ],
        "evidence": [
          {
            "url": "https://example.invalid/advisory/12345",
            "description": "Public vendor advisory for the vulnerability."
          }
        ],
        "content": {
          "references": [
            {
              "url": "https://example.invalid/advisory/12345",
              "tags": [
                "vendor-advisory"
              ]
            }
          ]
        },
        "review": {
          "status": "pending"
        },
        "upstream": {
          "status": "not_submitted"
        }
      }
    }
  ]
}

Core Fields

GCVE container fields

vulnId MUST contain the deterministic GNA 65530 umbrella identifier.
recordType MUST be update.
relationships MUST reference the target CVE.
x_gcve_community_contribution MUST contain the contribution defined by this BCP.

`contributionId`

contributionId MUST uniquely identify the contribution and MUST NOT be reused for technically different content.

`targetId`

targetId MUST contain the target CVE identifier and MUST equal the relationship’s destId.

Dates and revision

datePublished MUST record initial publication.
dateUpdated MUST record the latest fragment revision.
revision MUST start at 1 and increase whenever administrative metadata changes.

Timestamps MUST use RFC 3339 format.

`state`

Allowed values are:

active;
withdrawn;
superseded.

The default is active.

`intent`

Recommended values are:

add;
correct;
remove;
clarify;
enrich;
other.

intent describes the proposal. It is not an instruction to mutate the current CVE record automatically.

`areas`

areas MUST identify one or more logical areas affected by the contribution.

Values SHOULD correspond to CVE ADP container fields or named x_ extensions, for example:

affected;
descriptions;
metrics;
problemTypes;
references;
solutions;
workarounds;
configurations;
exploits;
timeline;
x_gcve_cpe;
x_gcve_purl;
x_gcve_detection.

The list is extensible.

`summary`

summary MUST concisely explain the assertion and why it matters.

`contributors`

contributors MUST identify at least one source unless the submission is explicitly anonymous.

A contributor MAY be an individual, organization, vendor, project, distribution, community, researcher, or database.

Anonymous submissions MAY be accepted, but maintainers MUST independently validate them before setting review.status to reviewed.

Personal contact information MUST NOT be published without authorization.

`evidence`

evidence MUST contain sufficient material to evaluate the assertion.

Evidence may include:

vendor or distribution advisories;
source-code commits;
patches;
issue tracker discussions;
package metadata;
release notes;
technical analyses;
reproducible tests;
public maintainer statements.

Community voting or repetition of an unsupported claim is not sufficient evidence.

`content`

content contains the proposed structured information.

Where possible, fields inside content SHOULD follow CVE ADP container names and structures.

A contribution SHOULD include only the fields required to express its assertion. It SHOULD NOT copy the complete CVE record.

At least one of content or targets MUST be present.

Optional Fields

`baseRecord`

baseRecord identifies the authoritative CVE revision used while preparing the contribution.

It MAY contain:

dateUpdated;
serial;
digest;
digestAlgorithm;
canonicalization.

{
  "baseRecord": {
    "dateUpdated": "2026-05-12T09:30:00Z",
    "serial": 4,
    "digestAlgorithm": "sha-256",
    "canonicalization": "JCS",
    "digest": "sha256:0123456789abcdef..."
  }
}

When a digest is used, RFC 8785 JSON Canonicalization Scheme SHOULD be used before hashing.

A contribution MUST NOT assume that its base record remains the latest CVE record.

`targets`

targets MAY identify elements in the pinned base record that motivated a correction or removal.

{
  "targets": [
    {
      "path": "/containers/cna/affected/0",
      "description": "The affected entry containing the incorrect product name."
    }
  ]
}

A target path is meaningful only for the exact baseRecord. Consumers MUST NOT apply it to another revision.

`supersedes`

supersedes MAY contain earlier contributionId values.

{
  "supersedes": [
    "urn:uuid:0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d"
  ]
}

Superseded contributions MUST remain available for history and attribution.

`review`

Recommended review.status values are:

pending;
reviewed;
rejected;
disputed.

A reviewed contribution SHOULD record reviewedAt and MAY record reviewers, notes, or public review references.

A default resolved view SHOULD include only reviewed contributions.

`upstream`

Recommended upstream.status values are:

not_submitted;
submitted;
partially_integrated;
integrated;
rejected;
no_response.

The object MAY record submission dates, channels, public references, responses, and integration notes.

Publication state, review status, and upstream status are independent dimensions and MUST NOT be collapsed into one status.

`patch`

A contribution MAY contain an RFC 6902 JSON Patch as a convenience.

A patch:

MUST identify a pinned baseRecord;
SHOULD begin with test operations;
MUST NOT be the only representation of the proposal when content can express it;
MUST NOT be applied when the base revision or digest does not match.

{
  "patch": [
    {
      "op": "test",
      "path": "/containers/cna/affected/0/product",
      "value": "Firefox"
    },
    {
      "op": "replace",
      "path": "/containers/cna/affected/0/product",
      "value": "Firefox for Android"
    }
  ]
}

content remains the primary assertion. The patch is only a transformation aid for one exact source record.

`contentDigest`

A contribution MAY contain a digest of its content object. RFC 8785 canonicalization SHOULD be used before hashing.

A content digest helps prove that an administrative update did not modify the technical assertion.

`withdrawalReason`

A withdrawn contribution SHOULD explain why it was withdrawn.

Immutability and Revisions

After publication, material changes to the following require a new contribution and a new contributionId:

targetId;
intent;
areas;
summary;
contributors when attribution materially changes;
evidence supporting the assertion;
baseRecord;
targets;
content;
patch.

The replacement contribution SHOULD reference the earlier contribution using supersedes.

The following administrative fields MAY be updated in place:

dateUpdated;
revision;
state;
review;
upstream;
withdrawalReason.

Every administrative update MUST increase revision, update dateUpdated, and preserve the previous revision in publication history.

A publication service MUST NOT replace technical content while retaining the same contributionId.

Review and Conflict Handling

The review process SHOULD verify that:

the target CVE exists, is allocated or rejected;
the contribution concerns the same vulnerability;
the evidence is accessible and relevant;
product and version claims are supported;
package, CPE, and PURL identifiers are correct;
severity vectors are valid;
assumptions are distinguished from verified facts;
confidential information is not disclosed;
malicious or irrelevant references are not introduced.

A contribution MUST NOT be marked reviewed solely because it has broad community support.

Conflicting contributions MAY coexist. They MUST retain separate identifiers and provenance.

If a conflict cannot be resolved:

the relevant contributions SHOULD be marked disputed;
review notes SHOULD describe the disagreement;
a default resolved view SHOULD omit the disputed assertion;
consumers MUST NOT silently select one position without a declared policy.

Relationship with the Responsible CNA

The responsible CNA remains authoritative for the target CVE record.

Reviewed contributions SHOULD be submitted to the CNA when practical.

When a contribution is integrated upstream:

upstream.status SHOULD become integrated;
the integration date SHOULD be recorded;
a public reference SHOULD be included when available;
the contribution SHOULD remain published for audit and attribution.

Publication and Distribution

Contribution fragments MUST be published using the decentralized mechanisms defined by GCVE-BCP-03.

TODO: Some details of implementation to be reviewed.

A publication service SHOULD support:

lookup by target CVE;
lookup by umbrella identifier;
lookup by contributionId;
complete and incremental feeds;
revision history;
provenance;
open redistribution;
cryptographic integrity protection.

Recommended file layout

GCVE-65530-2026-12345/
├── index.json
├── urn-uuid-0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d.json
├── urn-uuid-0198a75d-8856-75a3-b69f-18b13c356e19.json
└── urn-uuid-0198a77a-f00b-79ab-8270-e166b4348f09.json

Each contribution file is normative.

index.json is a generated convenience document and MAY be rewritten as contributions or statuses change.

Example index

{
  "vulnId": "GCVE-65530-2026-12345",
  "targetId": "CVE-2026-12345",
  "generatedAt": "2026-07-30T12:00:00Z",
  "contributions": [
    {
      "contributionId": "urn:uuid:0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d",
      "state": "active",
      "reviewStatus": "reviewed",
      "areas": [
        "affected"
      ]
    },
    {
      "contributionId": "urn:uuid:0198a75d-8856-75a3-b69f-18b13c356e19",
      "state": "active",
      "reviewStatus": "pending",
      "areas": [
        "references"
      ]
    }
  ]
}

Resolved Community Views

A publication service MAY provide a resolved community view for consumers that do not want to perform separate CVE and contribution lookups.

A resolved view:

MUST identify the authoritative CVE input;
MUST identify every contribution used;
MUST identify its resolution policy;
MUST retain field-level or assertion-level provenance;
MUST expose unresolved conflicts;
MUST NOT be presented as the authoritative CVE record.

A default policy SHOULD:

begin with the latest available authoritative CVE record;
include only active, reviewed contributions;
exclude superseded, withdrawn, rejected, pending, and disputed contributions;
avoid applying JSON Patch unless the pinned base record matches;
preserve the source of every addition or replacement.

Example resolution metadata:

{
  "x_gcve_resolution": {
    "generatedAt": "2026-07-30T12:00:00Z",
    "targetId": "CVE-2026-12345",
    "policy": "gna-65530-reviewed-contributions-v1",
    "authoritativeInput": {
      "serial": 5,
      "dateUpdated": "2026-07-29T15:20:00Z"
    },
    "contributionInputs": [
      "urn:uuid:0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d"
    ],
    "excludedContributions": [
      {
        "contributionId": "urn:uuid:0198a75d-8856-75a3-b69f-18b13c356e19",
        "reason": "review-pending"
      }
    ],
    "conflicts": []
  }
}

BCP-11 does not define one universal merge algorithm. Different consumers may use different trust policies, but the selected policy and provenance MUST remain visible.

Consumer Guidance

Consumers MUST treat BCP-11 data as community-proposed information.

Consumers SHOULD distinguish:

authoritative CNA information;
community contributions;
reviewed and pending contributions;
disputed, withdrawn, and superseded contributions;
information integrated upstream.

Consumers MUST NOT:

silently present a contribution as CNA-authored information;
automatically apply a patch to an unpinned CVE record;
discard provenance;
assume all contributions under one umbrella identifier are compatible;
treat the umbrella identifier as a replacement for the CVE identifier.

Security, Trust, and Abuse Considerations

GNA 65530 maintainers SHOULD mitigate:

false affected-product claims;
malicious CPE, PURL, or package mappings;
reference spam;
manipulated scores;
unsupported exploitation claims;
attempts to remove valid affected versions;
impersonation;
confidential disclosures;
malicious JSON content;
oversized or deeply nested documents;
coordinated attempts to influence automated vulnerability-management systems.

Implementations SHOULD:

validate fragments against a published JSON Schema;
limit document size and nesting;
validate URLs;
sanitize rendered text;
avoid automatically fetching untrusted references;
preserve history;
authenticate maintainers and reviewers;
sign published feeds;
rate-limit submissions.

Human review SHOULD be required before a contribution enters a default resolved view.

Worked Examples

The examples use example.invalid and are illustrative.

Add a downstream affected package

The original CVE describes the upstream project. A distribution contributes its package-specific affected and fixed versions.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-65530-2026-12345",
      "recordType": "update",
      "relationships": [
        {
          "destId": "CVE-2026-12345",
          "type": "proposes_update_to"
        }
      ],
      "x_gcve_community_contribution": {
        "contributionId": "urn:uuid:0198a75d-8856-75a3-b69f-18b13c356e19",
        "targetId": "CVE-2026-12345",
        "datePublished": "2026-07-30T09:00:00Z",
        "dateUpdated": "2026-07-30T09:00:00Z",
        "revision": 1,
        "state": "active",
        "intent": "enrich",
        "areas": [
          "affected",
          "x_gcve_purl"
        ],
        "summary": "Add the affected package range for Example Linux 12.",
        "contributors": [
          {
            "name": "Example Linux Security Team",
            "type": "distribution",
            "reference": "https://example.invalid/linux/security"
          }
        ],
        "evidence": [
          {
            "url": "https://example.invalid/linux/advisories/ELA-2026-77",
            "description": "Distribution advisory identifying the fixed package."
          }
        ],
        "content": {
          "affected": [
            {
              "vendor": "Example Linux",
              "product": "examplelib",
              "collectionURL": "https://packages.example.invalid",
              "packageName": "examplelib",
              "versions": [
                {
                  "version": "0",
                  "lessThan": "2.4.7-3+el12u1",
                  "versionType": "custom",
                  "status": "affected"
                },
                {
                  "version": "2.4.7-3+el12u1",
                  "status": "unaffected"
                }
              ],
              "defaultStatus": "unknown",
              "x_gcve_purls": [
                "pkg:deb/example-linux/examplelib@2.4.7-3%2Bel12u1"
              ]
            }
          ]
        },
        "review": {
          "status": "reviewed",
          "reviewedAt": "2026-07-30T10:00:00Z"
        },
        "upstream": {
          "status": "not_submitted"
        }
      }
    }
  ]
}

Correct a product and version range

The complete corrected affected item is the primary assertion. The optional patch is tied to one exact CVE revision.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-65530-2020-15647",
      "recordType": "update",
      "relationships": [
        {
          "destId": "CVE-2020-15647",
          "type": "proposes_update_to"
        }
      ],
      "x_gcve_community_contribution": {
        "contributionId": "urn:uuid:0198a77a-f00b-79ab-8270-e166b4348f09",
        "targetId": "CVE-2020-15647",
        "datePublished": "2026-07-30T10:00:00Z",
        "dateUpdated": "2026-07-30T10:00:00Z",
        "revision": 1,
        "state": "active",
        "intent": "correct",
        "areas": [
          "affected"
        ],
        "summary": "Correct the product to Firefox for Android and the affected upper bound to 64.18.1.",
        "contributors": [
          {
            "name": "Example Vulnerability Curator",
            "type": "researcher",
            "reference": "https://example.invalid/researchers/curator"
          }
        ],
        "evidence": [
          {
            "url": "https://example.invalid/mobile/release-notes/64.18.1",
            "description": "Release notes identifying the fixed mobile release."
          }
        ],
        "baseRecord": {
          "serial": 3,
          "digestAlgorithm": "sha-256",
          "canonicalization": "JCS",
          "digest": "sha256:0123456789abcdef..."
        },
        "targets": [
          {
            "path": "/containers/cna/affected/0",
            "description": "The affected entry containing the incorrect product and upper bound."
          }
        ],
        "content": {
          "affected": [
            {
              "vendor": "Mozilla",
              "product": "Firefox for Android",
              "platforms": [
                "Android"
              ],
              "versions": [
                {
                  "version": "0",
                  "lessThan": "64.18.1",
                  "versionType": "custom",
                  "status": "affected"
                }
              ],
              "defaultStatus": "unaffected"
            }
          ]
        },
        "patch": [
          {
            "op": "test",
            "path": "/containers/cna/affected/0/product",
            "value": "Firefox"
          },
          {
            "op": "replace",
            "path": "/containers/cna/affected/0/product",
            "value": "Firefox for Android"
          },
          {
            "op": "replace",
            "path": "/containers/cna/affected/0/versions/0/lessThan",
            "value": "64.18.1"
          }
        ],
        "review": {
          "status": "reviewed",
          "reviewedAt": "2026-07-30T11:00:00Z"
        },
        "upstream": {
          "status": "submitted",
          "submittedAt": "2026-07-30T11:30:00Z",
          "reference": "https://example.invalid/issues/CVE-2020-15647"
        }
      }
    }
  ]
}

If the CVE record later changes, consumers can still understand the contribution from content without applying the patch.

Add an independent severity assessment

The community score does not replace the CNA score. Both can coexist with separate provenance.

{
  "contributionId": "urn:uuid:0198a79d-03ad-7fde-97ab-c2732e043844",
  "targetId": "CVE-2026-12345",
  "state": "active",
  "intent": "enrich",
  "areas": [
    "metrics"
  ],
  "summary": "Add a CVSS v3.1 assessment accounting for authentication and user interaction.",
  "contributors": [
    {
      "name": "Example CSIRT",
      "type": "organization",
      "reference": "https://example.invalid/csirt"
    }
  ],
  "evidence": [
    {
      "url": "https://example.invalid/csirt/analysis/CVE-2026-12345"
    }
  ],
  "content": {
    "metrics": [
      {
        "format": "CVSS",
        "cvssV3_1": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:N",
          "baseScore": 7.6,
          "baseSeverity": "HIGH"
        }
      }
    ]
  },
  "review": {
    "status": "reviewed"
  }
}

State that a downstream product is unaffected

An explicit unaffected assertion is preferable to deleting another source’s affected entry.

{
  "contributionId": "urn:uuid:0198a7af-e122-7581-bd66-14f7ff7025fc",
  "targetId": "CVE-2026-12345",
  "state": "active",
  "intent": "enrich",
  "areas": [
    "affected"
  ],
  "summary": "Example Linux 11 is unaffected because the vulnerable feature is disabled at build time.",
  "evidence": [
    {
      "url": "https://example.invalid/linux/build/examplelib.spec"
    }
  ],
  "content": {
    "affected": [
      {
        "vendor": "Example Linux",
        "product": "examplelib",
        "versions": [
          {
            "version": "11",
            "status": "unaffected"
          }
        ],
        "defaultStatus": "unknown"
      }
    ]
  },
  "review": {
    "status": "reviewed"
  }
}

Represent conflicting contributions

Contribution A:

{
  "contributionId": "urn:uuid:0198a7c0-3ec3-7713-8d78-aa9b57f4f620",
  "summary": "The issue is fixed in version 3.2.5.",
  "content": {
    "affected": [
      {
        "vendor": "Example Vendor",
        "product": "Example Product",
        "versions": [
          {
            "version": "0",
            "lessThan": "3.2.5",
            "versionType": "semver",
            "status": "affected"
          }
        ]
      }
    ]
  },
  "review": {
    "status": "disputed",
    "notes": "Another contribution provides evidence for a 3.2.4 fix."
  }
}

Contribution B:

{
  "contributionId": "urn:uuid:0198a7c8-f7eb-7a09-a546-52c242e073ef",
  "summary": "The issue is fixed in version 3.2.4.",
  "content": {
    "affected": [
      {
        "vendor": "Example Vendor",
        "product": "Example Product",
        "versions": [
          {
            "version": "0",
            "lessThan": "3.2.4",
            "versionType": "semver",
            "status": "affected"
          }
        ]
      }
    ]
  },
  "review": {
    "status": "disputed",
    "notes": "The package changelog conflicts with the other contribution's advisory."
  }
}

Both remain available. A default resolved view omits the disputed version correction.

Supersede a contribution

New evidence shows that a previously proposed fixed version was incorrect.

{
  "contributionId": "urn:uuid:0198a7df-8e63-73d7-a21d-7d84bf981b8d",
  "targetId": "CVE-2026-12345",
  "state": "active",
  "intent": "correct",
  "areas": [
    "affected"
  ],
  "summary": "Correct the fixed version to 3.2.5 because the 3.2.4 patch was incomplete.",
  "supersedes": [
    "urn:uuid:0198a7c8-f7eb-7a09-a546-52c242e073ef"
  ],
  "evidence": [
    {
      "url": "https://example.invalid/project/commits/final-fix"
    }
  ],
  "content": {
    "affected": [
      {
        "vendor": "Example Vendor",
        "product": "Example Product",
        "versions": [
          {
            "version": "0",
            "lessThan": "3.2.5",
            "versionType": "semver",
            "status": "affected"
          }
        ]
      }
    ]
  },
  "review": {
    "status": "reviewed"
  }
}

The older contribution remains published and its administrative state becomes superseded.

Withdraw a contribution

The technical content is not edited. Only administrative metadata changes.

{
  "contributionId": "urn:uuid:0198a7af-e122-7581-bd66-14f7ff7025fc",
  "datePublished": "2026-07-30T13:00:00Z",
  "dateUpdated": "2026-08-02T10:00:00Z",
  "revision": 2,
  "state": "withdrawn",
  "withdrawalReason": "The build configuration was for a development branch and did not apply to the released package.",
  "review": {
    "status": "rejected",
    "reviewedAt": "2026-08-02T09:30:00Z"
  },
  "upstream": {
    "status": "not_submitted"
  }
}

The publication service retains the earlier revision.

Generate a resolved view

The following is derived data, not a contribution fragment:

{
  "x_gcve_resolution": {
    "generatedAt": "2026-07-30T12:00:00Z",
    "targetId": "CVE-2026-12345",
    "policy": "gna-65530-reviewed-contributions-v1",
    "authoritativeInput": {
      "serial": 5,
      "dateUpdated": "2026-07-29T15:20:00Z"
    },
    "contributionInputs": [
      "urn:uuid:0198a74b-4f14-7d4e-a1c0-9aa7f7c6628d",
      "urn:uuid:0198a75d-8856-75a3-b69f-18b13c356e19"
    ],
    "excludedContributions": [
      {
        "contributionId": "urn:uuid:0198a7c0-3ec3-7713-8d78-aa9b57f4f620",
        "reason": "disputed"
      }
    ],
    "conflicts": []
  }
}

The generated document may expose CNA data and community data in separate containers so consumers can retrieve one document without losing provenance.

Minimal Implementation Profile

A first implementation only needs:

deterministic umbrella identifiers;
unique contribution identifiers;
standalone contribution fragments;
structured content;
contributor and evidence metadata;
review status;
supersession and withdrawal;
lookup by target CVE;
administrative revision history.

The following MAY be implemented later:

JSON Patch;
content digests;
resolved views;
automatic CNA submission;
conflict detection;
contributor trust policies;
signatures for individual contributions.

An implementation does not need a universal merge engine to conform to the core BCP.

Summary of Requirements

A conforming GNA 65530 implementation:

MUST publish only contributions concerning existing CVE records;
MUST use one deterministic umbrella identifier per target CVE;
MUST give every contribution a globally unique contributionId;
MUST use the GCVE-BCP-05 container format;
MUST use recordType set to update;
MUST reference the target CVE;
MUST preserve provenance and evidence;
MUST distinguish contributions from authoritative CVE information;
MUST preserve published technical content;
MUST create a new contribution for a material technical correction;
MUST preserve superseded and withdrawn contributions;
MUST NOT claim to replace the responsible CNA;
SHOULD use ADP-compatible structures inside content;
SHOULD keep contributions independently reviewable;
SHOULD submit reviewed contributions to the CNA when practical;
MAY publish conflicting contributions;
MAY include an RFC 6902 patch tied to a pinned base record;
MAY generate a resolved community view;
MUST preserve provenance in any resolved view.

Rationale

The contribution-fragment model avoids requiring GNA 65530 to continuously reconstruct and reconcile a complete replacement-like CVE record.

It provides:

independent attribution;
append-oriented publication;
straightforward review;
visible correction history;
explicit conflict representation;
stable grouping;
compatibility with CVE ADP-style content;
optional unified views for scanners and other consumers.

The central design rule is:

BCP-11 publishes contributions. A resolver may generate a view. The CNA remains authoritative.