SanitizePackage throws NullPointerException during Node package scanning

[oliverlockwood]

Describe the bug

When running dependency-check against one of our modules, I hit the following NPE.

[WARN] An unexpected error occurred during analysis of '/Users/oliverlockwood/work/flex-nodejs-authentication/package-lock.json' (Node Audit Analyzer): null
[ERROR]
java.lang.NullPointerException: null
	at org.glassfish.json.JsonObjectBuilderImpl$JsonObjectImpl.getString(JsonObjectBuilderImpl.java:199)
	at org.owasp.dependencycheck.data.nodeaudit.SanitizePackage.sanitize(SanitizePackage.java:74)
	at org.owasp.dependencycheck.analyzer.NodeAuditAnalyzer.analyzeDependency(NodeAuditAnalyzer.java:189)
	at org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze(AbstractAnalyzer.java:131)
	at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:88)
	at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:37)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
[INFO] Finished Node Audit Analyzer (0 seconds)

It is worth noting that:

• we currently use yarn; so the package-lock.json is actually dynamically generated from yarn.lock using synp
• in order to try and debug this, I cloned the DependencyCheck repo and tweaked SanitizePackageTest.testSanitizePackage() to run against the local file. By doing so (adding try around the problematic line, and then logging in the catch branch) I identified that the problem occurs because for some reason the package-lock.json contains a double-nested dependencies object; that is, running cat package-lock.json | jq '.dependencies.dependencies' returns the following.

{
  "sax": {
    "version": "1.2.4",
    "resolved": "https://nexus.ooflex.net/repository/npm/sax/-/sax-1.2.4.tgz",
    "integrity": "sha1-KBYjTiN4vdxOU1T6tcqold9xANk="
  }
}

There seems to be nothing equivalent in the yarn.lock file, so perhaps there is an underlying bug in synp (UPDATE: imsnif/synp#29 is the issue), but nevertheless I believe this should be handled more gracefully.

Version of dependency-check used
The problem occurs using version 5.2.0 of the the CLI (whether directly or via the Jenkins plugin).

Log file
Log file is 421MB. I'm not sure how to upload a gist that large.

To Reproduce
Steps to reproduce the behavior:

1. Download the package-lock.json from https://gist.github.com/oliverlockwood/a63d2475c9a8faf0945e254c6be8e022
2. Run the dependency-check CLI against it

Expected behavior
I would expect:

• if there is a failure in running SanitizePackage, that some information is given - either in the standard output or the detailed logs - to identify what part of the package-lock.json is problematic
• error cases like this to be ignored and the rest of the file to be processed.

[jeremylong]

As I'm betting even npm audit would fail on the package-lock.json with the incorrect nested dependencies I'm not inclined to worry about this. Also, we reworked the node analysis for 5.3.0 which will be released soon.