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

**URL:** <https://discourse.ossbase.org/t/gcve-bcp-05-x-04-vulnerability-handling-and-advisory-publication-state/1136>\
**Category:** GCVE\
**Tags:** bcp-05\
**Created:** [October 4, 2026, 7:29am UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-04-vulnerability-handling-and-advisory-publication-state/1136 "2026-10-04T07:29:21Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![adulau](https://discourse.ossbase.org/user_avatar/discourse.ossbase.org/adulau/32/6_2.png) [@adulau](https://discourse.ossbase.org/u/adulau)\
**Post date:** [October 10, 2026, 9:16am UTC](https://discourse.ossbase.org/t/gcve-bcp-05-x-04-vulnerability-handling-and-advisory-publication-state/1136/4 "2026-10-10T09:16:16Z")

</div>

# 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](https://creativecommons.org/licenses/by/4.0/).

Copyright (C) 2026 [GCVE Initiative](https://gcve.eu/).

## 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](https://gcve.eu/bcp/extension/gcve-bcp-05-x-03/). 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](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174) 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.

```json
{
  "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:

```plaintext
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:

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `asOf` | string | yes | RFC 3339 date-time at which the snapshot is asserted to apply. |
| `handling` | object | no | Current handling state of the record-owning GNA. |
| `publication` | object | yes | Current publication lifecycle and visibility. |
| `embargo` | object | no | Current state of an applicable restriction on unrestricted public release. |
| `nextTransition` | object | no | Next planned publication or expansion of visibility. |
| `relatedEvents` | array of strings | no | References to supporting event IDs in BCP-05-X-03 within the same record. |
| `description` | string | no | Non-sensitive clarification of the current state. |
| `references` | array of strings | no | Public supporting references, when appropriate. |

`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.

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `status` | string | yes | Current handling status from the registry below. |
| `description` | string | no | Additional non-sensitive explanation. |

### Handling Status Values

| Status | Meaning |
| --- | --- |
| `received` | The report or case has been received but substantial assessment has not yet begun. |
| `assessing` | The report is undergoing triage, verification, or impact assessment. |
| `coordinating` | The GNA is actively coordinating with relevant participants. |
| `remediating` | Remediation activities are underway or are being followed as part of handling. |
| `on-hold` | Active handling has been temporarily paused. |
| `completed` | The GNA considers the planned handling activities completed. |
| `closed` | The GNA has administratively closed the case. |

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.

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `status` | string | yes | Advisory lifecycle state. |
| `visibility` | string | yes | Actual visibility or distribution level. |
| `description` | string | no | Non-sensitive details about publication state. |

### Publication Status Values

| Status | Meaning |
| --- | --- |
| `not-published` | The GNA has not released the advisory outside its internal preparation environment. |
| `scheduled` | The first external publication is planned for a future time but has not yet occurred. |
| `published` | The GNA has released the advisory to at least one external audience, including a restricted group. |
| `withdrawn` | The GNA has withdrawn its advisory or retracted it as an active publication. |
| `superseded` | The GNA has replaced its advisory with a successor or considers it obsolete in favor of another publication. |

`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

| Visibility | Meaning |
| --- | --- |
| `private` | The advisory has not been distributed outside the record owner’s internal preparation environment. |
| `restricted` | The advisory has been shared with an identified or controlled constituency, but not released to the unrestricted public. |
| `public` | The advisory has been made available without a confidentiality or membership-based audience restriction. |

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

| Publication status | Visibility | Interpretation |
| --- | --- | --- |
| `not-published` | `private` | Prepared or being prepared internally. |
| `scheduled` | `private` | First external release is planned but has not occurred. |
| `published` | `restricted` | Already published to selected recipients, not publicly released. |
| `published` | `public` | Publicly released by this GNA. |
| `withdrawn` | `private`, `restricted`, or `public` | Withdrawal state; visibility indicates the GNA’s currently accessible notice or retained publication. |
| `superseded` | `private`, `restricted`, or `public` | Superseded state; visibility indicates the GNA’s currently accessible notice or retained publication. |

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.

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `status` | string | yes | `active`, `lifted`, or `expired`. |
| `until` | string | no | RFC 3339 date-time of an expected or agreed embargo end, when disclosable. |
| `description` | string | no | Non-sensitive explanation of scope or conditions. |
| `references` | array of strings | no | Public references relevant to embargo conditions. |

### 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.

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `scheduledAt` | string | yes | RFC 3339 date-time for the planned transition. |
| `targetVisibility` | string | yes | Intended visibility: `restricted` or `public`. |
| `description` | string | no | Non-sensitive explanation of the plan. |

`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:

```plaintext
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](https://docs.oasis-open.org/csaf/csaf/v2.1/csaf-v2.1.html) 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** :

| BCP-05-X-04 | Related CSAF 2.1 concept | Conversion guidance |
| --- | --- | --- |
| `publication.status` | `document.tracking.status` | No direct mapping. CSAF `draft`, `interim`, and `final` describe document maturity or expected revision frequency, not whether publication is public, restricted, or withdrawn. |
| `publication.visibility` | `document.distribution.tlp` / `sharing_group` | Partial mapping. Sharing restrictions may help determine visibility, but a TLP label by itself does not prove actual distribution. |
| `embargo.status` | Coordination or distribution metadata | No general direct mapping. Do not infer an embargo solely from a non-public TLP marking. |
| `nextTransition` | Other scheduling or workflow metadata | No universal direct mapping. A scheduled action is not an accomplished publication. |
| `handling.status` | Coordination or action statuses where available | Partial, contextual mapping only. The GNA’s overall handling state is not the status of each individual CSAF action. |

The [FIRST Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/) 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:

```plaintext
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.

```json
{
  "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.

```json
{
  "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.

```json
{
  "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:**

```json
{
  "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:**

```json
{
  "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.

```json
{
  "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:

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

```

The handling state is located at:

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

```

The publication status and visibility are located at:

```plaintext
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:

```plaintext
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](https://gcve.eu/bcp/gcve-bcp-05/)
- [GCVE BCP-05-X-03 — Vulnerability Handling and Disclosure Timeline](https://gcve.eu/bcp/extension/gcve-bcp-05-x-03/)
- [GCVE BCP-05-X-04 — Community Discussion](https://discourse.ossbase.org/t/gcve-bcp-05-x-04-vulnerability-handling-and-advisory-publication-state/1136)
- [CSAF Version 2.1](https://docs.oasis-open.org/csaf/csaf/v2.1/csaf-v2.1.html)
- [FIRST Traffic Light Protocol 2.0](https://www.first.org/tlp/)

---

_[View the full topic](https://discourse.ossbase.org/t/gcve-bcp-05-x-04-vulnerability-handling-and-advisory-publication-state/1136)._
