Tootfinder

I love to see clever use of the @… ecosystem and @… did a cool GNA which is automatically creating GCVE records and structured security advisories from full-disclosure mailing-list or alike:
🔗 Project details #gcve #cve #vulnerability #vulnerability #opensource #cybersecurity

Pretty cool idea from @… - a bot to analyse fucked up references from the CVE records.
@…
Maybe we could imagine an archive bot at the same time to ensure that the references don't get lost. Just like archive.org or similar. Maybe something for @… to look into.
#cve #vulnerability #gcve

The GCVE Lab is an open space for experimenting with new ideas, tools, formats, and services related to the Global CVE Allocation System initiative.
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.
Open to comments/ideas.
#gcve #cve #cybersecurity
https://discourse.ossbase.org/t/gcve-lab-proposal/1117
https://gcve.eu
@… @…

From a research paper to running open-source code in just a few days.
We (with @…) have been experimenting in Vulnerability-Lookup with the concept of Local Exploit Hazard, based on the recent research paper “Modeling Local Exploit Hazard — A Bayesian Framework for Quantifying Exploit Risk and Operational Efficiency” by Stephen Shaffer and Laura Cristiana Voicu.
The idea addresses an important question in vulnerability management:
Not simply “How dangerous is this vulnerability globally?” but “How much exploitation risk does this vulnerability represent in my environment?”
Instead of introducing yet another static vulnerability score, the model starts from exploit likelihood such as EPSS and combines it with local security controls, CVSS attack vectors, vulnerability age and KEV policy to estimate an exploitation hazard.
We implemented an experimental version in Vulnerability-Lookup and connected it directly to operational workflows.
For the full details: #cve #gcve #vulnerabilitymanagement #vulnerability #opensource #opendata
@…

The @… BCP-07 KEV format has been updated to allow the Withdrawn and Reasserted KEV Assertions.
This allows to support case like CVE-2026-69836 .
🔗 #cve #gcve #kev #cybersecurity #vulnerabilitymanagement #vulnerability

Working on a first super beta implementation of @… BCP-11 "Community-Proposed Updates to Existing CVE Records"
To validate if the BCP-11 can be published.
#cve #gcve #vulnerability #opensource #opendata
Discussions https://discourse.ossbase.org/t/gcve-bcp-11-community-proposed-updates-to-existing-cve-records/1110

We did some improvements in GCVE extension - GCVE BCP-05-X-03 - Vulnerability Handling and Disclosure Timeline.
We also review the alignment and interoperability with CSAF 2.1.
Now there is a new object field entities to represent the entities in the handling timeline.
🔗 GCVE BCP-05-X-03 #csaf #gcve #cve #vulnerabilityManagement #vulnerability #openstandard #cra

We are pleased to announce the publication of GCVE BCP-07 version 3.0, extending the Known Exploited Vulnerability (KEV) Assertion Format with support for No Known Exploitable Vulnerability (NKEV) assessments. BCP-07 was initially designed to provide a structured, open and federated way to express exploitation assertions, including who made the assertion, when exploitation was observed or declared, what evidence supports it, and with what level of confidence. Version 3.0 keeps this KEV model intact while adding a complementary, product-oriented mechanism to assess whether known vulnerabilities are exploitable in a specific product context.
The distinction between KEV and NKEV is fundamental. A KEV assertion states that a producer has observed or otherwise asserts exploitation of a vulnerability. An NKEV assessment approaches the problem from a different direction: a specific product or product version is evaluated against explicitly identified vulnerability knowledge sources to determine whether known vulnerabilities are exploitable in the assessed context. The assessment takes into account the product, its configuration, the defined assessment scope, the knowledge sources consulted and a precise knowledge cut-off time. Its result can be pass, fail or inconclusive, making both the outcome and its limitations explicitly machine-readable.
🔗 #kev #bcp #gcve #cve #nkev #vulnerabilityManagement #cybersecurity #openstandard

GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference
We are pleased to announce a GCVE workshop on 22 September 2026, from 14:00 to 18:00, hosted at the CIRCL/LHC offices in Luxembourg, just before the VulnOpticon conference.
The workshop is free and open to everyone, but registration is required.
🔗 #cve #gcve #luxembourg #cybersecurity #vulnerabilitymanagement

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. It's already live in our open-source tool-set.
🔗 Blog post #opensource #openstandard #cve #gcve #cra #cybersecurity #vulnerability

GCVE BCP-07, the Known Exploited Vulnerability (KEV) Assertion Format, has been updated to version 2.2. A key addition is the formalisation of the GCVE KEV Directory, a simple machine-readable directory allowing organisations to announce where their KEV catalogues and exploitation assertions are published.
We particularly encourage software and hardware vendors to publish their own KEV catalogues. Vendors are often in the best position to confirm exploitation affecting their products, and publishing this information in a machine-readable form can significantly improve vulnerability prioritisation for users, CSIRTs and vulnerability-management platforms.
For more details #GCVE #GNA #vulnerabilityintelligence #opensource #KEV #cybersecurity
@…

We were very happy to participate in Vulnopticon 2026 and to meet so many people interested in vulnerability identification, publication, coordination, and management.
The discussions during the conference and just as importantly, the conversations around and outside the formal sessions brought a lot of useful feedback, new ideas, questions, and potential directions for GCVE. These exchanges are especially valuable for a project such as GCVE, where openness, federation, interoperability, and experimentation are at the core of the initiative.
🔗 #cve #gcve #vulnerabilityManagement #vulnerability #opensource

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.
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.
#gcve #cve #vulnerability #vulnerabilitymanagement
https://gcve.eu/2026/09/20/vulnarchive-and-gna-1988-automated-vulnerability-identifier-allocation-in-a-federated-gcve-ecosystem/
@…

Sightings have long been a major topic of discussion in the CTI community, particularly in the field of vulnerability management. We have now published a GCVE BCP to standardise the format that has been implemented, tested and used operationally in Vulnerability-Lookup for some time.
Thanks to everyone (Cédric Bonhomme, Éireann Leverett, Andras Iklody, Sami Mokaddem and many more) who participated in discussions and worked on the implementation details of sightings over the past several years. These efforts had a strong focus on practical implementation, while BCP-12 specifically addresses sightings in the context of vulnerability management.
BCP-12 is still a draft open for review, but it already provides a strong foundation for existing implementations.
#cve #cra #gcve #vulnerabilitymanagement #cybersecurity #openstandard

A new version of the BCP-11 "Community Contribution Fragments for Existing CVE Records" proposal has been published.
#gcve #cve #cybersecurity #vulnerabilitymanagement
@…

If you are curious about (nearly) everything we did the past months at the GCVE.eu initiative:
#gcve #cve #vulnerability #vulnerabilitymanagement #cra #cybersecurity #openstandard #opensource

Tired of drafting vulnerability advisories from Git patches?
We developed patch2vuln to facilitate the creation of security advisories directly from Git patches.
With a single command, patch2vuln can assist an analyst throughout the advisory creation process: analyzing the patch, drafting the vulnerability title and description, identifying CWE and CAPEC mappings, proposing a CVSS v4.0 vector, extracting affected versions, remediation information and credits, and generating a structured CVE/GCVE record.
The analysis can run entirely locally using an LLM via Ollama, while deterministic processing is used for elements such as CVSS scoring and structured output validation.
The goal is not to replace the security analyst, but to remove much of the repetitive work and provide a solid structured draft for human review and publication.
patch2vuln v1.0 is now available as open-source software under the @… Lab initiative.
#VulnerabilityManagement #CVD #CVE #GCVE #OpenSource #CyberSecurity #AI

I spent many hours in vulnogram today and to be honest. I'm glad that a colleague started to work on a replacement called vulniverse. Still early beta but it's promising.
#opensource #vulniverse #cybersecurity #cve #gcve
work in progress https://github.com/vulnerability-lookup/vulniverse

vulnerability-lookup 6.0 will be released this week with many (really, many!) new features.
One of the smaller, but important, additions is support for multiple SSVC views alongside CVSS. When SSVC information is available from an ADP (such as CISA) , or from additional sources such as GCVE, it is now displayed by default.
This allows users to more easily compare the different severity and prioritization assessments associated with a vulnerability.
The CIRCL vulnerability-lookup instance is running the pre-release of 6.0 -
#cve #gcve #opensource #vulnerabilitylookup #opendata #vulnerabilitymanagement #cyberecurity #ssvc
@…
@…