Add support for the CISA Known Exploited Vulnerabilities (KEV) catalog

[troymarshall]

Current Behavior

The current version of Dependency-Track provides support for several open data sources, including the EPSS. It does not currently ingest data from the CISA KEV. Inclusion in the CISA KEV triggers vulnerability remediation timeline requirements for federal agencies as set forth in CISA Binding Operational Directive (BOD) 22-01. Specifically, the BOD 22-01 specifies:

"Remediate each vulnerability according to the timelines set forth in the CISA-managed vulnerability catalog. The catalog will list exploited vulnerabilities that carry significant risk to the federal enterprise with the requirement to remediate within 6 months for vulnerabilities with a Common Vulnerabilities and Exposures (CVE) ID assigned prior to 2021 and within two weeks for all other vulnerabilities. These default timelines may be adjusted in the case of grave risk to the Federal Enterprise."outlined in

Proposed Behavior

I am proposing ingesting the CISA KEV database available at https://www.cisa.gov/known-exploited-vulnerabilities-catalog and using this data to enrich the existing exploitability data such as EPSS also to include the date added to KEV and the remediation due date. Once the data is included, I would request a policy to identify vulnerabilities outside of the KEV remediation timeline.

While the vulnerability due date is currently only applicable to US federal agencies, I could foresee a time when the remediation timeline becomes a requirement for federal contractors.

I had a brief exchange with Steve S. on this in the OWASP Slack channel, and he requested I include a note about building this in a way that isn't specific to the USA. I have spent some time researching international equivalents to the CISA KEV but have not found any. I have found several commercial tools supporting KEV, including: https://www.tenable.com/sc-dashboards/dhs-cisa-binding-operational-directive-22-01 https://nucleussec.com/cisa-kev/ https://www.paloaltonetworks.com/blog/security-operations/cortex-xpanse-identify-cisa-kev/ https://blog.qualys.com/product-tech/2022/02/22/managing-cisa-known-exploited-vulnerabilities-with-qualys-vmdr

Steve's note from our Slack discussion: "I wonder if other countries have similar things. I'd hate to make it U.S. specific. I'd rather find a non-geographic way to implement this while still being able to use KEV as one of the possible feeds. "

Checklist

• [X] I have read and understand the contributing guidelines
• [X] I have checked the existing issues for whether this enhancement was already requested

[AppSecAmael]

up :)

[msymons]

A few observations...

1. I cannot find the reference right now, but it has been mentioned that DT should not be too "USA-centric" . KEV might be managed by CISA ("America's Cyber Defense Agency") but it is referenced by security professionals around the world. I know of at least one company in Europe are looking at integrating KEV into MISP feeds.
2. I believe that KEV support in DT would be "good for marketing". Another demonstration of what is possible...
3. KEV is referenced by 2023 CWE Top 25 Most Dangerous Software Weaknesses. For example, the number 1 Weakness (CWE-787) is listed as "CVEs in KEV: 70".
4. There are criticisms of KEV: EPSS and gaps in the CISA KEV: Real-world examples. However, DT does support EPSS.

[stevespringett]

@msymons IMO, the implementation of KEV in DT should not be CISA specific. It should be designed in a way where other trailing indicators of known exploitable vulnerabilities can be supported in the future as well.

Known vulns are a trailing indicator of risk. KEV takes this much further, so it's not an overly useful metric to use for identifying potential and future risk. However, there are some industries, such as medical devices and OT, where devices have a long operational life and large gaps (if any) in maintenance and updates. For these industries, support for KEV is increasingly important.

The FDA today released Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions which includes the following text:

... Furthermore, vulnerabilities identified in Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities Catalog40 should be designed out of the device, as they are already being exploited and expose the medical device system and users to the risk.

To help medical device makers identify known exploitable vulnerabilities, I think DT should add support for KEV in 4.10. @nscuro @melba-lopez, if you agree, could you add the 4.10 milestone please?

[nscuro]

IMO, the implementation of KEV in DT should not be CISA specific. It should be designed in a way where other trailing indicators of known exploitable vulnerabilities can be supported in the future as well.

Agreed, but few questions:

• Are we aware of alternative feeds like KEV, possibly from commercial vendors?
• Are we expecting these trailing indicators to always be "is included in a list", or could there be more intricate metrics?

Also, in addition to the original ER to process "date added" and "due date", and exposing that in policies, what else should this feature include?

• Do we want inclusion in KEV to have an impact on the risk scoring?
• How about discoverability? i.e. do we want a UI view that answers "how many findings in my portfolio / project X are in KEV"?

---

Note for implementation: OVP has a client for KEV retrieval.

[stevespringett]

Are we aware of alternative feeds like KEV, possibly from commercial vendors?

The EU (under NIS2) will have an early warning system - likely private initially. The EU, under the CRA, will have their own vulnerability database (to be managed by ENISA). It would not surprise me if that database includes exploitability details. So while I do not know of another one as of today, I can certainly see this happening in the near future.

Are we expecting these trailing indicators to always be "is included in a list", or could there be more intricate metrics?

I think timeframes in which a vulnerability was first known to be exploited across different versions of an affected component is likely the most common use case. I don't think KEV, in its current form, is that granular.

Do we want inclusion in KEV to have an impact on the risk scoring?

My assumption, is that the EPSS score for this would be >0.9 in the event something is known to be exploitable. The EPSS score should be taken into consideration for the risk score, but I don't think adding KEV on top of that provides much value. However, I think it would be good to investigate whether or not EPSS scores ever decrease over time. Say a vulnerability is no longer being actively exploited because only a fraction of systems still use a vulnerable version. Advasaries likely have moved on. In this case, I don't know what would happen to the EPSS score. Does it maintain its peak value? Or does it decrease based on lack of active exploits in the wild? If is decreases, then adding KEV as part of the risk score makes sense. If EPSS maintains its peak value, then adding KEV to risk doesn't make much sense.

How about discoverability? i.e. do we want a UI view that answers "how many findings in my portfolio / project X are in KEV"?

Yes. That would be a great query to have IMO.

[nscuro]

However, I think it would be good to investigate whether or not EPSS scores ever decrease over time

Challenge accepted!

I pulled all datasets over the entire time frame of EPSS being available into a SQLite database, and did some data crunching. Yes, a decrease in score happens quite frequently. Quite significant drops from one day to another as well.

Below a snippet of the data, showing day-over-day changes in the score, sorted ascendingly by change.

Verifiable via EPSS API, e.g. CVE-2020-13158 dropped from 0.967910000 to 0.018220000 between 2023-09-21 and 2023-09-23: https://api.first.org/data/v1/epss?cve=CVE-2020-13158&scope=time-series

Overall I can see 259871 occurrences of scores decreasing day-over-day.

[stevespringett]

Nice work @nscuro. In that case, then yes, I think it makes sense to add the presence of KEV to the risk score.

[stevespringett]

• Additional note. CVEs can not only be added to KEV, but removed as well. See https://www.securityweek.com/cisa-reverses-course-on-malicious-exploitation-of-video-conferencing-device-flaws/ for a recent occurrence of that. The logic should support this use case.

[eastmadc]

@nscuro - I thought of this conversation and your work when I stumbled upon work from Patrick Garrity from Nucleus in his LinkedIn Post. Garrity put together these Sankey diagrams mapping the National Institute of Standards and Technology (NIST) National Vulnerability Database(NVD), Common Vulnerability Scoring System (CVSS), Exploit Prediction Scoring System (EPSS), Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities Catalog and GreyNoise Intelligence.

[nscuro]

Seems there's now at least one additional KEV datasource, provided by VulnCheck: https://vulncheck.com/kev

Claims to be free, but requires registration. Will need to investigate whether we can integrate with it.

I haven't yet registered, so if anyone sees this and is willing to go through the registration process, please feel free to share your findings here!

[setchy]

The terms and conditions of using VulnCheck KEV, it's data in whole or in part, either publicly or in cybersecurity product or service, requires prominent attribution to VulnCheck. However, other than this requirement, no additional costs are required.

If you're interested in including VulnCheck KEV data in whole or in part, in one or more cybersecurity products at your company, please reach out to VulnCheck at [email protected] to receive additional details on the attribution requiments. Including VulnCheck KEV in your product is meant to be free and not incur additional costs, we simply ask for prominent attribution.

[nscuro]

Thanks @setchy, that looks similar to what the NVD requires when using their API.

Prominent attribution should not be a problem, especially given that this would be an opt-in integration that users will have to enable in their own instance.

[setchy]

We switched one of our internal processes from CISA KEV to VulnCheck KEV and have found that to be beneficial

[italvi]

@nscuro another interesting thing could be inthewild.io

[msymons]

Changed milestone to v4.12 in order that v4.11 to allow for implementation to be something that caters to KEV and Vulncheck... and other possible data sources as well.

[topiga]

The VulnCheck API seems to have other features, but I think it requires a paid licence (or at least that's what the API anwers). It would be nice to have these feature too (like VulnCheck XDB, which has a DB for source-available POCs) in Dependency Track, although I don't know how it would be feasible without this alleged paid subscription.

[nscuro]

The VulnCheck KEV API merely requires a free account, no paid license as per https://docs.vulncheck.com/community/vulncheck-kev/faq#how-do-i-gain-access-to-vulncheck-kev

[msymons]

Moving to 4.13 milestone. This is a large piece of work and needs to be done properly... and not hold up the release of all the good stuff that is already implemented for 4.12

[patrickmgarrity]

I work at Vulncheck and manage our community edition. I noticed a few questions and thought I would proactively hop in.

1. Yes it is free to use with attribution. Simply refer to findings as VulnCheck KEV similar to CISA KEV.
2. It is fully inclusive of CISA KEV
3. It includes references, identification when a CVE is used in a ransomware campaign, Exploit links from VulnCheck XDB: https://vulncheck.com/xdb/.
4. If you need a briefing on details or help with implementation, just ask email (pgarrity at vulncheck dot com)

Documentation Details API Schema: https://docs.vulncheck.com/community/vulncheck-kev/schema Attribution: https://docs.vulncheck.com/community/vulncheck-kev/attribution

[karsten-klein]

Hmm. I just wanted to get hold of an API key and there are solid Terms of Use that can first be seen after a login is requested. Could you share a link, such that many eyes can have a look and comment?

[karsten-klein]

E.g.: Section 7 contains a limitation where I'm not sure whether DependencyTrack or other aggregation and monitoring tools would be allowed to use VulnCheck. Section 12 limits free usage (including also the community version) to 30 days (if not otherwise determined)

[patrickmgarrity]

Karsten, We provide the community edition to 1000's of security teams/tools and encourage it's use to provide better visibility into vulnerabilities and exploitation. The only ask we make of customers using VulnCheck Community within a product is prominent attribution when using VulnCheck KEV or VulnCheck CPE.

The terms are pretty boiler plate for a free service and can be found here: https://vulncheck.com/terms-accept

• Patrick