Add a cacheable task that has the NVD database as output

[Vampire]

Updating the NVD API is a slow task, especially if there are many updates.

Currently it does not even work properly most often, as the backend server does not answer the Cloudflare proxy in time which then results in 524 error responses for the API download calls.

One of our build agents was able to successfully download the updates, but the others still don't have the current data and thus fail analysis as update fails with server-side error.

It would be nice if there were a cacheable task that cares about getting the updated NVD data with the "last updated timestamp" as input and the NVD database files as output.

That way not only all build agents can reuse these cached results as soon as one build agent did the update successfully, but also local builds can reuse the result if a remote build cache is in use.
This can then even reuse the NVD database without having an NVD API key available, having the current data fast from the cache instead of querying it from the NVD API.

This would solve problems with slow NVD downloads, missing API keys, and currently even the server-side errors preventing the analysis to run properly.

Maybe it even needs to be multiple tasks, so that on a cache miss you don't need to download the complete database but can update it. Not sure how to best solve it, but thought I give a food for thought here.

[chadlwilson]

This seems a very Gradle-specific suggestion (even specific to your particular deployment if using remote build caches) and not really compatible with the way everything else in the core of ODC works. The core of ODC is used by a number of plugins, and i doubt it's going to be refactored significantly specifically to support something Gradle (and further hacking around the NVD).

As far as I can tell you can achieve the same thing currently by using separate update and anaiyze tasks with a custom data directory you archive yourself into Nexus or Artifactory (or somewhere) with a bit of Gradle scripting (per pattern at https://dependency-check.github.io/DependencyCheck/data/cacheh2.html )

Or using a central database rather than the H2 database.

Or you can avoid the API by using NVD's 2.0 data feeds.
Or avoid it by using data feeds built by ODC itself.

• like NVD API update process retries indefinitely with repeated request failures DependencyCheck#8633 (comment)

All of these approaches work for every single ODC integration in basically the same way, and already exist. I use the Gradle plugin with both central data dir caching on Nexus (need to cache OSS index results too) and proxied NVD official 2.0 data feeds - have had zero problems in the most recent weeks' incidents.