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

Submitted ⁨⁨5⁩ ⁨weeks⁩ ago⁩ by ⁨adulau@discourse.ossbase.org⁩ to ⁨GCVE.eu@discourse.ossbase.org⁩

https://discourse.ossbase.org/t/gcve-bcp-05-x-04-vulnerability-handling-and-advisory-publication-state/1136/1

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

Its purpose would be to represent the current snapshot, while BCP-05-X-03 remains the historical timeline.

Some state ideas:

not-public
embargoed
scheduled
published
withdrawn
superseded

The current challenge is to define embargoed. Means that a publication could be have done already done to a private group. So those state could be combined. We saw also case of publication which were limited to a trusted group and never going fully public.

The draft mode and alike must be also aligned with the vulnerability-lookup implementation. Prototype in vulnerability-lookup but a new rework is required.

original

Comments

Sort:hotnew top

adulau@discourse.ossbase.org ⁨1⁩ ⁨day⁩ ago
@cedric Do you see anything to update or change before we go for the development in the reference implementation?
original

adulau@discourse.ossbase.org ⁨4⁩ ⁨weeks⁩ ago

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.

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:

Handling state: the current operational state of the GNA’s handling process.
Publication state: the lifecycle state of the advisory issued by that GNA.
Visibility: the audience to which the advisory has actually been released or made available.
Embargo: whether a restriction on unrestricted public disclosure is currently active.
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:

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:

GNA A may publish a restricted advisory about a vulnerability under an active embargo.
GNA B may independently issue a public advisory about the same vulnerability under its own identifier.
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:

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

x_state MUST contain asOf and publication.
publication MUST contain both status and visibility.
All date-time fields MUST use RFC 3339. Producers SHOULD prefer UTC.
Producers MUST distinguish a planned release from an actual release.
publication.status: not-published and publication.status: scheduled MUST be used with publication.visibility: private.
publication.status: published MUST be used with publication.visibility: restricted or public.
publication.status: scheduled MUST include nextTransition.
An active embargo MUST NOT, by itself, imply that the advisory has not already been shared with a restricted group.
An embargo end date MUST NOT automatically trigger or establish public publication.
handling.status MUST describe the state of the containing GNA’s process, not the state of all participants’ handling or remediation processes.
Producers MUST NOT assert the handling, embargo, or publication state of another GNA as if it were the state of their own record.
If X-03 exists, relatedEvents values MUST refer to existing local timeline event IDs. Values MUST be unique.
Producers MUST NOT include confidential embargo schedules, recipient identities, case details, or non-public technical information in a record intended for public distribution.
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.
Consumers MUST NOT treat the absence of this extension as meaning that the vulnerability, the advisory, or another GNA’s record is public.
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:

Minimal handling vocabulary: Are the proposed generic handling values sufficient across vendors, CSIRTs, coordinators, and automated GNAs, or is a separately extensible vocabulary preferable?
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?
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?
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?
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

original

cedric@discourse.ossbase.org ⁨4⁩ ⁨weeks⁩ ago
I think that public is public, no need to say fully public. If there is an embargo, it isn’t public it is restricted. So public is not compatible with embargo. For me these are not the same kind of state. That’s why I detect some incompatibilities (states that are incompatible). It’s an issue and a solution in the same time. We can have the 3 types of states (for example):

Visibility

not-public

published

Publication process

(draft)

scheduled

published

withdrawn

Disclosure restrictions / or lifecycle (maybe redundant with what we have in BCP-005)

embargoed

superseded

That’s why the combinations of any of these states become awkward. But it works with types.

I added draft state for the case when the vulnerability coordinator is currently working on a new advisory. A draft is not necessaru private. I was not fan of this idea of “private draft” because I think that practically some people will use it to write advisory taht are not public (they will stay in draft mode for days). So here we could have a way to say “public draft” or “private draft”. I encourage “public draft” ! And from the beginning. It’s like with open source code. Public even before it is ready to be shown.
So this is a public draft (as encouraged by me):

{ "publication": { "state": "draft", "visibility": "public" } }

I would also make published explicitly mean “publicly published”.

and then we can have a model like:

{ "publication": { "state": "published", "published_at": "...", "visibility": "public" }, "handling": { "embargoed": false }, "superseded_by": null }

but now my issue is:

{ "publication": { "state": "published", "published_at": "...", "visibility": "public" }, "handling": { "embargoed": true }, "superseded_by": null }

this should be forbidden!
Default value of embargoe should be false. And during the embargoe:

{ "publication": { "state": "scheduled", "scheduled_at": "...", "visibility": "restricted" }, "handling": { "embargo": { "until": "2026-11-01T12:00:00Z" } }, "superseded_by": null }

and then we are transparent on when will be the end of the embargo.

state = published implies visibility = public.
When we have the state public the state can be omitted.

As for superseded_by, should we use the same in as in BCP-05. We have relationships and deprecation record type. So I would just set an id here to keep it simple. And don’t add redundancy in the global record.
original
- cedric@discourse.ossbase.org ⁨4⁩ ⁨weeks⁩ ago
  
  Image cedric:
  
  restricted
  
  the scope is the GNA owner of the record.
  Another GNA can publish independently the information.
  original