Failed to request component-reports

[chetan-2085]

We've configured dependency-check to run in Jenkins build pipeline. When multiple builds are triggered simultaneously, we get this error: AnalysisException: Failed to request component-reports [ERROR] caused by TransportException: Unexpected response; status: 429

Looks like there is a rate limit on NVD side that is causing this to fail. How do we handle this?

[aikebah]

Not NVD, but OSSINDEX is giving you the 429.

See OSSINDEX API docs

Either register with Sonatype for a higher limit, disable OSSINDEX Analyzer and/or (if many components are shared) ensure that the Jenkins pipelines use a shared data folder so that they can benefit from the caches that the OSSIndex client created for other builds.

[aikebah]

Note that disabling OSSIndex may result in false negatives that could have been avoided for cases where a (typically recent) vulnerability at the time of scanning is only in their dataset.

[chetan-2085]

I did register with Sonatype but not sure how to use their POST API for this purpose? How are the coordinates defined? How do i make a call to the OSS index REST endpoint?

[aikebah]

Assuming that you use the Jenkins plugin you can find the information in the CLI configuration documentation

There are --ossIndexUsername and --ossIndexPassword optional parameters to configure an OSSIndex account to use for the OSSIndexAnalyzer.

[chetan-2085]

Using --disableOssIndex to disable OSS Index gives and error - "Unable to parse command line options: Unrecognized option: --disableOssIndex"

However when I tried with -DossindexAnalyzerEnabled=false it works well. Is this the right one to be used?

[aikebah]

Assuming that you use the Jenkins plugin you can find the information in the CLI configuration documentation

Was the crucial part of my reply that explains your findings. Your reply indicates you're not using the jenkins plugin for running dependencycheck (which would run the CLI which needs the configuration like stated), but you use the maven plugin. Which means you can either set it with the -D as a property on the maven commandline like you did, or configure it in the pom.xml.

[andrewm-aero]

@aikebah

Not NVD, but OSSINDEX is giving you the 429.

See OSSINDEX API docs

Either register with Sonatype for a higher limit, disable OSSINDEX Analyzer and/or (if many components are shared) ensure that the Jenkins pipelines use a shared data folder so that they can benefit from the caches that the OSSIndex client created for other builds.

Sorry if this is wrong place to ask, but where is that shared directory location documented, and for that matter, why is that information not stored in/retrieved from the JDBC database? Is that an impossibility, or has it just never been gotten-around-to?

[aikebah]

@andrewm-aero

(3rd attempt.... why doesn't the browser cache my replies and restore them, when a gesture makes it traverse browsing history)

The OSSIndex cache is maintained by the library that sonatype publishes for the usage of their API. It expects a folder which is DependencyCheck configures to be underneath the dataDirectory used for various local persistent datas.

https://github.com/jeremylong/DependencyCheck/blob/41785fb6b013a80d830d4b4e03a3ade1d24e9102/core/src/main/java/org/owasp/dependencycheck/data/ossindex/OssindexClientFactory.java#L98-L104

Documentation can definitely be improved on this caching. A quick scan of the codebase reveals the location to be used at least for

• H2 database with the NVD vulnerability data (when using the default H2 database configuration)
• a cached copy of the downloaded NVD data
• the caches of the OSSIndex API client (for the OSSIndexAnalyzer)
• a cache with data from npm audit (for the NodeAuditAnalyzer) and Maven Central search data (pom-files and maven artifact metadata for the CentralAnalyzer)
• a cached copy of the RetireJS vulnerability data (for the RetireJS Analyzer)

How to configure that data directory is listed on the configuration pages of each of the integrations (Maven plugin, Gradle plugin, Ant Task etc.).

For a pre-configured dedicated persistent system (e.g. dedicated buildserver or developer workstation) you would typically leave the data directory at the defaults of the tool. But if you use a pristine environment for your build (e.g. an on-demand provisioned CLI-installation dedicated to your build or an ephemeral containerized build agent that gets cleanly started to run your build and is destroyed afterwards) you may want to consider provisioning a special persistent data-directory that you re-use (e.g. mount into your container) and provide it's location as a configuration parameter to the tool.