[FEATURE]: EPSS Score on Vulnerability model

[mcombuechen]

Describe the feature

Vulnerabilities can have an EPSS score attached to them. This describes the probability of a vulnerability being exploited. As of spec version 1.6, there is no clear way to attach this to a CycloneDX Vulnerability.

A vulnerability does have a slot for ratings, but it is not clear whether it can be used to include the EPSS, which consists of two values (the probability score itself, a percentile). It might be worth introducing a new slot for this vulnerability attribute.

Possible solutions

Shooting from the hip.

type Vulnerability {
  bom-ref string
  // ...
  epss    EpssScore
}

type EpssScore {
  probability float
  percentile  float
}

Alternatives

Getting it into the ratings, but it does not really fit the "severity" category that ratings was intended for.

Additional context

Support for EPSS was added to SPDX 3.0: https://spdx.github.io/spdx-spec/v3.0/model/Security/Classes/EpssVulnAssessmentRelationship/

[stevespringett]

Thanks for the suggestion. There are a few challenges with supporting EPSS in any specification today.

1. Its dynamic and subject to change every 24 hours.
2. EPSS is not versioned.
3. Updates to the EPSS model occur with little to no notice to adopters.

Because EPSS is not versioned, and the scores can change whenever changes to the model occur, it will be important to capture the timestamp of when the EPSS was generated. It appears that SPDX v3.0 does not have support for this. They have a publishedTime, but that is in reference to the vulnerability, not when when the EPSS was calculated.

Another potential challenge is the use of two fields today (probability and percentile). Since EPSS is not versioned, there is nothing prohibiting the EPSS team from adding or removing other fields, making any standard that supports it incompatible with the current EPSS specification.

Adding an unversioned pseudo standard to CycloneDX which is pursuing both Ecma and ISO standardization will be problematic. It will likely (and rightfully) be questioned.

If we can get the EPSS team to formally version EPSS, then that would reduce possible issues with CycloneDX adoption and standardization efforts.

We may want to ping Sasha Romanosky, or one of the other EPSS chairs.

[thiago-gitlab]

Thanks for the insightful response, @stevespringett. I've asked about KEV in the Slack thread, but I figured I should do it here since it's more discoverable by others.

Have you got any thoughts on supporting KEV in CDX?

[stevespringett]

@thiago-gitlab,

KEV defines the following properties:	property	description
cveID	The CVE ID of the vulnerability in the format CVE-YYYY-NNNN, note that the number portion can have more than 4 digits
vendorProject	The vendor or project name for the vulnerability
product	The vulnerability product
vulnerabilityName	The name of the vulnerability
dateAdded	The date the vulnerability was added to the catalog in the format YYYY-MM-DD
shortDescription	A short description of the vulnerability
requiredAction	The required action to address the vulnerability
dueDate	The date the required action is due in the format YYYY-MM-DD
knownRansomwareCampaignUse	'Known' if this vulnerability is known to have been leveraged as part of a ransomware campaign; 'Unknown' if CISA lacks confirmation that the vulnerability has been utilized for ransomware
notes	Any additional notes about the vulnerability

knownRansomwareCampaignUse is interesting but limited to only ransomware, which is unfortunate. The requiredAction and dueDate are U.S. Government specific. In fact, KEV itself is U.S. specific. If CycloneDX supported a catalogue of known exploitable vulnerabilities, it would need to do so in a more inclusive way. If you're interested in that, please create a new ticket and we can discuss there.