GCVE Lab
Draft proposal
The GCVE Lab is an open space for experimenting with new ideas, tools, formats, and services related to the Global CVE Allocation System.
The lab allows the GCVE community to explore promising concepts without immediately imposing the stability, compatibility, and operational requirements expected from the core GCVE infrastructure.
Some experiments may eventually become official GCVE tools or services. Others may remain research prototypes, inspire different projects, or be discontinued when the experiment has achieved its purpose.
Objectives
The GCVE Lab aims to:
- develop experimental open-source tools related to vulnerability identification, publication, enrichment, and coordination;
- test new approaches before considering their integration into the GCVE ecosystem;
- encourage rapid prototyping and practical experimentation;
- collect feedback from vulnerability researchers, vendors, CSIRTs, GNAs, CNAs, open-source communities, and other interested organisations;
- provide reusable implementations and reference material for emerging GCVE concepts;
- openly document both successful and unsuccessful experiments.
An experiment does not need to become an operational service to be useful. Negative results, limitations, and discarded approaches can provide valuable information for future GCVE developments.
Open Participation
The GCVE Lab is open to external contributors.
Individuals, research teams, open-source projects, vendors, CSIRTs, public institutions, and other communities are welcome to:
- propose new experiments;
- contribute code, documentation, tests, or datasets;
- review existing prototypes;
- evaluate tools in their own environments;
- report limitations and interoperability issues;
- suggest that an experiment be promoted, redesigned, or discontinued.
Experiments should preferably be developed openly from an early stage so that their assumptions, design choices, and limitations can be reviewed by the wider community.
Proposals and Discussions
Proposals for new GCVE Lab experiments are published and discussed on discourse.ossbase.org.
The discussion forum provides a public place to:
- present the objective and scope of a proposed experiment;
- collect feedback before implementation begins;
- identify interested contributors and maintainers;
- discuss technical approaches, formats, and interoperability;
- document important design decisions;
- evaluate whether an idea belongs in the GCVE Lab;
- review whether an existing experiment should be continued, promoted, redesigned, archived, or discarded.
Publishing a proposal on the forum does not automatically create a GCVE Lab project. The discussion should first establish that the experiment is sufficiently relevant, concrete, and aligned with the objectives of GCVE.
Once there is enough interest and agreement to proceed, a dedicated Git repository may be created for the experiment.
Repository Naming
Each experiment is maintained in a dedicated Git repository.
Experimental repositories use the following prefix:
gcve-lab-
Examples include:
gcve-lab-example-tool
gcve-lab-experimental-format
gcve-lab-vulnerability-enrichment
The prefix makes it clear that the repository contains experimental work and is not yet part of the stable GCVE toolset.
If an experiment matures into a core GCVE project, the repository is renamed and the gcve-lab- prefix is removed.
For example:
gcve-lab-example-tool
may eventually become:
gcve-example-tool
Renaming a repository does not happen automatically. It requires a review of the project’s usefulness, maintenance model, security, interoperability, documentation, and operational readiness.
Experiment Lifecycle
A GCVE Lab experiment may follow several stages.
Proposal
A problem, opportunity, or research question is identified.
The proposal is published on discourse.ossbase.org and should explain what the experiment intends to test, how it relates to GCVE, and what results are expected.
The proposal is openly discussed before the experiment proceeds to implementation.
Prototype
An initial open-source implementation is created in a gcve-lab- repository. At this stage, interfaces, features, and data formats may change frequently.
The repository should reference the original discussion so that contributors can understand the context and design decisions behind the experiment.
Evaluation
The community tests the experiment, provides feedback, identifies limitations, and evaluates whether it addresses a real need.
Technical discussions may take place in the repository, while broader discussions about the experiment’s direction and future may continue on discourse.ossbase.org.
Outcome
An experiment may have one of several outcomes:
- Promotion: the project becomes a maintained GCVE tool or service and the
gcve-lab-prefix is removed. - Continuation: the project remains in the lab while additional research or development is performed.
- Reuse: parts of the experiment are integrated into another GCVE project.
- Archive: the project is retained for reference but is no longer actively developed.
- Discard: the approach is abandoned, with the findings and reasons documented whenever possible.
There is no requirement for every experiment to become a core GCVE project.
Important outcomes and decisions should be documented publicly, either in the project repository or in the corresponding discussion on discourse.ossbase.org.
Experimental Status
Software and specifications published through the GCVE Lab should be considered experimental unless explicitly stated otherwise.
Lab projects may:
- introduce incompatible changes;
- contain incomplete features;
- have limited documentation or testing;
- depend on experimental formats or services;
- be unsuitable for production environments;
- be discontinued or significantly redesigned.
Each repository should clearly describe its current status, intended audience, known limitations, and security considerations.
The presence of a project in the GCVE Lab does not mean that it is endorsed as an operational GCVE component or that it will become part of the core GCVE infrastructure.
Open Source
GCVE Lab projects are developed as open-source software.
Whenever possible, repositories should include:
- a recognised open-source licence;
- a clear README;
- installation or execution instructions;
- the objective and scope of the experiment;
- a link to the corresponding proposal or discussion;
- known limitations;
- contribution guidelines;
- a security policy;
- sample data or test cases where appropriate.
Open development helps ensure that experiments can be independently reviewed, reproduced, extended, and reused.
Proposing an Experiment
A proposal for a GCVE Lab experiment should be published on discourse.ossbase.org and briefly describe:
- the problem or opportunity being explored;
- the expected relationship with GCVE;
- the intended users or communities;
- the proposed implementation or research approach;
- the expected output of the experiment;
- any security, privacy, legal, or interoperability considerations;
- the individuals or organisations interested in contributing.
A proposal does not need to include a complete implementation. Early ideas are welcome when they are sufficiently concrete to support discussion and experimentation.
The discussion may result in the proposal being accepted as a GCVE Lab experiment, refined before implementation, redirected to another GCVE activity, or left open for future consideration.
Joining the GCVE Lab
Contributions from the wider community are encouraged.
You can participate by publishing a proposal on discourse.ossbase.org, contributing to an existing repository, testing a prototype, opening an issue, reviewing a design, or sharing operational requirements.
The GCVE Lab is intended to be a practical collaboration space where new ideas can be tested openly before they are adopted, transformed, or discarded.
Experiment openly. Discuss collaboratively. Document the results. Improve vulnerability coordination together.