GCVE BCP-05-X-03: Bringing Vulnerability Handling Timelines into Vulnerability Records

Vulnerability records usually provide a good description of what a vulnerability is, which products are affected, how severe it may be, and where additional information can be found.

They are often much less effective at describing what happened, when it happened, and who was involved during the vulnerability handling and disclosure process.

Following many discussions during VulnOptiCON 2026 in Luxembourg, this limitation became particularly clear. Vulnerability analysts, coordinators, vendors and other participants repeatedly discussed how difficult it can be to reconstruct a reliable timeline during vulnerability analysis and coordinated vulnerability disclosure.

To help address this, the GCVE initiative has published a new extension:

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

The extension provides a structured and machine-readable way to represent the lifecycle of a vulnerability from discovery and reporting through acknowledgement, validation, remediation and public disclosure.

Why do we need a vulnerability timeline?

A vulnerability rarely appears instantaneously as a finished advisory.

In practice, a vulnerability can go through many different stages:

• discovery by a researcher or another party;
• reporting to a vendor, coordinator or security team;
• acknowledgement of the report;
• validation and technical analysis;
• identification of exploitation in the wild;
• preparation or availability of mitigations;
• availability of a security fix;
• coordinated or public disclosure;
• publication of the vulnerability advisory;
• regulatory notifications and reporting.

Many of these events are currently scattered across email conversations, ticketing systems, advisories, source-code commits and vulnerability databases.

Even when individual timestamps are available, their meaning and relationship are often ambiguous.

Was a date the discovery date, the reporting date, the date the vendor became aware of exploitation, the publication date, or simply the date on which a database entry was modified?

BCP-05-X-03 aims to make those distinctions explicit.

From CVD timelines to regulatory timelines

This requirement has become increasingly important as vulnerability handling intersects with regulatory obligations.

For example, the EU Cyber Resilience Act introduces reporting requirements where the exact moment at which an organization becomes aware of certain events can influence subsequent notification deadlines.

This means that vulnerability timelines are no longer useful only for retrospective analysis. They can also become an important part of documenting how a vulnerability was handled and how operational or regulatory milestones relate to one another.

BCP-05-X-03 therefore supports not only conventional vulnerability-handling events, but also structured information related to regulatory processes.

A simplified lifecycle can be represented as follows:

---
config:
  theme: 'redux-color'
---
flowchart TD
    A[Discovered] --> B[Reported]
    B --> C[Acknowledged]
    C --> D[Validated]
    D --> E[Exploit observed]
    E --> F[Mitigation available]
    F --> G[Fix available]
    G --> H[Public disclosure]
    H --> I[Advisory published]

    subgraph CRA["EU Cyber Resilience Act (CRA) reporting"]
        direction TD
        R1[Regulatory awareness]
        R2[Early warning]
        R3[Vulnerability notification]
        R4[Final report]

        R1 --> R2
        R2 --> R3
        R3 --> R4
    end
    E -.->|may trigger| R1
    G -. remediation milestone .-> R4

    style CRA stroke-dasharray: 5 5

The objective is not to replace the underlying regulatory process, but to make the relevant timeline explicit, interoperable and machine-readable.

Designed to remain format-agnostic

One of the core principles of GCVE is that useful vulnerability information should not be locked into a single vulnerability format.

BCP-05-X-03 is therefore designed so that the timeline model can be reused with existing vulnerability publication ecosystems, including:

• CVE Record Format;
• CSAF;
• OSV.

Within GCVE records, the timeline can be carried as a BCP-05 extension while retaining compatibility with the existing CVE container model.

The same conceptual model can also be mapped into other advisory formats.

This is particularly important for vulnerability producers and consumers operating across multiple ecosystems. A vulnerability-handling timeline should describe the underlying process, independently of the serialization format used to publish the vulnerability.

Events are explicit and attributable

The extension describes timeline events individually rather than reducing the lifecycle to a small set of generic timestamps.

For example:

1
2
3
4
5
6

{
  "id": "evt-validation",
  "type": "validated",
  "timestamp": "2026-09-09T13:30:00Z",
  "actor": "vendor"
}

Another event could describe the moment exploitation was established:

1
2
3
4
5
6
7

{
  "id": "evt-exploitation",
  "type": "exploit-observed",
  "timestamp": "2026-09-10T10:00:00Z",
  "actor": "vendor",
  "description": "Evidence established that the vulnerability was being actively exploited."
}

By giving events their own identifiers, types, timestamps and actors, tools can reason about the vulnerability lifecycle without attempting to infer the meaning of dates from free-form text.

It also becomes possible to reference specific events from other parts of the timeline.

Supporting regulatory reporting

The extension can additionally represent regulatory milestones associated with a vulnerability.

A simplified example could look like:

1
2
3
4
5
6
7

{
  "framework": "EU-CRA",
  "jurisdiction": "EU",
  "assessment": "applicable",
  "trigger": "actively-exploited-vulnerability",
  "awarenessAt": "2026-09-10T10:00:00Z"
}

Notifications can then be associated with that regulatory context:

1
2
3
4
5
6
7

{
  "type": "early-warning",
  "dueAt": "2026-09-11T10:00:00Z",
  "submittedAt": "2026-09-10T15:42:00Z",
  "status": "submitted",
  "channel": "CRA-SRP"
}

This makes it possible to distinguish the technical vulnerability timeline from the regulatory reporting timeline, while still keeping both connected to the same vulnerability record.

Already implemented in patch2vuln

The extension is not only a specification.

Support for BCP-05-X-03 is already available in patch2vuln v1.2.0.

Starting with version 1.2.0, patch2vuln generates the BCP-05-X-03 vulnerability timeline extension by default when producing vulnerability information.

This means that information extracted or inferred during the patch-to-vulnerability workflow can immediately be represented using the common timeline model rather than being reduced to unstructured text.

patch2vuln is intended to assist analysts in transforming software patches into draft vulnerability advisories, and structured provenance and lifecycle information are an important part of keeping that automation understandable and reviewable.

Supported by Vulnerability-Lookup

Support has also been added to Vulnerability-Lookup.

The implementation is available in the following commit:

GCVE-BCP-05-X-03: vulnerability handling and disclosure timeline

This allows vulnerability records containing the extension to be consumed and handled by the Vulnerability-Lookup ecosystem and provides a foundation for exposing richer lifecycle information to analysts and users.

Vulnerability-Lookup already supports practical CVD workflows for GCVE GNAs, from receiving and investigating reports to preparing and publishing vulnerability records. Adding structured handling timelines extends that workflow with a better representation of the actual disclosure process.

Vulnerability records should describe the process too

A vulnerability record is traditionally considered a description of a technical security issue.

But for vulnerability analysts, CSIRTs, vendors, coordinators and regulators, understanding the process surrounding the vulnerability can be just as important.

When was it discovered?

When was it reported?

When did the vendor acknowledge it?

When was exploitation first known?

When did a mitigation become available?

When was a fix released?

When did public disclosure happen?

Which regulatory deadlines were triggered?

BCP-05-X-03 provides a common vocabulary to answer these questions directly in vulnerability data.

As with other GCVE extensions, the goal is to keep the model open, interoperable, reusable and easy to implement.

The specification is available here:

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

Implementations and feedback from vulnerability producers, analysts, vendors, CSIRTs and tooling developers are very welcome.