KEV (Known Exploited Vulnerabilities) - Potential Format (BCP-07)

[hyc]

@adulau you don't preserve the CWEs info?

[adulau]

Indeed, good catch. I just updated the CISA to KEV BCP-07 script to add it:

chg: [CISA] the `cwes` array has been added to `evidence.details`

We also update the BCP-07 document to reference those fields are optional meta fields as usually the CWEs are also described in the vulnerability information as well.

Thank you!

[adulau]

Thanks for the feedback.

Do you have a reference about this? In the CISA page, it’s clearly exploited in the wild. We could add a specific field in status field.

[adulau]

Following the workshop in Luxembourg, we added a new extension to the evidence structure to facilitate the creation of KEV assertions for all publishers in the GCVE ecosystem.

@cedric Does this make sense for the implementation?

[cedric]

yes, as discussed I think it makes sense to have the possibility to store both the Vulnerability-Lookup (the origin) UUID and the GNA id. Since publishing a KEV catalogue is not reserved to GNAs.
The Vulnerability-Lookup origin UUID will be useful for the upcoming synchronization mechanism.

[adulau]

Following our discussion, I added the altId to have an array of additional identifiers.

chg: [bcp-07] `altId` added to support alternate identifier in the KEV ·...

[adulau]

• Added a new severity field
• Added a new UUID object for the GCVE ecosystem
• Added a JSON Schema to the specification

Based on the discussions about the implementation with @cedric

GCVE-BCP-07 - Known Exploited Vulnerability - KEV Assertion Format

gcve-bcp-07.pdf

[jayjacobs]

I have a top level question/concern about the format being presented here and the duplication of data. Why do you include characteristics of the vulnerability in an information element communicating exploitation activity? It duplicates information, creates extra work in both the record production, storage, validation and parsing as well as just makes the record bloated. By including the GCVE-ID in this record you should then never need to include things like the affected product or vendor, or global characteristics of the vulnerability (like the name or if it requires auth or is an RCE or the severity score of it) which should be included in the GCVE record (right?). By asking for people to generate a KEV record with those elements, you introduce the possibility of conflicting information (“GCVE record says CWE-foo but KEV says CWE-bar”, or “GCVE says it’s microsoft, but KEV record says it’s Microsoft Inc|MSFT|microsoft corp…” ).
As a general rule, when building a data product, we need to consider where the source of truth is, and with disparate sections/sources capture the same data element, we risk confusing where and what the real truth is. This also applies to the CVE record, which has several places where the same information may appear in multiple data elements.
I may be off in this feedback because I’m still coming up to speed on the building blocks of GCVE, apologies if so!

[adulau]

Welcome @jayjacobs to this discourse forum. Thank you for the feedback.

The format is not arbitrary. It is based on CSIRT use cases and on the data that is actually shared as an observation point for real-world exploitation.

As a result, most fields are optional: in the standard, a timestamp and a vulnerability identifier are technically sufficient.

So why include additional fields? The goal is not to duplicate existing vulnerability data, but to capture what is observed in the wild and to relate it to what is already known about a vulnerability. In some cases, exploitation is observed before the vulnerability itself has been formally published. Another important aspect is the ability to combine/review observations and disclosures originating from the same source.

Ultimately, the goal is to provide and facilitate the exchange of KEV information from multiple sources and to enable correlation and aggregation of those results.

The BCP is still in draft, and clarifications and updates can be made based on your feedback.

[jayjacobs]

@adulau

In some cases, exploitation is observed before the vulnerability itself has been formally published.

Apologies if this seems like it’s too deep too quick, but I have been thinking a lot about this: the primary purpose of a vulnerability database is to establish an identity (give the vulnerability a proper name that can be agreed upon). That can be a complex process and it’s something we have not done well in vulnerability databases so far, but exploitation activity is one or more events related to a vulnerability. So before we can record an event about a subject we need to define that subject. It may not be enough to record the observed characteristics and attributes during the event as a way to establish the subject, and if the subject is already defined (it has a name/ID), then we should have already established the characteristics and attributes.

I guess what I’m saying is that we (seriously, the collective “we”) need to be a lot more deliberate about establishing the identity of a vulnerability, and then very deliberate about using that identity when various assertions are made. Why wouldn’t we include the vendor, product, and RCE status when recording a CVSS vector string? Do we need to outline characteristics when publishing signatures too, or can it be just enough to say “this is a signature (or exploit event, or CVSS score) for this GCVE ID)” and not put identity-related data in multiple assertions?

[adulau]

Thanks for the question as this will most probably update the BCP-07 with the actual background of the format.

KEV and CVE (or GCVE) represent different layers in the model, and that distinction is intentional.

A vulnerability identifier (CVE/GCVE) is primarily about establishing the identity of a vulnerability something that the ecosystem can refer to consistently over time. KEV, on the other hand, is an assertion about observed exploitation activity, made by an observer at a given point in time. In an ideal world, the same actor that defines the vulnerability (for example, a vendor CNA) would also confirm exploitation, but in practice these concerns are frequently dissociated.

There are several common situations where vulnerability identity and exploitation assertions do not originate from the same place or even at the same time:

• Embargoed or restricted vulnerabilities, where exploitation is observed and tracked within a limited circle (CSIRTs, intelligence teams, trusted communities) before public disclosure or before a vendor-assigned identifier exists.

• Situations of disagreement or asymmetry of knowledge, where an observer has high-confidence evidence of exploitation while the vendor disputes impact, scope, or even the existence of the vulnerability.

• Early or partial observations, where exploitation activity is detected before a stable understanding of affected products, attack vectors, or vulnerability class has been established.

The KEV format explicitly models exploitation as an event-level assertion linked to a vulnerability identity, rather than as part of the identity itself. This reflects operational reality: exploitation is something that happens, may occur multiple times, may be observed by different parties, and may be interpreted differently as more information becomes available.

This separation already exists implicitly across today’s KEV lists, vendor advisories, and threat intelligence reports, but it is inconsistently expressed, often duplicated, and rarely machine-parseable in a coherent way. The GCVE KEV format (BCP-07) provides a structured and open way to express these assertions while anchoring them to a shared vulnerability identifier when one exists.

Importantly, KEV entries are assertions, not ground truth.

They may later be revised, withdrawn, or contradicted by other observers. Decoupling identity from assertions allows such evolution without disconnecting from the underlying vulnerability record. A vulnerability identity should remain stable even if claims about exploitation change over time.

This model also assumes that multiple assertions per vulnerability identity are normal and expected. Different organisations may publish different KEV entries, CVSS scores, or detection signatures for the same GCVE ID, reflecting different perspectives, evidence sets, or confidence levels. Centralising identity while allowing plural assertions enables this diversity in a federated model.

With respect to identity-related data (such as vendor, product, or RCE status), once a vulnerability identity is established and assigned a GCVE ID, CVE ID (or any id), that identity should be the container for stable characteristics from a vendor. Assertions such as KEV entries, CVSS vectors, or signatures should primarily reference the GCVE ID, CVE ID (or any id) and focus on what is specific to the assertion itself: context, timing, confidence, evidence, or scoring rationale. The goal is not to repeat identity-defining attributes in every assertion.

Finally, this separation is essential for machine-readability. Clear boundaries between identity and assertions enable automated correlation, reasoning, and downstream decision-making across heterogeneous data sources. GCVE KEV (BCP-07) treats exploitation knowledge as structured data, without overloading the vulnerability identity layer itself.

Example

For example, the entry at

Vulnerability-Lookup

illustrates this separation well: the underlying vulnerability was disclosed several years ago, yet the KEV assertions associated with it remain recent and are continually updated based on ongoing exploitation observed in a honeypot. Over time, as active exploitation continues to be observed, the vendor’s original phrasing of “could allow” becomes weaker in practical relevance, because the evidence shifts from theoretical potential to demonstrated exploitation activity.

[jayjacobs]

Thank you so much for your detailed response and I think I understand (and agree) with what you are saying so let me summarize:

1. The KEV record is a standalone record type
2. The exploit activity is often observed after a vulnerability identity has been established, but may be observed and recorded prior to an identity being established (i.e., there is no assigned vulnerability ID).
3. If there is an existing identity, it can be recorded in vulnerability.vulnId field in the KEV record (with more in the vulnerability.altId array).
4. If there is no existing identity or “exploitation activity is detected before a stable understanding of [the vulnerability identity] has been established,” then the KEV record should support defining the observer’s state of knowledge about the vulnerability identity. I would guess in the optional characteristics object, but also could appear in the optional evidence.details object.

Before I go down this thread more, I’m curious if my summary is correct. That does makes sense why the KEV record may want to support vulnerability-identity-like fields if that’s the case. I do think there is an huge opportunity (that goes well beyond GCVE) to define what makes up a good vulnerability identity.

A couple of other things I noticed while digging deeper:

• What if the vulnId and altId fields differ from the relationships established in the primary vulnId record? This is probably okay given that this is an “assertion”, meaning maybe we can’t treat this as ground truth? For example, what if the vulnId is associated with an altId in a KEV record, but that relationship does not exist in the primary vulnerability record? (I am thinking from an unaided machine-actionable standpoint, not an analyst at a keyboard). This also applies to other things in the characteristics section, that may different from what is recorded about the vulnerability.
• The evidence.details object is undefined and open-ended. From an automated data processing perspective, this means unknown fields and data. If the JSON object in the details varies across JSON records, this creates unparsable JSON at scale (e.g., dropping json into databricks or snowflake, etc). While technically JSON is “machine-readable” inconsistent JSON objects are challenging to be machine-parsable across records. This is fine if I am pulling up a single record in python I can visually inspect and adjust for that record, or maybe do some tests checking if some fields exist vs others, but it creates an insurmountable challenge while ingesting thousands of records to store in a tidy data format.
• this may be lack of knowledge about GCVE in general, but from the schema defines “severity” and it’s 0-100. The only time I’ve heard “severity” used is when CVSS pretends they aren’t measuring risk, but that’s 0-10. I couldn’t find any details in the KEV docs here either.

Again, thank you for your detailed response you’ve already provided and discussion!

[adulau]

Thanks a lot for taking the time to read the BCP and provide feedback.

1. Yes, the summary is correct. KEV is a standalone record type.

2. Yes, and additionally, there are cases where an identifier has already been assigned but is not yet publicly disclosed (e.g., embargoed vulnerabilities).

3. vulnerability.vulnId represents the primary identifier, while vulnerability.altId contains synonymous identifiers referring to the same vulnerability. If exploitation activity relates to a different vulnerability, it should be expressed in a separate KEV record.

4. Correct. The evidence.details field primarily acts as a container for source-specific or legacy KEV data, ensuring that original information can be preserved when ingesting or converting existing KEV formats.

Additional clarifications:

• vulnId and altId are strictly synonyms referring to the same vulnerability identity. A KEV record always applies to a single vulnerability. Any relationship modeling (e.g., dependency, causality, aggregation) is handled in the vulnerability record itself, as described in the BCP-05 relationships field.

• evidence.details is intentionally flexible and is used to carry original data or source-specific attributes that are not yet standardized. This follows a similar design pattern to the meta fields in MISP. If common structures emerge over time, these may be formalized later as an annex or extension within BCP-07.

• The severity field reflects the severity inferred from the exploitation assertion itself, not an abstract or vendor-defined vulnerability score. For example, a honeypot observation resulting in full system compromise would justify a high severity value. This distinction may benefit from clearer wording in the BCP document.

[adulau]

@adulau

The severity field reflects the severity inferred from the exploitation assertion itself, not an abstract or vendor-defined vulnerability score. For example, a honeypot observation resulting in full system compromise would justify a high severity value. This distinction may benefit from clearer wording in the BCP document.

I updated the BCP-07 draft based on the question and feedback provided.

chg: [BCP-07] clarification about the severity · gcve-eu/gcve.eu@a0bf395

[adulau]

GCVE‑BCP‑07 ‑ Known Exploited Vulnerability ‑ KEV Assertion Format version 1.9 published and leaving the draft status.

GCVE-BCP-07 - Known Exploited Vulnerability - KEV Assertion Format

gcve-bcp-07.pdf

We are open to update or changes but we suppose the format won’t change fundamentally in the next iterations.

[adulau]

Following a CNW meeting in the CVD working group, a question was raised concerning the model for the confidence level. Here is a small proposal which could be included in BCP-07 at some point:

Confidence	Label	Meaning (confidence in this evidence item)	Typical exploitation evidence examples
0.0	None	No usable evidence or placeholder only	Empty claim; unresolved rumor with no traceability
0.1	Extremely low	Unreliable and uncorroborated; major gaps	Single anonymous post; vague claim of exploitation
0.2	Very low	Weak signal; high chance of misattribution	Ambiguous scanning activity; noisy or indirect telemetry
0.3	Low	Plausible but thin; limited traceability	Single non-authoritative report; partial indicators without artifacts
0.4	Low–moderate	Some structure and traceability; still uncertain	Reputable researcher hint with limited technical detail
0.5	Moderate	Credible but not fully validated; alternative explanations remain	Multiple consistent reports; exploitation attempts seen but success unclear
0.6	Moderate–high	Good evidence with reasonable verification	Honeypot telemetry showing exploit-like behavior; strong IOCs
0.7	High	Strong and fairly direct evidence; limited uncertainty	Incident response report with logs/artifacts consistent with exploitation
0.8	Very high	Direct evidence or strong multi-source corroboration	Forensics confirming exploit path; authoritative confirmation of in-the-wild exploitation
0.9	Near-certain	Highly direct, well-attributed, well-corroborated	Confirmed compromise with clear exploit attribution across independent sources
1.0	Certain	Practically proven; no plausible alternative explanation	Deterministic proof (e.g., full packet/log capture) tying exploitation to the vulnerability

[cedric]

Various information related to the current implementation of BCP-07 for the new comers.

Definition of the BCP (details, JSON schema, etc.): GCVE-BCP-07 - Known Exploited Vulnerability - KEV Assertion Format – GCVE - Global CVE Allocation System

CISA KEV imported in Vulnerabiliy-Lookup

Available here.

Getting the data via the API:

$ curl -s https://vulnerability.circl.lu/api/kev/?vulnerability_lookup_origin=405284c2-e461-4670-8979-7fd2c9755a60 | jq .

.
.
.    {
      "uuid": "8e46e728-d57d-4715-90f4-1d5272088e9e",
      "vulnerability": {
        "vulnId": "CVE-2019-0863",
        "altId": []
      },
      "gcve": {
        "origin_uuid": "405284c2-e461-4670-8979-7fd2c9755a60",
        "object_uuid": "8e46e728-d57d-4715-90f4-1d5272088e9e"
      },
      "status": {
        "exploited": true,
        "status_reason": "confirmed",
        "status_updated_at": "2021-11-03T00:00:00+00:00"
      },
      "characteristics": {},
      "timestamps": {
        "asserted_at": "2021-11-03T00:00:00Z",
        "recorded_at": "2026-02-02T12:25:39Z",
        "first_seen_at": "2021-11-03T00:00:00Z"
      },
      "scope": {
        "notes": "KEV entry: Microsoft Windows Error Reporting (WER) Privilege Escalation Vulnerability | Affected: Microsoft / Windows | Description: Microsoft Windows Error Reporting (WER) contains a privilege escalation vulnerability due to the way it handles files, allowing for code execution in kernel mode. | Required action: Apply updates per vendor instructions. | Due date: 2022-05-03 | Known ransomware campaign use (KEV): Unknown | Notes (KEV): https://nvd.nist.gov/vuln/detail/CVE-2019-0863"
      },
      "evidence": [
        {
          "type": "vendor_report",
          "source": "cisa-kev",
          "signal": "successful_exploitation",
          "confidence": 0.8,
          "details": {
            "cwes": [],
            "feed": "CISA Known Exploited Vulnerabilities Catalog",
            "product": "Windows",
            "due_date": "2022-05-03",
            "date_added": "2021-11-03",
            "vendorProject": "Microsoft",
            "vulnerabilityName": "Microsoft Windows Error Reporting (WER) Privilege Escalation Vulnerability",
            "knownRansomwareCampaignUse": "Unknown"
          }
        }
      ],
      "references": [
        {
          "id": "CVE-2019-0863",
          "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2019-0863"
        }
      ]
    }
  ]
}

It’s possible to get all the catalog as ndjson, here.

ENISA KEV Vulnerability-Lookup

Available here. Same principle for the API.

Tool used to import CISA/ENISA KEV

Since both CISA and ENISA are not yet using BCP-07, we have created a tool to import these catalogs. Available here.

We are currently working on the synchronization between Vulnerability-Lookup instances. The PR is here.
This feature will enable synchronization between instances, allowing a local instance to pull objects (bundles, comments, sightings, KEV entries) from configured remote Vulnerability-Lookup instances via their public APIs.

Small showcase:

The release is almost ready. Then it will be possible to synchronize KEV Catalogs compliant to BCP-07 without having to use the previously mentioned conversion tool.

JSON Validator

We have a JSON validator, here for BCP-07 (and BCP-05).

# Validate CIRCL KEV
python gcve_bcp07_validate.py --schema website/web/static/schemas/GCVE/gcve-bcp-07.schema.json --url https://vulnerability.circl.lu/known-exploited-vulnerabilities-catalog/export.ndjson

# Validate ENISA KEV
python gcve_bcp07_validate.py --schema website/web/static/schemas/GCVE/gcve-bcp-07.schema.json --url https://vulnerability.circl.lu/known-exploited-vulnerabilities-catalog/export.ndjson?catagog_uuid=405284c2-e461-4670-8979-7fd2c9755a60

[adulau]

evidence[].confidence level calculation has been added in the standard specification.

gcve-bcp-07.pdf

[rjb4standards]

Please consider adding “mitigation steps” to help consumers protect themselves until a patch is available. This could be a URL to a document describing mitigation steps.

[adulau]

Thanks for joining the discussions.

That’s a great idea. We will the default meta with potential fields such as mitigation/remediation steps.