[FEATURE]: EPSS Score on Vulnerability model

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/

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

Its dynamic and subject to change every 24 hours.
EPSS is not versioned.
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.

@stevespringett

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?

@thiago-gitlab

@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.

@thiago-gitlab,

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.

KEV started as as a US-based project by CISA, but the european ENISA has started publishing a (much smaller, so far) catalog as well.

I think that the ability to enrich a Vulnerability entry with exploitability properties like EPSS and KEV is really important.
If it is possible, I think that this would be a good area to allow for dynamic extendability for handling new standard that come around.

Now that CycloneDX 2.0 will be JSON only and its primary format for sharing will be over API's, it makes sense to add EPSS support. Pull requests are encouraged. But we need to capture not just the scores, but the timestamps as well. Possibley some other metadata.

KEV was mentioned multiple times. This ticket doesn't address KEV. If people want KEV, I would suggest opening another ticket specific to it.

@stevespringett

I'd like to create a pull request for this. Since it's my first time here: Is there a contribution guideline somewhere @stevespringett ?

KEV was mentioned multiple times. This ticket doesn't address KEV. If people want KEV, I would suggest opening another ticket specific to it.

Done. See #890

@mtausig

@mtausig A PR adding EPSS would be fine. However, you'd have to make it against the 2.0-dev branch, specifically on the vulnerability model.

For reference, Grype is already adding an EPSS value to their Cylclone-DX output. They are simply using the ratings property of a vulnerability:

"vulnerabilities": [
    {
      "bom-ref": "urn:uuid:a84d2d53-e833-428d-b673-b56ee0798197",
      "id": "CVE-2024-56433",
      "source": {
        "name": "debian-distro-debian-13",
        "url": "https://security-tracker.debian.org/tracker/CVE-2024-56433"
      },
      "references": [
        {
          "id": "CVE-2024-56433",
          "source": {
            "name": "debian-distro-debian-13",
            "url": "https://security-tracker.debian.org/tracker/CVE-2024-56433"
          }
        }
      ],
      "ratings": [
        {
          "score": 3.6,
          "severity": "low",
          "method": "CVSSv31",
          "vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N"
        },
        {
          "source": {
            "name": "FIRST",
            "url": "https://www.first.org/epss/"
          },
          "score": 0.04509,
          "method": "other"
        }
      ],

RFC notice sent on 18 September 2026.
RFC period ends on 16 October 2026.

Navigation Menu

Repository navigation

[FEATURE]: EPSS Score on Vulnerability model #481

Describe the feature

Possible solutions

Alternatives

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: EPSS Score on Vulnerability model #481

Description

Describe the feature

Possible solutions

Alternatives

Additional context

Activity

stevespringett commented on Jun 12, 2024

thiago-gitlab commented on Jun 13, 2024

stevespringett commented on Jun 13, 2024

mtausig commented on Feb 26, 2026

mtausig commented on Feb 26, 2026

stevespringett commented on Feb 27, 2026

mtausig commented on Mar 20, 2026

mtausig commented on Mar 20, 2026

stevespringett commented on Mar 28, 2026

mtausig commented on Apr 17, 2026

jkowalleck commented on Sep 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions