Loading

Vulnerability fields

The vulnerability fields describe information about a vulnerability that is relevant to an event.

Field Description Level
vulnerability.category The type of system or architecture that the vulnerability affects. These may be platform-specific (for example, Debian or SUSE) or general (for example, Database or Firewall). For example (https://qualysguard.qualys.com/qwebhelp/fo_portal/knowledgebase/vulnerability_categories.htm)

This field must be an array.

type: keyword

Note: This field should contain an array of values.

example: ["Firewall"]
extended
vulnerability.classification The classification of the vulnerability scoring system. For example (https://www.first.org/cvss/)

type: keyword

example: CVSS
extended
vulnerability.description The description of the vulnerability that provides additional context of the vulnerability. For example (https://cve.mitre.org/about/faqs.html#cve_entry_descriptions_created)

type: keyword

Multi-fields:

* vulnerability.description.text (type: match_only_text)

example: In macOS before 2.12.6, there is a vulnerability in the RPC...
extended
vulnerability.enumeration The type of identifier used for this vulnerability. For example (https://cve.mitre.org/about/)

type: keyword

example: CVE
extended
vulnerability.id The identification (ID) is the number portion of a vulnerability entry. It includes a unique identification number for the vulnerability. For example (https://cve.mitre.org/about/faqs.html#what_is_cve_id)

type: keyword

example: CVE-2019-00001
extended
vulnerability.reference A resource that provides additional information, context, and mitigations for the identified vulnerability.

type: keyword

example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6111
extended
vulnerability.report_id The report or scan identification number.

type: keyword

example: 20191018.0001
extended
vulnerability.scanner.vendor The name of the vulnerability scanner vendor.

type: keyword

example: Tenable
extended
vulnerability.score.base Scores can range from 0.0 to 10.0, with 10.0 being the most severe.

Base scores cover an assessment for exploitability metrics (attack vector, complexity, privileges, and user interaction), impact metrics (confidentiality, integrity, and availability), and scope. For example (https://www.first.org/cvss/specification-document)

type: float

example: 5.5
extended
vulnerability.score.environmental Scores can range from 0.0 to 10.0, with 10.0 being the most severe.

Environmental scores cover an assessment for any modified Base metrics, confidentiality, integrity, and availability requirements. For example (https://www.first.org/cvss/specification-document)

type: float

example: 5.5
extended
vulnerability.score.temporal Scores can range from 0.0 to 10.0, with 10.0 being the most severe.

Temporal scores cover an assessment for code maturity, remediation level, and confidence. For example (https://www.first.org/cvss/specification-document)

type: float
extended
vulnerability.score.version The National Vulnerability Database (NVD) provides qualitative severity rankings of "Low", "Medium", and "High" for CVSS v2.0 base score ranges in addition to the severity ratings for CVSS v3.0 as they are defined in the CVSS v3.0 specification.

CVSS is owned and managed by FIRST.Org, Inc. (FIRST), a US-based non-profit organization, whose mission is to help computer security incident response teams across the world. For example (https://nvd.nist.gov/vuln-metrics/cvss)

type: keyword

example: 2.0
extended
vulnerability.severity The severity of the vulnerability can help with metrics and internal prioritization regarding remediation. For example (https://nvd.nist.gov/vuln-metrics/cvss)

type: keyword

example: Critical
extended
vulnerability.status This field is beta and subject to change. The lifecycle state of a vulnerability finding on an asset. Use this field to distinguish between vulnerabilities that are currently present and those that have been remediated.

Integrations that consume incremental or delta APIs should map their vendor-specific status values to one of the allowed values below. Integrations that consume full-snapshot APIs (where every record represents a currently open vulnerability) should set this field to open. Full-snapshot sources never produce fixed records — fixed vulnerabilities simply stop appearing in subsequent snapshots and are eventually evicted by the transform's retention policy.

type: keyword

Important: The field value must be one of the following:

open, fixed, reopened, unknown

To learn more about when to use which value, visit the page allowed values for vulnerability.status
extended