In our first demo, we'll run Dependency‑Check on an installed Java application,
Apache Solr, to see how it works.
We'll focus on the output report and discuss how to read it in its
default HTML form before seeing how we can configure
Dependency‑Check to output a different file format.
The background here is that the Globomantics search team are not quite
sure which version of Solr they have installed on their search server, but
they have a feeling it might be out of date.
They know there are nasty vulnerabilities out there
in some older versions of Solr,
including the Log4Shell vulnerability that we mentioned earlier.
So they've asked if we can use OWASP Dependency‑Check to take an inventory
of what's installed and figure out whether they need to update Solr, and if
so, how urgently. Now that it's installed and made available in our path,
running Dependency‑Check is simple.
We just need to call cependency‑check and then pass the directory that we
want to scan using the ‑‑scan option. In our demo, we want to scan the
Apache Solr installation directory, and on this server that's found at
C:/solr, so the command will look like this.
We've opened a terminal inside the search server, and
we'll go ahead and run that command.
You'll see some informational messages appearing in the
output as Dependency‑Check starts working. If you're
running this for the first time,
it is going to begin by downloading a local copy of those vulnerability
databases that I mentioned earlier, and this may take several minutes, so I'm
going to speed this clip up quite a bit. Once that's done,
you'll see a flurry of additional messages about analyzers finishing or
not being found followed by Analysis Complete and a note about where the
report file was written. By default, it's written as an HTML file into
our current working directory.
Open that report in the browser of your choice, and here's how it looks. At
the top, there's some high‑level stats about the scan,
including the number of dependencies that were scanned,
how many vulnerabilities were found, and we then have a summary table, which
lists all of the dependencies that were found to be vulnerable.
The first three columns identify the dependency by name
and version in a few different formats.
For example,
you can see that the file angular.min.js was found and that it was
identified to be version 1.8.0 of the JavaScript package AngularJS.
The Highest Severity column gives you a description of how severe
the most serious vulnerability known to exist in that version of the
package is, low, medium, high or critical.
The CVE Count column tells you how many
vulnerabilities were found in that dependency.
If we scroll down this list, we can see log4j‑core‑2.14.1 Critical
severity, confirming our suspicions that the version of Solr deployed
here is susceptible to the Log4Shell vulnerability.
We'll have to tell the Globomantics team to update their Apache Solr
installation urgently. If we click on the dependency name,
we get taken to a more detailed report about that dependency and
the vulnerabilities that were found in it.
There's a description of the dependency,
a license if one could be identified, and more information
about the specific file found. The really important bit here
is Published Vulnerabilities.
This section lists details on all known
vulnerabilities associated with this package.
Vulnerabilities are listed by their unique identifier,
which is usually a CVE, or Common Vulnerability Enumeration.
The first four digits indicate the year the vulnerability was disclosed.
We then have a description of the vulnerability and some
information about the severity in the form of CVSS scores.
We'll explore those a bit more later.
If you want additional information about the vulnerability,
the References section contains some useful links. Clicking on the CVE
itself will take you to the vulnerability database that it came from,
which may have other helpful information or links.
The HTML report is a helpful way for a human to review the output, but there
are other output options too, XML, CSV, JSON, JUnit, and SARIF, and you can
have a scan right to multiple formats if you like.
Let's write out a JSON file. We can do that with ‑‑format JSON, in
uppercase. As well as the format, we can also control the output file
name with the ‑‑out command. Let's call this solr‑report.json. This
command will finish much quicker now that the database is already
downloaded, and once it does,
you can see that solr‑report.json has been created. Opening
it up, the JSON report contains all of the same information
that we saw in the HTML report,
but in a more machine readable format. In this demo,
we've been using Dependency‑Check as a security assessment tool
to scope out an off‑the‑shelf application.
It's definitely given us some helpful insight, so there's not too much we can
do about the results other than to upgrade our installation.
In the next clip, though,
we'll apply a Dependency‑Check to a code base that we have
ownership over and we'll start to get a picture of how valuable
this tool can be for continuous security.