GCVE BCP-05-X-03: Vulnerability Handling and Disclosure Timeline

• Version: 1.0
• Status: Draft
• Date: 2026-10-01
• Authors: GCVE Working Group
• BCP Extended ID: BCP-05
• BCP ID: BCP-05-X-03

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 handling, coordination, remediation, disclosure, and regulatory notification timeline associated with a vulnerability advisory.

The extension provides a machine-readable representation of significant events during the vulnerability lifecycle, following the principles described in GCVE BCP-02 — Practical Guide to Vulnerability Handling and Disclosure.

It additionally provides an optional mechanism for recording regulatory notification milestones, including timelines associated with the European Union Cyber Resilience Act (CRA), without conflating regulatory notification with coordinated vulnerability disclosure or public publication.

The objective is to improve transparency, interoperability, process analysis, and automation while preserving the distinction between:

• vulnerability discovery and reporting;
• acknowledgement and validation;
• coordinated vulnerability disclosure;
• remediation and availability of corrective measures;
• public advisory publication; and
• regulatory notifications.

Motivation

GCVE BCP-02 recommends that vulnerability advisories include a discovery and disclosure timeline describing significant events such as when a vulnerability was reported, fixed, and publicly disclosed.

In practice, vulnerability handling contains considerably more useful information than these three dates. A complete process may include:

• initial discovery;
• report submission;
• acknowledgement;
• vulnerability validation;
• identifier allocation;
• coordination with affected parties;
• agreement or modification of an embargo;
• development and testing of remediation;
• availability of a workaround;
• availability of a corrective measure;
• detection of active exploitation;
• public disclosure; and
• regulatory notification.

Recording these events in a structured form enables vulnerability databases, CSIRTs, GNAs, CNAs, vendors, open-source projects, researchers, and CVD platforms to exchange and analyse handling timelines consistently.

Regulatory requirements can introduce additional deadlines that are related to, but distinct from, the CVD process. For example, under the European Union Cyber Resilience Act, a manufacturer becoming aware of an actively exploited vulnerability may be subject to specific notification deadlines.

This extension therefore models operational vulnerability-handling events separately from regulatory notification requirements.

Placement

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

Its value MUST contain one x_timeline object.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12345",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-03": {
          "x_timeline": {
            "events": [],
            "regulatory": []
          }
        }
      }
    }
  ]
}

The regulatory member is OPTIONAL.

Data Model

The x_timeline object contains:

Handling and Disclosure Events

Each member of events represents a significant event in the vulnerability lifecycle.

Example:

1
2
3
4
5
6
7

{
  "id": "evt-3",
  "type": "validated",
  "timestamp": "2026-09-10T14:20:00Z",
  "actor": "vendor",
  "description": "The vulnerability was reproduced and confirmed."
}

Event Fields

When a precise time is known, an RFC 3339 date-time SHOULD be used and UTC (Z) SHOULD be preferred.

When only a calendar date is reliably known, an ISO 8601 full date MAY be used.

Event Types

The following event types are defined:

Event types are intended to describe facts rather than workflow states.

Producers MAY omit events that are unknown or not relevant.

Consumers MUST NOT infer that an omitted event did not occur.

Additional event types MAY be introduced in future revisions of this extension. Consumers MUST ignore event types they do not understand rather than rejecting the complete extension.

Actor Values

The actor field MAY use one of the following values:

• reporter
• researcher
• vendor
• maintainer
• coordinator
• gna
• cna
• csirt
• regulator
• downstream
• other

The role identifies the party associated with the event and does not require the publication of a natural person’s identity.

Regulatory Timeline

The optional regulatory array represents regulatory processes associated with the vulnerability.

Regulatory notification is distinct from public vulnerability disclosure.

A notification to a competent authority, national CSIRT, ENISA, or another regulatory recipient MUST NOT be represented as a public-disclosure event unless the vulnerability information was actually made public.

Each regulatory entry describes one regulatory framework or reporting regime.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "framework": "EU-CRA",
  "jurisdiction": "EU",
  "assessment": "applicable",
  "trigger": "actively-exploited-vulnerability",
  "awarenessAt": "2026-09-10T10:00:00Z",
  "notifications": [
    {
      "type": "early-warning",
      "dueAt": "2026-09-11T10:00:00Z",
      "submittedAt": "2026-09-10T15:42:00Z",
      "status": "submitted",
      "channel": "CRA-SRP"
    },
    {
      "type": "vulnerability-notification",
      "dueAt": "2026-09-13T10:00:00Z",
      "submittedAt": "2026-09-12T08:30:00Z",
      "status": "submitted",
      "channel": "CRA-SRP"
    },
    {
      "type": "final-report",
      "triggerEvent": "evt-fix-available",
      "dueAt": "2026-09-30T09:00:00Z",
      "status": "pending",
      "channel": "CRA-SRP"
    }
  ]
}

Regulatory Fields

Assessment Values

The assessment field MUST use one of:

• not-assessed
• not-applicable
• potentially-applicable
• applicable

The value expresses the publisher’s process assessment and MUST NOT be interpreted by consumers as an authoritative legal determination.

Regulatory Notification Object

Each regulatory notification MAY contain:

Notification Status

The status field SHOULD use one of:

• pending
• submitted
• updated
• not-required
• withdrawn

These values describe workflow state only.

A submitted value MUST NOT by itself be interpreted as evidence of regulatory compliance.

European Union Cyber Resilience Act Profile

This extension defines EU-CRA as the conventional framework identifier for reporting associated with Regulation (EU) 2024/2847, the Cyber Resilience Act.

For an actively exploited vulnerability, an entry MAY use:

1
2
3
4
5

{
  "framework": "EU-CRA",
  "jurisdiction": "EU",
  "trigger": "actively-exploited-vulnerability"
}

When the publisher determines that the relevant CRA reporting requirement applies, assessment SHOULD be applicable.

The timeline MAY record the manufacturer’s awareness time using awarenessAt.

For an actively exploited vulnerability, the following notification types are defined:

early-warning

Represents the early warning notification required without undue delay and, where applicable, within 24 hours after the manufacturer becomes aware of the actively exploited vulnerability.

Recommended basis:

Regulation (EU) 2024/2847 Article 14(2)(a)

vulnerability-notification

Represents the subsequent vulnerability notification required without undue delay and, where applicable, within 72 hours after awareness, unless the relevant information has already been provided.

Recommended basis:

Regulation (EU) 2024/2847 Article 14(2)(b)

final-report

Represents the final report associated with an actively exploited vulnerability.

The relevant deadline is based on the availability of a corrective or mitigating measure rather than the original awareness timestamp.

A final-report SHOULD therefore use triggerEvent to reference the corresponding fix-available or mitigation-available event when that event is represented in the timeline.

Recommended basis:

Regulation (EU) 2024/2847 Article 14(2)(c)

For CRA actively exploited vulnerability reporting, the final report is, where applicable, due no later than 14 days after a corrective or mitigating measure becomes available.

CRA Example

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107

{
  "x_gcve": [
    {
      "vulnId": "GCVE-1-2026-12345",
      "recordType": "advisory",
      "extensions": {
        "bcp-05-x-03": {
          "x_timeline": {
            "events": [
              {
                "id": "evt-discovery",
                "type": "discovered",
                "timestamp": "2026-09-07",
                "actor": "researcher"
              },
              {
                "id": "evt-report",
                "type": "reported",
                "timestamp": "2026-09-08T08:15:00Z",
                "actor": "researcher"
              },
              {
                "id": "evt-ack",
                "type": "acknowledged",
                "timestamp": "2026-09-08T09:02:00Z",
                "actor": "vendor"
              },
              {
                "id": "evt-validation",
                "type": "validated",
                "timestamp": "2026-09-09T13:30:00Z",
                "actor": "vendor"
              },
              {
                "id": "evt-exploitation",
                "type": "exploit-observed",
                "timestamp": "2026-09-10T10:00:00Z",
                "actor": "vendor",
                "description": "Evidence established that the vulnerability was being actively exploited."
              },
              {
                "id": "evt-mitigation",
                "type": "mitigation-available",
                "timestamp": "2026-09-10T17:00:00Z",
                "actor": "vendor"
              },
              {
                "id": "evt-fix-available",
                "type": "fix-available",
                "timestamp": "2026-09-16T09:00:00Z",
                "actor": "vendor",
                "description": "Security update made available to users."
              },
              {
                "id": "evt-disclosure",
                "type": "public-disclosure",
                "timestamp": "2026-09-16T09:15:00Z",
                "actor": "vendor"
              },
              {
                "id": "evt-advisory",
                "type": "advisory-published",
                "timestamp": "2026-09-16T09:15:00Z",
                "actor": "vendor"
              }
            ],
            "regulatory": [
              {
                "framework": "EU-CRA",
                "jurisdiction": "EU",
                "assessment": "applicable",
                "trigger": "actively-exploited-vulnerability",
                "awarenessAt": "2026-09-10T10:00:00Z",
                "notifications": [
                  {
                    "type": "early-warning",
                    "dueAt": "2026-09-11T10:00:00Z",
                    "submittedAt": "2026-09-10T15:42:00Z",
                    "status": "submitted",
                    "channel": "CRA-SRP",
                    "basis": "Regulation (EU) 2024/2847 Article 14(2)(a)"
                  },
                  {
                    "type": "vulnerability-notification",
                    "dueAt": "2026-09-13T10:00:00Z",
                    "submittedAt": "2026-09-12T08:30:00Z",
                    "status": "submitted",
                    "channel": "CRA-SRP",
                    "basis": "Regulation (EU) 2024/2847 Article 14(2)(b)"
                  },
                  {
                    "type": "final-report",
                    "triggerEvent": "evt-fix-available",
                    "dueAt": "2026-09-30T09:00:00Z",
                    "status": "pending",
                    "channel": "CRA-SRP",
                    "basis": "Regulation (EU) 2024/2847 Article 14(2)(c)"
                  }
                ]
              }
            ]
          }
        }
      }
    }
  ]
}

Relationship Between BCP-02 and Regulatory Timelines

GCVE BCP-02 defines practical recommendations for coordinated vulnerability handling and disclosure.

The events represented by this extension provide a machine-readable expression of that process.

In particular:

discovered
    |
reported
    |
received / acknowledged
    |
triaged / validated
    |
coordination-started
    |
remediation-started
    |
mitigation-available / fix-developed
    |
fix-available
    |
public-disclosure / advisory-published
    |
case-closed

Individual cases MAY omit steps, contain additional steps, or execute several steps in parallel.

Regulatory processes MAY branch from this timeline independently:

                   +--> regulatory awareness
                   |        |
validated/exploit--+        +--> early warning
                            |
                            +--> vulnerability notification
                            |
fix/mitigation available ---+--> final report

The existence of regulatory reporting MUST NOT modify the semantics of CVD events.

In particular:

• a CRA early warning is not a public disclosure;
• a CRA vulnerability notification is not an advisory publication;
• assignment of a GCVE or CVE identifier does not by itself trigger or satisfy a CRA reporting obligation;
• publication of a vulnerability advisory does not by itself satisfy a regulatory reporting requirement; and
• regulatory reporting does not by itself mean vulnerability information has been publicly disclosed.

Public Disclosure and Corrective Measures

BCP-02 recommends coordinating public disclosure with the availability of a fix or other protective measure whenever practical.

For products within the scope of applicable regulation, additional vulnerability-handling requirements may apply.

The operational timeline SHOULD therefore distinguish at least:

fix-developed

from:

fix-available

and from:

public-disclosure

A fix can exist internally before it is available to users, and the availability of a corrective measure can itself trigger a regulatory deadline.

Processing and Validation Requirements

1. events MUST contain an array of event objects.

2. Every event MUST contain a unique id, a type, and a timestamp.

3. Events SHOULD be ordered chronologically.

4. Producers MUST preserve the factual distinction between report receipt, validation, remediation, availability of a corrective measure, and public disclosure.

5. A triggerEvent MUST reference an existing event id within the same x_timeline object.

6. Regulatory notifications MUST NOT be represented as public disclosure unless the underlying information was actually made public.

7. dueAt values SHOULD represent deadlines determined by the producer from the applicable regulatory requirements. Consumers SHOULD NOT independently infer legal compliance solely by comparing dueAt and submittedAt.

8. Regulatory deadlines MAY depend on facts, exceptions, interpretations, or subsequent regulatory guidance not represented in the vulnerability record.

9. assessment: applicable indicates the producer’s assessment and MUST NOT be interpreted as a definitive legal determination by downstream consumers.

10. Unknown event types, regulatory frameworks, notification types, or fields MUST NOT cause consumers to reject the complete extension.

11. Producers SHOULD include only information that is appropriate for the distribution level of the containing vulnerability record.

12. Producers MUST NOT publish confidential regulatory identifiers, coordination details, personal information, or non-public vulnerability information merely for the purpose of completing the timeline.

Updates and Corrections

A vulnerability timeline can evolve after publication.

For example:

• active exploitation may be discovered after an advisory has been published;

• additional affected parties may be identified;

• a corrective measure may be replaced;

• regulatory notifications may be updated;

• an embargo may change;

• the advisory may be corrected or expanded.

Producers MAY append additional events to the timeline.

Previously published factual events SHOULD NOT normally be removed. If an event was incorrect, the publisher SHOULD correct it in a way that preserves sufficient provenance to understand the change when supported by the surrounding publication system.

Privacy and Security Considerations

Vulnerability-handling timelines can reveal sensitive operational information.

In particular, they may disclose:

• when an organization first became aware of a vulnerability;

• the existence of confidential coordination;

• vendors or downstream projects that were privately notified;

• regulatory submissions;

• internal remediation activities;

• embargo periods;

• non-public exploitation information; or

• identifiers issued by regulatory platforms.

A producer MUST review timeline data before publication.

The presence of fields such as description, reference, or notes MUST NOT be used to publish confidential information that would otherwise be excluded from the vulnerability advisory.

When this extension is used internally before public disclosure, implementations MAY maintain additional non-public events. These SHOULD be removed, redacted, or transformed as appropriate before publishing the GCVE record.

The reference field of a regulatory notification SHOULD NOT contain confidential CRA SRP submission identifiers unless their publication has explicitly been determined to be appropriate.

Legal and Regulatory Considerations

This extension is a vulnerability-information interchange format and not a compliance determination mechanism.

Regulatory deadlines and requirements may change through legislation, delegated acts, implementing acts, regulatory guidance, judicial interpretation, or other applicable rules.

Therefore:

• producers are responsible for determining which regulatory obligations apply;

• consumers MUST NOT treat the presence or absence of this extension as evidence of regulatory compliance;

• consumers MUST NOT treat timeline calculations as legal advice; and

• regulatory profiles SHOULD be revised when the applicable framework changes.

The explicit dueAt field is preferred over requiring consumers to calculate regulatory deadlines from hard-coded rules. This allows the format to remain useful when regulatory requirements evolve.

Interoperability Considerations

The timeline is intended to complement rather than replace existing BCP-05 and CVE record fields.

The extension SHOULD NOT duplicate:

• vulnerability descriptions;

• affected product information;

• CVSS metrics;

• CWE classifications;

• references already represented by the containing record; or

• KEV assertions.

Where active exploitation is established, a publisher SHOULD additionally consider publishing the corresponding machine-readable information using GCVE BCP-07.

BCP-05-X-01 MAY be used when AI-assisted processing contributed to the generation or analysis of timeline information.

BCP-05-X-02 MAY be used when vulnerability metadata or remediation information was derived from analysis of a software patch.

Minimal Example

A producer that only wants to publish the disclosure history MAY use:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

{
  "bcp-05-x-03": {
    "x_timeline": {
      "events": [
        {
          "id": "evt-1",
          "type": "reported",
          "timestamp": "2026-08-20",
          "actor": "researcher"
        },
        {
          "id": "evt-2",
          "type": "acknowledged",
          "timestamp": "2026-08-20",
          "actor": "vendor"
        },
        {
          "id": "evt-3",
          "type": "validated",
          "timestamp": "2026-08-22",
          "actor": "vendor"
        },
        {
          "id": "evt-4",
          "type": "fix-available",
          "timestamp": "2026-09-12",
          "actor": "vendor"
        },
        {
          "id": "evt-5",
          "type": "advisory-published",
          "timestamp": "2026-09-12",
          "actor": "vendor"
        }
      ]
    }
  }
}

Example JSON Paths

The handling events for a vulnerability are located at:

containers.cna.x_gcve[0].extensions.bcp-05-x-03.x_timeline.events

The CRA regulatory timeline is located at:

containers.cna.x_gcve[0].extensions.bcp-05-x-03.x_timeline.regulatory

An individual regulatory notification can therefore be located under:

containers.cna.x_gcve[0].extensions.bcp-05-x-03.x_timeline.regulatory[].notifications[]

Relationship to Other GCVE BCPs

This extension complements:

• GCVE BCP-02 — defines the practical vulnerability handling and coordinated disclosure process represented by the timeline.
• GCVE BCP-04 — identifier allocation may be represented using the identifier-assigned event.
• GCVE BCP-05 — defines the containing GCVE vulnerability record.
• GCVE BCP-05-X-01 — can describe AI assistance used during vulnerability analysis or advisory preparation.
• GCVE BCP-05-X-02 — can preserve provenance where vulnerability information was generated from software patches.
• GCVE BCP-07 — should be considered when the timeline establishes known exploitation.
• GCVE BCP-12 — sightings may provide evidence relevant to an exploit-observed event.

The extension is intentionally generic enough to represent non-CRA regulatory or contractual vulnerability-reporting timelines in future implementations.