We've notified the Globomantics team about the outdated Solr installation,
and they're rolling out the update as we speak.
Let's turn our attention to the second component of the search app,
the web application.
Unlike the Solr example that we just saw,
Globomantics wrote this application themselves using JavaScript
which means we have access to the source code.
Of course, as is normal practice,
they have used lots of third‑party libraries to help build this app.
We need to find out how to get Dependency‑Check to
accurately inventory and check all of those dependencies so
that we can report back to the team.
Along the way,
we'll learn about a few command line options that
we can use to finetune our scan, excluding directories,
disabling analyzers, and separating development dependencies.
Let's take a look.
We've got the source code checked out on our laptop,
and we're looking at the root folder of it here.
We don't need to worry too much about how this JavaScript app works.
This isn't a JavaScript course,
and Dependency‑Check is going to handle all of that for us.
Let's open a terminal in the current directory and run
Dependency‑Check with the same basic arguments as before to see how
well that default configuration works for our web app.
Once again, it's going to take a few minutes to run.
The first thing you'll notice about the report is that it's huge,
almost 33 MB, and if we open it up,
we can see a clue as to why the report shows 27,000 scanned dependencies.
JavaScript projects do tend to have a lot of dependencies,
but usually not quite that many.
In this case, the true number is 1800,
so Dependency‑Check is scanning a lot of files that it shouldn't be.
If we scroll down to look at the list of vulnerable dependencies,
we can also spot a few things here which are potentially unhelpful.
You can see we have a report for dompurify version
2.0.0 near the top of the list.
But further down, we have more reports relating to dompurify,
in this case, flagging specific JavaScript files from inside that same package.
It isn't really giving us any new information, it's just generating noise.
There is also a handful of false positives in this report that
will distract us from the real vulnerabilities.
For example, check out this report for WS, a WebSocket library version 6.2.2.
Let's come down to the published vulnerabilities,
and we've got 1 medium‑level report CVE‑2021‑32640,
a resource exhaustion problem.
Let's open up the last two references, the NVD and the GitHub security advisory.
In the NVD, if we scroll down to known affected software configurations,
we can see that the issue exists up to and excluding 6.2.2, so our version is
actually the patched safe version according to the NVD.
The GitHub page also confirms that.
So the analyzer here has picked up that the
vulnerability exists in this package,
but it hasn't picked up that it is actually patched in the version that we have.
So what's going on here?
Well Dependency‑Check actually has three analyzers
that scan JavaScript applications,
they each have a specific use case that they work best on,
but remember, by default, all analyzers run on a scan,
even if they're not really the best fit for the current project.
The Node Audit Analyzer works only for JavaScript projects which use
the npm package manager for dependency management.
It will take your dependency list as calculated by npm and submit that
data to the npm Audit API to check for vulnerabilities that's backed by
the GitHub security advisory database.
So if your project uses npm, this is probably the best analyzer for you.
The Node.js analyzer is similar to the Node Audit Analyzer,
which can be a little confusing.
It works with files from npm and Yarn package managers,
and it will check against the NVD and the Sonatype databases.
In my experience,
the Node.js analyzer isn't quite as accurate as the
Node Audit Analyzer for npm projects.
So I'd recommend that if you can,
you use the Node Audit Analyzer and disable the Node.js analyzer.
In our demo,
the false positive that we saw for the WS library was
generated by the Node.js analyzer,
while the Node Audit Analyzer correctly reports no known
vulnerabilities on our version of that package.
Finally, the Retire.js analyzer is really focused on client‑side code.
It's going to look through your project for JavaScript files that it recognizes
as belonging to vulnerable dependencies and it does that by checking against
the database maintained by the Retire.js project.
If you have copies of third‑party libraries saved directly in your code
base rather than being served through a package manager,
a copy of jQuery for example, then Retire.js will spot those files.
In our case, though, Retire.js was also scanning the node modules directory.
Node modules is where the node package manager places all the
downloaded npm packages for our application.
An individual npm package consists of multiple files and
Retire.js was checking every single 1, all 27,000.
That's why we had such a big report file and that's also why we had
multiple reports for the same dompurify package.
Since the node modules are already being covered by the Node Audit Analyzer,
we can safely exclude that folder from the scan and make those problems go away.
Let's look at the new command that we'll run.
We'll want Dependency‑Check ‑‑scan current directory,
then ‑‑disableNodeJS to skip the Node.js analyzer,
that's case sensitive by the way.
Then we'll pass an exclude argument with ‑‑exclude
and the node_modules directory.
Here,
the quotes and the asterisks make sure that we properly exclude all files from
node_modules no matter where we're running this command from.
Let's go ahead and run that.
The scan is quite a bit quicker now,
and the resulting report is now also a sensible file size.
If we open that report up,
the first thing that you'll see is the number of
dependencies found is actually now too small.
It says 14, when we know it should be in the thousands.
Well, don't worry, the scanners actually work just fine.
This is a known limitation with the Node Audit Analyzer where packages
without known vulnerabilities don't get counted.
Coming down to our list of vulnerable dependencies,
you can see it's a little smaller than it was before.
We still have the dompurify package listed,
but we don't have the duplicated reports for the
individual JavaScript files now.
Also gone is the WS package which we identified as a false positive,
along with a couple of other false positive packages that we didn't talk about.
By disabling the Node.js analyzer and excluding the node_modules directory,
we have improved the accuracy of this JavaScript scan quite a bit.
That's going to make this report much more meaningful and much more
useful for the Globomantics development team.