Dependencycheck: Centralized Database and --disableCentral | Is it okay?

[aravindparappil46]

Hello!

I am using the CLI 5.3.2 version. I have setup a centralized MySQL Database by running the initialization script & the following command
./dependency-check.sh --log odc.log --updateonly --connectionString jdbc:mysql://MYHOST:3306/dependencycheck --dbDriverName com.mysql.jdbc.Driver --dbPassword MYPASSWORD --dbUser MYUSER

Database was built successfully and exited clean.

However, when I run a scan against this database (used --noupdate), I faced the following:
_PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target_

The HTML report was generated but it showed the above error along with the usual vulnerabilities info.

Perusing through #728, #2222, #561, #2036 and #1908, I realized it's a cert issue and @jeremylong suggested in one of the them to use --disableCentral flag while running the scan. Unsurprisingly, that got rid of the error, but I was concerned about the disclaimer in the CLI arguments page regarding this flag (that it is not recommended).

My question is - if I do have a centralized database that is updated regularly, would it be less of a risk to use --disableCentral and possibly --disableOssIndex too? (Risk in the sense that I won't miss out on catching some vulnerabilities)

_Some additional info:_

• Using Open JDK 1.8.0_232
• No proxy
• As mentioned in #2222, tried export JAVA_OPTS="-Dcom.sun.security.enableAIAcaIssuers=true" but did not get rid of the error
• I am yet to try adding the certificate to keystore (if having a central DB and adding the disable flags get the job done equally well, would prefer that)

Please let me know if you need more information!

Stay safe!

[aikebah]

--disableCentral means 'do not try to look-up maven coordinates of files by searching maven central using the hash of files'. So the side-effect is that you increase the chances that the fuzzy text-based matching will link discovered files to the wrong cpe whereas that would not have happened if maven central had a hit for the hash that showed it was some entirely different file.

If whatever you scan are libraries not present in maven central (https://repo1.maven.org/maven2/) you will not see any difference; if some of them are the chances for a proper cpe-match are higher when the maven-coordinates can be confirmed with the sha-hash lookup, which is why it is not recommended to switch it off for the CLI-scan. Turning it off increases the risk of false matches (which leads to higher false-positive and false negative rates)

My gut feel is that you are on a corporate network travelling via a re-encrypting proxy (which would essentially count as a 'trusted MITM'). If that's the case you could consider obtaining the proxy's CA certificate and add that to javas truststore so that java can build a trusted path from the TLS cert that is offered.

Edit: forget all I said about proxy... I missed the 'no proxy'... no clue why maven central is then not trusted by your java. You should try enabling TLS debugging on java to determine what certificate you do get offered.

[aikebah]

Given that your issue appears to be with access to maven central you might want to try the SSLPoke utility as referenced in a comment in issue 1057 towards https://repo1.maven.org/maven2/ to try and debug why the certificate offered would not be trusted by your java

[jeremylong]

ODC makes at least 4 external connections:

1. The NVD - to pull down the latest CVE data.
2. Maven Central - in some cases helps reduce FP/FN
3. OSS Index - identifies vulnerabilities not in the NVD
4. Github - it performs both a version check to see if you are using the latest version as well as pulls the RetireJS database.

Using a centralized database has no bearing on the items 2-4 - this only solves item 1.

For Maven Central - I would always recommend using the Maven or Gradle plugins directly instead of Jenkins or the CLI when analyzing Java based projects. The central analyzer is disabled by default as the same information can be retrieved from the build system itself.

For OSS Index - there might be vulnerabilities in their database that are not in the NVD. So there is a risk if not using it - up to you and your organization to determine what your risk appetite is.

For the access to github - the version check is trivial and if it fails no errors are produced. However, if the RetireJS repo is not available and you use 3rd party JS files you may see some false negatives. Note, you can mirror the RetireJS repository locally just like the NVD.

[aravindparappil46]

Thanks for the great info, guys! Really helped get more context. I'll close this issue!