@cedric Do you see anything to update or change before we go for the development in the reference implementation?

First version

If you don’t know on which project to contribute to, CIRCL has a lot open-source projects:

Just an idea.

GCVE BCP-05-X-04: Vulnerability Handling and Advisory Publication State

• Version: 0.1
• Status: Draft
• Date: 2026-10-10
• Authors: GCVE Working Group
• BCP Extended ID: BCP-05
• BCP ID: BCP-05-X-04

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

Copyright (C) 2026 GCVE Initiative.

Abstract

This document defines an extension to GCVE BCP-05 for representing the current state of vulnerability handling and advisory publication as asserted by the GCVE Numbering Authority (GNA) responsible for the containing record.

The extension complements GCVE BCP-05-X-03 — Vulnerability Handling and Disclosure Timeline. BCP-05-X-03 records historical events; BCP-05-X-04 describes the current snapshot of a handling process and the availability of its advisory.

In particular, publication state, audience visibility, and embargo state are modeled independently. An advisory may have already been published to a restricted group while remaining under embargo for unrestricted public disclosure. A restricted advisory may also remain restricted indefinitely, with no intention to publish it publicly.

The state expressed by this extension applies only to the containing GNA’s record and publication process. It MUST NOT be interpreted as a global state for the underlying vulnerability or as constraining an independent publication by another GNA.

Motivation

Vulnerability handling and advisory publication do not always follow a linear sequence from discovery to unrestricted publication. In practice:

• a vulnerability report can be under assessment while no advisory has been released;
• an advisory can be scheduled for release but not yet distributed;
• an advisory can be distributed to a trusted constituency under an embargo;
• an advisory can be restricted without a planned public release;
• a public advisory can remain available while handling and remediation continue;
• an advisory can be withdrawn or superseded without erasing its historical publication; and
• different GNAs can publish information about the same vulnerability independently, at different times and to different audiences.

A single status such as embargoed or published cannot accurately represent all these cases. An embargo limits a planned form of disclosure; it does not necessarily imply that nobody has received the information. Similarly, not-public does not distinguish between information kept internally and an advisory already distributed to selected recipients.

This extension therefore separates:

1. Handling state: the current operational state of the GNA’s handling process.
2. Publication state: the lifecycle state of the advisory issued by that GNA.
3. Visibility: the audience to which the advisory has actually been released or made available.
4. Embargo: whether a restriction on unrestricted public disclosure is currently active.
5. Next planned publication: a prospective change in availability, distinct from completed publication.

These dimensions are complementary and MUST NOT be conflated.

Terminology and Normative Language

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

In this document:

• Record owner means the GNA responsible for the containing GCVE record and for the state assertions made in that record.
• Publication means release or distribution of an advisory outside the record owner’s internal preparation environment, including distribution to a restricted group.
• Public publication means release to an unrestricted audience; it is only one possible form of publication.
• Visibility means the extent of distribution or availability established by the record owner. It is not itself a permission grant to a recipient.
• Embargo means an applicable coordination or disclosure restriction preventing unrestricted public release until the restriction is lifted or otherwise ends.
• Snapshot means the state asserted at a particular point in time; it does not reconstruct the full history of transitions.

Placement

The extension MUST be placed in the extensions object of a GCVE BCP-05 record, using the key bcp-05-x-04.

Its value MUST contain one x_state object.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12345",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T09:00:00Z",
            "publication": {
              "status": "not-published",
              "visibility": "private"
            }
          }
        }
      }
    }
  ]
}

The asOf and publication members are REQUIRED. The handling, embargo, nextTransition, and relatedEvents members are OPTIONAL as described below.

In a CVE-format document, the corresponding path is:

containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state

The enclosing placement MAY differ where the GCVE object is distributed independently of a CVE-format document, but the names and semantics of the extension fields remain the same.

Data Model

The x_state object contains:

asOf MUST be a valid RFC 3339 date-time including a time-zone offset. UTC (Z) SHOULD be preferred. It represents the date and time of the state assertion, not necessarily the time of the underlying state transition.

The absence of an optional field MUST NOT be interpreted as a negative assertion. For example, omission of embargo means that no embargo assertion is provided, not that all embargoes are known to be absent.

Vulnerability Handling State

The optional handling object describes the current state of handling activities coordinated or tracked by the record-owning GNA.

Handling Status Values

These values describe an operational workflow, not an ordered vulnerability-severity scale or a determination of technical fix availability.

For example, remediating does not establish that a fix is available, and completed does not establish that all affected systems have deployed a corrective measure. An organization MAY return from completed or closed to an active handling state when new evidence is received.

The handling status MUST NOT be interpreted as the workflow status of another organization participating in the same coordinated disclosure.

Advisory Publication State

The REQUIRED publication object describes the state of the advisory managed by the record-owning GNA.

Publication Status Values

published MUST NOT be interpreted as implying unrestricted public access. The visibility field specifies the actual audience.

withdrawn and superseded describe the lifecycle state of the advisory, not necessarily the validity or invalidity of the underlying vulnerability. A withdrawn or superseded record MAY remain accessible as a notice, a historical record, or a tombstone. Relevant references or successor relationships SHOULD be maintained using the normal BCP-05 mechanisms.

Visibility Values

A GNA MAY use restricted when sharing only with coordinators, affected vendors, downstream maintainers, constituency members, ISACs, trusted users, or other designated recipients. It need not publish the recipients’ identities.

restricted is a visibility assertion by the owner of the containing record. It MUST NOT be interpreted as an assertion that other GNAs, vendors, researchers, or independent publishers are unable or forbidden to disclose their own information about the same vulnerability.

private and restricted are both not public, but they are not equivalent. A restricted advisory has already been published to some external audience, whereas a private one has not.

Publication and Visibility Combinations

A producer MUST NOT use published together with private, or use not-published or scheduled with restricted or public.

A public withdrawal notice does not establish that the previously withdrawn content remains available. The meaning and context SHOULD be clarified in publication.description or a corresponding BCP-05 record.

Embargo State

The optional embargo object represents the status of restrictions on unrestricted public disclosure within the record owner’s coordination or publication process.

Embargo Status Values

• active: The GNA asserts that an embargo currently applies to unrestricted public publication.
• lifted: A previously active embargo was explicitly lifted or cancelled by the relevant process.
• expired: A previously active embargo has reached its agreed expiry and the GNA asserts that it is no longer in force.

An embargo MAY be active while publication.status is published and publication.visibility is restricted.

An embargo SHOULD NOT be represented as active if the GNA has already released the same advisory publicly without relevant content restrictions. The GNA MAY publish a limited public notice while more sensitive content remains embargoed, but in that case it SHOULD use a separate scoped advisory or explain the distinction explicitly; the current extension does not define per-section embargoes.

The mere presence of an until timestamp MUST NOT cause a consumer to change publication.status, publication.visibility, or embargo.status automatically. Expiration of an embargo does not prove that an advisory was published.

embargo does not imply legal exclusivity or a restriction on the independent publication decisions of other GNAs. Where several parties have agreed to an embargo, this extension records only the containing GNA’s assertion about its own process.

Scheduled Publication and Visibility Changes

The optional nextTransition object describes the next planned release or expansion of advisory visibility.

nextTransition MAY be used when:

• publication.status is scheduled and publication.visibility is private; or
• publication.status is published and publication.visibility is restricted, with a future plan to release the advisory publicly.

If publication.status is scheduled, nextTransition MUST be present.

nextTransition MUST NOT be treated as proof that the scheduled action occurred. When the action takes place, the producer SHOULD update the snapshot and SHOULD record the actual event in BCP-05-X-03.

The presence of nextTransition does not create an obligation to publish, and a producer MAY change or cancel the plan. A planned release MAY remain confidential; producers MUST NOT expose an embargo date or a coordinated release plan solely to populate this field.

A restricted advisory MAY remain restricted indefinitely. In that case, nextTransition SHOULD be omitted.

Scope of State Assertions and GNA Autonomy

Each x_state object MUST describe the handling and publication state as asserted by the owner of the containing GCVE record.

This extension MUST NOT be used to declare or impose a globally authoritative publication state for a vulnerability across all GCVE identifiers, GNAs, CNAs, or independent advisory producers.

For example:

1. GNA A may publish a restricted advisory about a vulnerability under an active embargo.
2. GNA B may independently issue a public advisory about the same vulnerability under its own identifier.
3. GNA A’s publication.visibility: restricted remains an accurate assertion about GNA A’s own advisory, even though GNA B’s information is public.

Consumers MUST NOT resolve this situation by silently overwriting GNA A’s state with GNA B’s, or vice versa.

Records referring to the same vulnerability MAY use BCP-05 relationships to express identity or association. Such relationships do not merge or transfer ownership of publication-state assertions.

This model does not prevent the normal exchange, republication, or enrichment of vulnerability information according to its applicable publication terms. It prevents a local state assertion from being misrepresented as a universal state.

Relationship to BCP-05-X-03 Historical Timeline

BCP-05-X-03 and BCP-05-X-04 express different dimensions:

BCP-05-X-03                            BCP-05-X-04
--------------------------------      --------------------------------
Historical events                     Current snapshot
What happened                         What the GNA currently asserts
When it happened                      State as of a specified date-time
Who participated (when available)     Current handling and publication
Embargo agreed / extended             Embargo currently active or ended
Publication / disclosure occurred     Current visibility and status

The relatedEvents array MAY identify BCP-05-X-03 events that support or explain the current snapshot. When BCP-05-X-03 is present in the same record, each listed event ID MUST match an existing x_timeline.events[].id. Consumers MUST NOT interpret such links as a complete reconstruction of all state transitions.

For example:

• embargo-agreed in X-03 may explain an embargo.status: active in X-04.
• advisory-published in X-03 may explain publication.status: published in X-04, provided the event describes the same release scope.
• public-disclosure-planned in X-03 does not prove public availability; X-04 may still show publication.visibility: restricted.
• fix-available in X-03 does not itself determine X-04 handling.status or publication.status.

Historical events MUST NOT be rewritten merely because the current state changes. Conversely, current state MUST NOT be inferred solely from the presence of a historical event without a documented derivation rule.

CSAF 2.1 and TLP Interoperability

The Common Security Advisory Framework (CSAF) 2.1 includes document-level publication and distribution-related information, including document.tracking.status, document.distribution.tlp, and optional sharing group metadata.

Those fields overlap with aspects of BCP-05-X-04 but are not semantically equivalent:

The FIRST Traffic Light Protocol (TLP) 2.0 describes sharing boundaries for recipients. A TLP marking is not a substitute for access control, proof of publication, or an embargo agreement.

Implementations SHOULD preserve TLP metadata and sharing-group restrictions when converting to or from a format that supports them. They MUST NOT silently infer public merely from document maturity, or restricted solely because a restricted distribution was planned.

The same principles apply to other vulnerability interchange formats, including CVE-based records and OSV where no equivalent publication-state fields exist. Non-equivalent fields SHOULD be preserved as extension data rather than assigned misleading approximate values.

Processing and Validation Requirements

1. x_state MUST contain asOf and publication.
2. publication MUST contain both status and visibility.
3. All date-time fields MUST use RFC 3339. Producers SHOULD prefer UTC.
4. Producers MUST distinguish a planned release from an actual release.
5. publication.status: not-published and publication.status: scheduled MUST be used with publication.visibility: private.
6. publication.status: published MUST be used with publication.visibility: restricted or public.
7. publication.status: scheduled MUST include nextTransition.
8. An active embargo MUST NOT, by itself, imply that the advisory has not already been shared with a restricted group.
9. An embargo end date MUST NOT automatically trigger or establish public publication.
10. handling.status MUST describe the state of the containing GNA’s process, not the state of all participants’ handling or remediation processes.
11. Producers MUST NOT assert the handling, embargo, or publication state of another GNA as if it were the state of their own record.
12. If X-03 exists, relatedEvents values MUST refer to existing local timeline event IDs. Values MUST be unique.
13. Producers MUST NOT include confidential embargo schedules, recipient identities, case details, or non-public technical information in a record intended for public distribution.
14. Consumers MUST treat unsupported or unknown extension fields and status values as unrecognized, rather than silently rewriting them to a different known value. They SHOULD continue processing other recognized fields.
15. Consumers MUST NOT treat the absence of this extension as meaning that the vulnerability, the advisory, or another GNA’s record is public.
16. Publication, withdrawal, and supersession SHOULD be reflected in the containing record’s normal versioning, relationships, or deprecation information where appropriate.

Updates, Corrections, and State Transitions

A state snapshot is mutable over time. It SHOULD be updated when the GNA’s handling status, publication status, visibility, embargo, or publication plans change. When producing a new snapshot, the GNA MUST update asOf to describe the new assertion time.

The extension does not prescribe a mandatory linear state machine. For example:

not-published/private
        |
        +--> scheduled/private
        |           |
        |           v
        +------> published/restricted -----> published/public
                       |                         |
                       +--> withdrawn            +--> withdrawn
                       +--> superseded           +--> superseded

This diagram is illustrative, not exhaustive. Direct publication from not-published/private to published/public is valid. A restricted publication does not imply that public publication will ever occur.

A publisher SHOULD preserve previous factual transitions through BCP-05-X-03 events or an appropriate record-versioning/audit mechanism. The latest X-04 snapshot MUST NOT be treated as an immutable event log.

When corrections are made, consumers SHOULD preserve provenance and MUST NOT interpret earlier published snapshots as though they were always identical to the corrected version.

Privacy and Security Considerations

Publication-state metadata can be sensitive even when it does not contain vulnerability details. It may reveal:

• the existence of a confidential vulnerability report;
• the fact that a limited constituency has already received an advisory;
• anticipated embargo expiry or release dates;
• the existence of coordinated remediation activity; or
• changes to a vendor’s disclosure plans.

A publicly retrievable x_state object cannot protect confidential information merely because it declares visibility: private or visibility: restricted.

Implementations MUST enforce distribution restrictions outside this metadata, using appropriate authorization and information-sharing controls. Producers SHOULD omit or redact confidential parts of x_state before publishing a public version of a record.

A GNA MAY maintain a richer private snapshot internally and release a reduced snapshot publicly. Such redaction MUST NOT silently transform the meaning of a retained field. A public record MAY omit the extension entirely when even disclosure of its existence or current state would be inappropriate.

Consumers MUST NOT treat a claimed visibility or embargo state as a legal restriction on another GNA’s independently produced information, nor as evidence that the information is unavailable elsewhere.

Legal and Regulatory Considerations

This extension describes the publisher’s asserted operational state. It does not establish legal confidentiality, prove compliance with coordinated disclosure obligations, determine an embargo’s enforceability, or replace regulatory notification mechanisms.

Regulatory notifications and deadlines SHOULD continue to be represented separately using the regulatory component of BCP-05-X-03 where applicable. A regulatory notification is not necessarily a publication to the public or to a general trusted constituency.

Producers remain responsible for determining the applicable contractual, legal, regulatory, and information-sharing requirements before distributing a vulnerability record.

Example: Advisory Not Yet Published

The vulnerability is under assessment. No advisory has been released to external recipients.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12345",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T09:00:00Z",
            "handling": { "status": "assessing" },
            "publication": {
              "status": "not-published",
              "visibility": "private"
            }
          }
        }
      }
    }
  ]
}

Example: Restricted Publication Under an Active Embargo

The GNA has already released the advisory to a trusted group. Unrestricted public publication remains embargoed and is planned for a later date.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12345",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T09:00:00Z",
            "handling": { "status": "coordinating" },
            "publication": {
              "status": "published",
              "visibility": "restricted"
            },
            "embargo": {
              "status": "active",
              "until": "2026-10-22T08:00:00Z"
            },
            "nextTransition": {
              "scheduledAt": "2026-10-22T08:00:00Z",
              "targetVisibility": "public"
            },
            "relatedEvents": ["evt-embargo", "evt-restricted-release"]
          }
        },
        "bcp-05-x-03": {
          "x_timeline": {
            "events": [
              {
                "id": "evt-embargo",
                "type": "embargo-agreed",
                "timestamp": "2026-10-05T13:00:00Z"
              },
              {
                "id": "evt-restricted-release",
                "type": "advisory-published",
                "timestamp": "2026-10-09T10:00:00Z",
                "description": "Advisory shared with the trusted coordination group."
              }
            ]
          }
        }
      }
    }
  ]
}

Important: This example describes sensitive pre-publication metadata. It MUST NOT be distributed publicly unless its disclosure has been approved and is consistent with the embargo. The advisory-published event in this example documents a restricted release; it MUST NOT be interpreted as an unrestricted public-disclosure event.

Example: Permanently Restricted Publication

A GNA has shared an advisory with its constituency and does not currently plan unrestricted public publication. No embargo need be asserted; restricted visibility and an embargo are distinct concepts.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12346",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T10:00:00Z",
            "handling": { "status": "completed" },
            "publication": {
              "status": "published",
              "visibility": "restricted",
              "description": "Distributed only within the GNA's trusted constituency."
            }
          }
        }
      }
    }
  ]
}

Omission of nextTransition means that this snapshot does not assert a planned next publication step. It does not guarantee that a future release will never happen.

Example: Independent Publication by Another GNA

GNA A and GNA B independently describe the same underlying vulnerability. Their current publication states differ and remain valid within their respective record scopes.

GNA A:

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12345",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T09:00:00Z",
            "publication": {
              "status": "published",
              "visibility": "restricted"
            }
          }
        }
      }
    }
  ]
}

GNA B:

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1988-2026-54321",
      "recordType": "advisory",
      "relationships": [
        { "destId": "GCVE-1-2026-12345", "type": "equal" }
      ],
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T10:00:00Z",
            "publication": {
              "status": "published",
              "visibility": "public"
            }
          }
        }
      }
    }
  ]
}

GNA B’s public release MUST NOT automatically change GNA A’s record to visibility: public or cancel GNA A’s local embargo assertion.

Example: Withdrawn or Superseded Publication

A previously public advisory can be withdrawn or superseded while keeping a public notice or historical record accessible.

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12347",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-04": {
          "x_state": {
            "asOf": "2026-10-10T11:00:00Z",
            "handling": { "status": "closed" },
            "publication": {
              "status": "withdrawn",
              "visibility": "public",
              "description": "A public withdrawal notice remains accessible."
            }
          }
        }
      }
    }
  ]
}

For a superseded advisory, the publisher SHOULD also publish an appropriate successor reference or deprecation relationship using the underlying BCP-05 record model.

Example JSON Paths

The current state of the advisory is located at:

containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state

The handling state is located at:

containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state.handling.status

The publication status and visibility are located at:

containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state.publication.status
containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state.publication.visibility

Embargo status and the next planned publication are located at:

containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state.embargo.status
containers.cna.x_gcve[0].extensions.bcp-05-x-04.x_state.nextTransition

Relationship to Other GCVE BCPs

This extension complements:

• GCVE BCP-02: defines recommended operational handling and coordinated vulnerability disclosure practices.
• GCVE BCP-03: defines decentralized publication and synchronization; it does not impose a global advisory state across GNAs.
• GCVE BCP-04: defines the allocation of GCVE identifiers, which establish the scope for associated records.
• GCVE BCP-05: defines the containing GCVE record, record types, and relationships.
• GCVE BCP-05-X-01: can identify AI-assisted information processing, where applicable.
• GCVE BCP-05-X-02: can describe provenance of patch-derived advisory information.
• GCVE BCP-05-X-03: provides the historical vulnerability handling, coordination, disclosure, and regulatory timeline to which this current-state extension is complementary.
• GCVE BCP-07: provides exploitation-related assertions; active exploitation MUST NOT be inferred from an advisory’s publication state.
• GCVE BCP-12: records vulnerability sightings, which are distinct from publication state.

Open Questions for Public Review

The following points are intentionally left open for discussion before publication of this extension:

1. Minimal handling vocabulary: Are the proposed generic handling values sufficient across vendors, CSIRTs, coordinators, and automated GNAs, or is a separately extensible vocabulary preferable?
2. Granularity of visibility: Is private / restricted / public sufficient, given that TLP 2.0 and CSAF sharing-group metadata can express more specific recipient rules? Do we want to support MISP sharing-group if the records are shared via MISP communities?
3. Partial publication: Should a later revision allow a public summary and embargoed full advisory to be represented as independently scoped components, or should separate BCP-05 records remain the recommended solution?
4. Retractions: Should the draft define an additional structured reference to the publicly accessible withdrawal/supersession notice, or rely solely on existing BCP-05 relationships and references?
5. State provenance: Is the containing GNA’s record identity sufficient to attribute the assertion, or should x_state include an optional distinct issuing-party identifier for delegated publishers?

References

• GCVE BCP-05 — GCVE Vulnerability Format
• GCVE BCP-05-X-03 — Vulnerability Handling and Disclosure Timeline
• GCVE BCP-05-X-04 — Community Discussion
• CSAF Version 2.1
• FIRST Traffic Light Protocol 2.0