VULNARCHIVE and GNA 1988: Automated Vulnerability Identifier Allocation in a Federated GCVE Ecosystem

One of the core ideas behind GCVE is that vulnerability identification does not need to depend on a single central authority. Independent GCVE Numbering Authorities (GNAs) can operate their own processes, allocation policies and publication infrastructure while remaining interoperable with the wider GCVE ecosystem.

VULNARCHIVE is a new example of this model in practice. It has been assigned GNA 1988 and can automatically allocate identifiers in the form:

1

GCVE-1988-YEAR-ID

From vulnerability archives to GCVE identifiers

VULNARCHIVE is an open-source project designed to preserve and process vulnerability information published on security mailing lists.

Its pipeline can ingest mailing-list messages, preserve the original evidence and provenance, extract structured vulnerability information, compare the information with known vulnerabilities, and determine whether the entry should be linked to an existing identifier or published as a new record.

When the publication policy determines that a new identifier is required, VULNARCHIVE can automatically allocate and publish a GNA 1988 identifier.

Automatic allocation does not mean blind allocation. The system separates evidence collection, matching, review and publication, allowing uncertain cases to be reviewed while well-defined cases can flow through the pipeline automatically.

Published records can then become visible throughout the GCVE ecosystem, including via Vulnerability-Lookup instances.

Federation in practice

VULNARCHIVE illustrates an important property of GCVE: new vulnerability producers can join the ecosystem without depending on a central identifier-allocation service.

A GNA can define an allocation process adapted to its own use case, operate its own infrastructure and publish its own vulnerability records. GCVE Best Current Practices provide the common mechanisms needed for discovery, publication and interoperability between these independent producers.

This means GCVE can accommodate very different approaches to vulnerability identification: vendors, CSIRTs, open-source communities, research projects, automated analysis pipelines, vulnerability archives, or models that we have not considered yet.

The VULNARCHIVE implementation is itself open source:

• VULNARCHIVE service: https://vuln.freearchive.org/
• Source code: https://github.com/rommelfs/VULNARCHIVE
• GNA: 1988
• Recent GNA 1988 records: https://vulnerability.circl.lu/recent?source=gna-1988

What could your GNA do?

The federated model is intentionally designed to leave room for experimentation.

We are particularly interested in hearing about specific, unusual or creative GNA use cases. If you have a vulnerability publication workflow, dataset, research project, community or automated process that could benefit from its own identifier space, we would be very happy to discuss how it could fit into the GCVE ecosystem.

Federation becomes useful when different communities can build the vulnerability identification processes they actually need — while still being able to exchange and correlate the resulting information.