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

GCVE
33

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.