Dependency-check NVD db update error

[mertartanbtc]

trafficstars

Hello, I am running the latest version dependency-check with docker on vmss agent with azure pipelines.

--nvdApiKey df6826c1-****
--nvdApiDelay 10000
--nvdMaxRetryCount 25

Even though I provided the API nvdApiKey, nvdApiDelay and nvdMaxRetryCount values as above, I have been receiving the error 13 that I mentioned in the log for the last 2 days. When I update my Apikey and try it, I get the same error. When I increase the nvdApiDelay value the db update takes too long. What do you think could be the reason for the error?

Log file

Please ensure your API Key is valid; see https://github.com/jeremylong/Open-Vulnerability-Project/tree/main/vulnz#api-key-is-used-and-a-403-or-404-error-occurs

If you NVD API Key is valid try increasing the NVD API Delay.

If this is ocurring in a CI environment
	at org.owasp.dependencycheck.data.update.NvdApiDataSource.processApi(NvdApiDataSource.java:387)
	at org.owasp.dependencycheck.data.update.NvdApiDataSource.update(NvdApiDataSource.java:116)
	at org.owasp.dependencycheck.Engine.doUpdates(Engine.java:906)
	at org.owasp.dependencycheck.Engine.initializeAndUpdateDatabase(Engine.java:711)
	at org.owasp.dependencycheck.Engine.analyzeDependencies(Engine.java:637)
	at org.owasp.dependencycheck.App.runScan(App.java:262)
	at org.owasp.dependencycheck.App.run(App.java:194)
	at org.owasp.dependencycheck.App.main(App.java:89)
[INFO] Updating CISA Known Exploited Vulnerability list: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
[INFO] Begin database defrag
[INFO] End database defrag (272 ms)
[WARN] Unable to update 1 or more Cached Web DataSource, using local data instead. Results may not include recent vulnerabilities.
[ERROR] Unable to continue dependency-check analysis.
[ERROR] One or more fatal errors occurred
[ERROR] Error updating the NVD Data; the NVD returned a 403 or 404 error

Please ensure your API Key is valid; see https://github.com/jeremylong/Open-Vulnerability-Project/tree/main/vulnz#api-key-is-used-and-a-403-or-404-error-occurs

If you NVD API Key is valid try increasing the NVD API Delay.

If this is ocurring in a CI environment
[ERROR] No documents exist

##[error]Bash exited with code '13'.

[ajeckmans]

We have the same issue now.

[jeremylong]

Following either of these should help in the long term:

• https://jeremylong.github.io/DependencyCheck/data/cacheh2.html
• https://jeremylong.github.io/DependencyCheck/data/mirrornvd.html

[ajeckmans]

Is it just the API getting overloaded? If so it would be nice to see that reflected in the error message if possible.

[jeremylong]

100% agree - but this project doesn't own or contribute to the NVD API. We just use the API.

[ajeckmans]

I am aware of that. I was just hoping that something in the response would indicate that the server is overloaded and that it has nothing to do with an invalid key.

[Nishith1314]

Will removing the NVD API key in my maven pom still try to hit the NVD API?

[jeremylong]

Yes

On Fri, Jun 14, 2024, 11:43 AM Nishith N @.***> wrote:

Will removing the NVD API key in my maven pom still try to hit the NVD API?

— Reply to this email directly, view it on GitHub https://github.com/jeremylong/DependencyCheck/issues/6428#issuecomment-2168299028, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGSVQUER5FWTQ7QORB7XXLZHMFSVAVCNFSM6AAAAABCLJG7ICVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRYGI4TSMBSHA . You are receiving this because you commented.Message ID: @.***>

[Nishith1314]

So whats the work around or fix for this... We have multiple apps using this plugin and don't want to get failed because of the NVD API error.. Can I stop it from hitting the NVD server in anyway? I am doing the CI for each application and the build is failing. When I retrigger again the issue gets fixed at times.. Please suggest a way to still use the plugin without these errors in maven project

[jeremylong]

Take a look at options 2-4: https://jeremylong.github.io/DependencyCheck/data/index.html

[mcsmit]

We use option 4 (Use a more robust centralized database with a single update node) and still have the same issue. Our database is MySQL and one job updates this database each day. Since version 10 the first fill of the database went smooth but after that updating keeps failing.