blog

CVE API is changing. What are the new feature for vulnerability management and application security?

CVE, CVSS, New CVE API, NVD New API format, how to query NVD, How to get CVSS using API

CVE API is being used by tons of vulnerability management programs and application security programs to investigate whether a piece of software or library is vulnerable to a in preparation for CVSS v4/ CVSS4m and adding CISA KEV. The new API is changing or at least their JSON representations, as provided by two key data providers: the CVE Project and NIST’s NVD.

What is changing? Everything… but not quite.

The new formats are not backwards compatible with the previous vulnerability format. If you leverage this API for CVSS calculation, vulnerability management and application security program you might want to consider the changes. In other words, any parser that processes data provided by the earlier formats for CVE and Vulnerabilities would not work with the new format without modification. However, they capture the same information records as before, so their structure and contents would be very easily recognizable by anyone familiar with the old formats.

From a practical point of view, any script or software currently dealing with these data formats would have to be updated to parse and handle the new ones.

We are looking at two independent but connected changes…

CVE JSON version 5

As described here, the old (version 4) format and related downloads will be deprecated on or before Dec 31st 2023.

If you are currently working with V4 files for your vulnerability and vulnerability management program, you need to start looking to migrate your scripts and code to the new format. The CVE Project provides access to CVE data with the new format in its repository. If you are leveraging this API for CVSS calculation, vulnerability management and application security program, you might want to consider the changes

What is the new CVE API format?

Vulnerability grouping:

The bulk of the CVE data is now placed within the top-level containers array, with the cna container capturing the “canonical” information from the CVE Numbering Authority (CNA) that originally assigned the CVE ID. This container is the only one required and always present.

The other containers live inside the adp array (itself inside containers), with each object in the array holding CVE details from a different Authorized Data Publisher (ADP) participating in the CVE program. Each object inside the “adp” array mirrors the structure of the “cna” container.

The image below shows the top-level “containers” element, with its “cna” (object, required) and “adp” (array, optional) elements.

cve, cvss, application security, new CVE API, CVE v5 Json, vulnerability management, CNA

Affected vs Affects (CPEs all the way)

When describing the products affected by each CVE, the new format has replaced the affects object with the affected array.

This seems like a small change on the face of it, but it hides an important shift: inside “affected” all vendors and products are now described through their CPE name.

CPE can be software you extract from vulnerability scanners, in your vulnerability management program or libraries for your application security program.

Below we can see the same product entry for CVE-2023-36874 in the current/old version 4 format and the new version 5.

 cve, cvss, new CVE API, CVE v5 Json, first, product
CVE JSON V4 – affects
vulnerability, cve, cvss, new CVE API, CVE v5 Json, vulnerability management, CPE
CVE JSON V5 – affected

Apart from changes to the overall structure of the affects/affected elements (e.g. products are no longer grouped by vendor), we can see that the product information is more specific and complete, including CPE names and a structured version constraint.

CVSS Impacts move to Metrics

The other noticeable change in the structure of the JSON from NVD is the move of CVSS information from the impact object to the metrics array. This critical parameter is used to calculate the base score in CVSS for your vulnerabilities in the vulnerability management or application security program.

cve, JSON v4, impactcvss, application security, new CVE API, CVE v5 Json, first,
CVE JSON V4 – base score
cvss, cve, cvss, application security, new CVE API, CVE v5 Json, first, application security
CVE JSON V5 – metrics

However, please note that V5 features a new “impacts” element (array) that can be confused with the V4 “impact” object. They contain different information. Remember that the CVSS details are in the new “metrics” array.

Other changes

The new structure is generally more extensible, adapting to application security and vulnerability management, as we can see from the transitions from singular objects to arrays containing many elements. This is clearly noticeable at the top level by introducing the “cna” and “adp” containers.

On a different front, apart from the CPE details now available in the “affected” array, the configurations element contains the “configuration required for exploiting this vulnerability”.

Furthermore, the new schema features elements for “workarounds”, “solutions”, “exploits”, “timeline”, “tags” and others. The official V5 schema documentation is quite well structured and a must-read for anybody working with these formats.

How to query NVD API to get CVSS

there are open alternatives to CVSS and NVD databases for your vulnerability management program. Those toolsets would need to be updated, so beware if after September, there is some interruption

Official query tool from first: https://github.com/toolswatch/pycvss3

NIST Wrapper: https://nvdlib.com/en/latest/

CVE API from open Vulnerability DB: https://docs.opencve.io/api/cve/

NVD API V2

NIST’s NVD provides its own version of the CVE database, with additional information and query capabilities. Naturally, this has meant this database and its access APIs are changing as well.

Most of the CVE API V2 data format changes align with the CVE JSON schema V5 updates, but others are specific to NVD.

This transition has been in progress for a while now, following a schedule defined by NIST as follows (text in bold is for future milestones).

October 2021The NVD released API keys.
March 2022The NVD announced the enforcement of API rate limits for users without an API key.
July 2022The NVD announced its 2.0 APIs are in development.The NVD announced that 12 months after the release of the 2.0 APIs it will retire its legacy data feeds and the 1.0 APIs.
September 2022The NVD released the 2.0 APIs in an open beta.The 2.0 APIs included all the functionality of the 1.0 APIs plus new features and improved performance.New users were advised to start with the 2.0 APIs.Existing users were advised to prepare for their transition to the 2.0 APIs.
November 2022The NVD released a new API endpoint for CVE Histories in an open beta.
January 2023The 2.0 APIs have exited the open beta period, deprecating the 1.0 APIs.While deprecated, the 1.0 APIs will not receive updates or product support.All new and existing users must transition to the 2.0 APIs.
March 2023The NVD plans to retire the RSS data feeds.The NVD plans to enable reCAPTCHA across all webpages and to retire webpages intended to support web scraping (e.g., Full Listings) before its APIs existed.
September 2023The NVD plans to retire the remaining legacy data feeds as well as all 1.0 APIs.

As before, the NVD data includes the “configurations” elements to capture the combinations of affected products

vulnerability, cve, cvss, application security, new CVE API, CVE v5 Json, vulnerability management, first, application security

However, the new version provides more details and includes the “matchCriteriaId”, which can be used to query the list of CPEs matching that CPE name (through the CPE APIs V2).

vulnerability, cve, cvss, application security, new CVE API, CVE v5 Json, vulnerability management, first, application security

How does CISA KEV Integrate in new CVE API

But one of the key additions to V2 (in part because it’s completely new to this version) is the inclusion of CISA KEV information for each CVE. This is a very nice touch from the NVD guys that can save us additional requests to the CISA data sources.

vulnerability, cve, cvss, application security, new CVE API, CVE v5 Json, vulnerability management, first, application security, cisa kev

The new CVE APIs

While the new APIs have been improved in terms of structure and performance, we should keep in mind that they are a free service, not geared towards extremely high volumes.

Even though they provide powerful search capabilities, they don’t provide multi-CVE (or multi-CPE) requests, which means that many requests must be performed per-CVE/CPE basis.

The above, coupled with a rate limit of 50 requests per 30-second window (for requests with API Key; without Key it’s only 5 requests), could mean that some users might find this quite limiting. Clearly, the preferred strategy for consuming this data should be based around local storage of the complete DB and regular updates only of modified data.

Another significant change with this upgrade is removing the one-file-per-year downloads. These were a good way to kick-start a local copy of the database, but now we’ll have to rely on the paginated API V2 for this purpose, as described in the recommended workflow.

Taking into account that the maximum number of CVEs per request is 2000, and that there are around 220,000 CVEs in the database, it would take 110 requests to fetch the whole dataset. If each request takes around 4 seconds, as our tests show, and we sleep for 6 seconds between requests, as recommended in the documentation, it should take less than 20 minutes to fetch the whole CVE database into your local copy.

After that, it’s just a question of fetching only new and updated items…

Alfonso brings experience running international teams for multi-million dollar, technologically advanced projects for Telefónica, IBM and Vodafone. Alfonso joins with two decades of experience working for tech leaders, including at Dell EMC, Yahoo! and Intershop.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

Discover and fix CVE-2024-3094 vulnerability affecting Linux distributions liblzma, part of the xz package, Fedora, openSUSE, Debian, and Kali. Get the latest updates, fixes, and security recommendations to safeguard your system against unauthorized access through compromised XZ Utils. Protect and discover the affected system with ASPM, Application security Posture management
Francesco Cipollone
Discover and fix CVE-2024-3094 vulnerability affecting Linux distributions liblzma, part of the xz package, Fedora, openSUSE, Debian, and Kali. Get the latest updates, fixes, and security recommendations to safeguard your system against unauthorized access through compromised XZ Utils. Protect and discover the affected system with ASPM, Application security Posture management
Francesco Cipollone
Discover and fix CVE-2024-3094 vulnerability affecting Linux distributions liblzma, part of the xz package, Fedora, openSUSE, Debian, and Kali. Get the latest updates, fixes, and security recommendations to safeguard your system against unauthorized access through compromised XZ Utils. Protect and discover the affected system with ASPM, Application security Posture management
Francesco Cipollone
Explore the interplay between the MITRE ATT&CK framework and EPSS for effective vulnerability management. Learn how these tools help predict and prioritize cyber threats, with deep dives into the most and least exploited techniques. Stay ahead in cybersecurity with Phoenix’s advanced analysis.
Francesco Cipollone

Derek Fisher

Head of product security at a global fintech

Derek Fisher – Head of product security at a global fintech. Speaker, instructor, and author in application security.

Derek is an award winning author of a children’s book series in cybersecurity as well as the author of “The Application Security Handbook.” He is a university instructor at Temple University where he teaches software development security to undergraduate and graduate students. He is a speaker on topics in the cybersecurity space and has led teams, large and small, at organizations in the healthcare and financial industries. He has built and matured information security teams as well as implemented organizational information security strategies to reduce the organizations risk.

Derek got his start in the hardware engineering space where he learned about designing circuits and building assemblies for commercial and military applications. He later pursued a computer science degree in order to advance a career in software development. This is where Derek was introduced to cybersecurity and soon caught the bug. He found a mentor to help him grow in cybersecurity and then pursued a graduate degree in the subject.

Since then Derek has worked in the product security space as an architect and leader. He has led teams to deliver more secure software in organizations from multiple industries. His focus has been to raise the security awareness of the engineering organization while maintaining a practice of secure code development, delivery, and operations.

In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.