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:

NIST Wrapper:

CVE API from open Vulnerability DB:


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…

How Phoenix Security Can Help:

Phoenix Security is a platform that collects information from various sources, contextualizes, and prioritizes vulnerabilities from code to the cloud leveraging CVSS 3, CWE, Contextual information, Cyber threat intelligence.

With Phoenix Security you don’t need to worry about which source of vulnerability gets flagged, Phoenix highlights those vulnerabilities for you.

If you want to know more about Phoenix security and doing vulnerability management at scale, contact us 

Get a Free Assessment today

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

Phoenix Security, the next-gen leader in Application Security Posture Management and Unified Vulnerability Management, welcomes Lee Vorthman, Ciso of ORACLE advertising to the advisory board
Francesco Cipollone
Owasp top 10 has been a pillar over the years; sister to CWE – Common Weakness Enumeration we provide an overview of the top software vulnerabilities and web application security risks with a data-driven approach focused on helping identify what risk to fix first.
Francesco Cipollone
The Cloud Security and AppSec teams at Phoenix Security are pleased to bring you another set of new Phoenix Security features and improvements for vulnerability management across application and cloud security engines. This release builds on top of previous releases with key additions and progress across multiple areas of the platform. Asset and Vulnerability Management – Associate assets with multiple Applications and Environments – Mapping of vulnerabilities to Installed Software – Find Assets/Vulns by Scanner – Detailed findings Location information Risk-based Posture Management – Risk and Risk Magnitude for Assets – Filter assets and vulnerabilities by source scanner Integrations – BurpSuite XML Import – Assessment Import API Other Improvements – Improved multi-selection in filters – New CVSS Score column in Vulnerabilities
Alfonso Eusebio

Join our Mailing list!

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

x Logo: ShieldPRO
This Site Is Protected By