NVD API update process retries indefinitely with repeated request failures

[sakenalimbayev]

Precondition

• I checked the issues list for existing open or closed reports of the same problem.

Describe the bug
During the vulnerability database update phase, Dependency-Check repeatedly retries NVD API requests without providing enough information about the underlying failure.

Version of dependency-check used
Dependency-Check Core version 12.2.2

Log file
https://gist.github.com/sakenalimbayev/5559dca430a31defdd8cc3b506f2503c

To Reproduce
Steps to reproduce the behavior:

1. Run dependency-check.sh
2. See error

Expected behavior
Report generated successfully

[marcelstoer]

This is not a bug on our side and nothing we can do.

NVD updated their data yesterday. Hence, if ODC updates the local database it'll have to pull ~350'000 records from the NVD. As the NVD infrastructure apparently (still) isn't prepared to handle such load, it errors out with HTTP 503.

#11 93.79 [ERROR] Error updating the NVD Data
#11 93.79 org.owasp.dependencycheck.data.update.exception.UpdateException: Error updating the NVD Data
#11 93.79 	at org.owasp.dependencycheck.data.update.NvdApiDataSource.processApi(NvdApiDataSource.java:387)
#11 93.79 	at org.owasp.dependencycheck.data.update.NvdApiDataSource.update(NvdApiDataSource.java:128)
#11 93.79 	at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:887)
#11 93.79 	at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:859)
#11 93.79 	at org.owasp.dependencycheck.App.runUpdateOnly(App.java:444)
#11 93.79 	at org.owasp.dependencycheck.App.run(App.java:173)
#11 93.79 	at org.owasp.dependencycheck.App.main(App.java:88)
#11 93.79 Caused by: io.github.jeremylong.openvulnerability.client.nvd.NvdApiException: NVD Returned Status Code: 503
#11 93.79 	at io.github.jeremylong.openvulnerability.client.nvd.NvdCveClient._next(NvdCveClient.java:445)
#11 93.79 	at io.github.jeremylong.openvulnerability.client.nvd.NvdCveClient.next(NvdCveClient.java:356)
#11 93.79 	at org.owasp.dependencycheck.data.update.NvdApiDataSource.processApi(NvdApiDataSource.java:343)
#11 93.79 	... 6 common frames omitted

On June 17, 2026, the National Vulnerability Database (NVD) deployed an expansion to its vulnerability assessment metrics and data schema.
...
The deployment process affected approximately 95% of all existing vulnerabilities within the NVD. Consequently, every updated record now includes a new change log entry and an updated “lastModified” timestamp.

Source: https://www.nist.gov/itl/nvd#news-updates

We build the database daily like so (ODC CLI):

# Load the current NVD data and suppression files into the local ./data dir.
# First, get the cached feed files as a basis.
# They are force-updated every 24h, see https://github.com/dependency-check/DependencyCheck_Builder/blob/main/.github/workflows/cache.yml and https://github.com/dependency-check/DependencyCheck_Builder/tree/gh-pages.
# Then fetch the latest delta from the NVD API.
$ bin/dependency-check.sh --updateonly --nvdDatafeed=https://dependency-check.github.io/DependencyCheck_Builder/nvd_cache/nvdcve-{0}.json.gz && \
$ bin/dependency-check.sh --updateonly --nvdValidForHours=0 --nvdApiKey="$NVD_API_KEY"

This is not yet completely optimized but usually keeps us well shielded from NVD infra issues. However, the delta pull (2nd command) now has to pull all changes since 2026-06-16T20:58:59Z - that is the value nvd.api.last.modified has after updating the database from the feed files. Hence, all changes from June 17th would come through the NVD API.

[brampat]

Same here. NVD decreased budget is becoming more and more an issue.

[ImadNadeem]

So what is the solution for this?

[brampat]

So what is the solution for this?

Either use a different CVE source or use OWASP Dep. Track (easy to run locally using Podman / Docker) and instead of generating your CVE scan in the pipeline, upload / import your SBOM to Dep. Track. Extra points for setting up an OWASP Dep. Track server in your stack and auto-uploading them as part of the pipeline. Dep. track monitors ALL dependencies, and raises issues based on not just CVEs, but also licensing issues. You can set policies, like "should have no CVE's of 7+" and report on which apps are within policy and which are not. And obv. the graphs of CVEs over time is something mgnt will drool over(I hope... if numbers go down)

mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

[chadlwilson]

https://www.nist.gov/itl/nvd#june-17-2026-nvd-deployment-update-ssvc-and-cve-affected-data-no

https://socket.dev/blog/federal-audit-finds-nist-wasted-funds-with-no-plan-to-clear-nvd-backlog

As @marcelstoer says, nothing this project can do. Wait for the load peak to pass, and properly cache updates, or use the data feed URL with the cache as noted at #8435 (comment) (which will likely be stale for the same reasons as noted here, but might be better than nothing).

Every time NVD make any change to their responses, their whole system goes down. Has been happening for years, and it will not change any time soon.

See #8435 (comment) or the literally dozens of duplicate threads.