Dependencycheck: NodeAuditAnalyzer fails when hitting a 400 Bad Request where `npm audit` succeeds

[oliverlockwood]

Describe the bug

[DependencyCheck] [ERROR] NodeAuditAnalyzer failed on <redacted-path>/package-lock.json
[DependencyCheck] [WARN] An error occurred while analyzing <redacted-path>/package-lock.json' (Node Audit Analyzer).
[DependencyCheck] [INFO] Finished Node Audit Analyzer (0 seconds)
...
Could not perform Node Audit analysis. Invalid payload submitted to Node Audit API.

There are some similarities with #1632 and #1634, but those have been closed and we're still having issues with version 5.2.0, hence this ticket.

Version of dependency-check used
The problem occurs using version 5.2.0 of the CLI (but it was originally spotted using the Jenkins plugin).

To Reproduce
Steps to reproduce the behavior:

1. Put the package-lock.json and package.json into a folder.
2. Run npm audit -registry=https://registry.npmjs.org. It succeeds and finds 81 vulnerabilities.
3. Point the NodeAuditAnalyzerIT.testAnalyzePackage() test to use the package-lock.json file in this folder, and run. Boom.

Expected behavior

1. the Node Audit should succeed
2. the behaviour should be consistent between dependency-check and npm audit!

[jpeterso]

We just hit this issue too with version 5.2.1. Any solutions since reporting?

[oliverlockwood]

Sadly not. We worked around in a decidedly unsatisfactory manner, by disabling dependency checking for projects which suffer this bug :disappointed:

It would be nice to see an opinion from the project maintainers...

[jpeterso]

@oliverlockwood Agreed. We have hit this bug as well and are having to turn off the dep check in a few repos as well.

[skjolber]

@oliverlockwood @jpeterso did 5.2.3 fix the issue for you? Because I'm still getting it with 5.2.4.

[oliverlockwood]

@skjolber 5.2.3 did indeed fix the issue for us. But I haven't tested with 5.2.4 yet 😬

[jeremylong]

@oliverlockwood any chance you can test 5.2.4? The only change between 5.2.3 and 5.2.4 that would have affected the node.js analysis was wrapping the caching in some error handling:

+++ b/core/src/main/java/org/owasp/dependencycheck/data/nodeaudit/NodeAuditSearch.java
@@ -39,6 +39,7 @@ import org.slf4j.LoggerFactory;
 import javax.json.Json;
 import javax.json.JsonObject;
 import javax.json.JsonReader;
+import org.apache.commons.jcs.access.exception.CacheException;

 import static org.owasp.dependencycheck.analyzer.NodeAuditAnalyzer.DEFAULT_URL;

@@ -99,8 +100,13 @@ public class NodeAuditSearch {
             LOGGER.debug("Not using proxy");
         }
         if (settings.getBoolean(Settings.KEYS.ANALYZER_NODE_AUDIT_USE_CACHE, true)) {
-            final DataCacheFactory factory = new DataCacheFactory(settings);
-            cache = factory.getNodeAuditCache();
+            try {
+                final DataCacheFactory factory = new DataCacheFactory(settings);
+                cache = factory.getNodeAuditCache();
+            } catch (CacheException ex) {
+                settings.setBoolean(Settings.KEYS.ANALYZER_NODE_AUDIT_USE_CACHE, false);
+                LOGGER.debug("Error creating cache, disabling caching", ex);
+            }
         }
     }

[jeremylong]

@skjolber Any chance you can provide a package.json and package-lock.json that we can use to test?

[oliverlockwood]

@jeremylong apologies for my last message which turned out to be incorrect. I have just double-checked and it turns out we moved straight from 5.2.0 to 5.2.4, which resolved the issue we had seen. So I guess @skjolber's issue must be a different variant.

[skjolber]

Ok, this can be closed. We generated a package-lock.json via yarn and npm audit failed because we had not run npm install. The error message was exactly the same as above, so I guess there is something to be gained by propagating a more exact error message.

Edit: Or this might just have masked the problem. Will investigate further.