Alright.
Now that you've seen how Dependency‑Check works,
let me finish up by sharing just a few tips that I found to be
helpful as I've adopted this tool into my projects.
First of all,
try and understand how the Dependency‑Check analyzers will interact with
your application's dependencies so that you can make sure that the scan
of your project is as effective as possible.
For example,
some analyzers will need the dependency files to have already
been downloaded to disk before scanning them.
So in, say, a continuous integration build,
then you might need to make sure that any installed dependency steps
have already happened before you scan your application.
In our JavaScript demo earlier,
we saw the value of really understanding how the different analyzers work.
We were able to use that knowledge to improve the accuracy
of our results quite a bit in that example by disabling an
analyzer that we didn't need, by excluding a directory from the scan,
and by separating out our development dependencies.
Secondly,
think about how and when you'll run this tool, and
that definitely should be automated.
If you're a development team,
then adding this as a step into your continuous integration
pipeline will seem like an obvious choice here,
and for many teams, that works just fine.
But bear in mind, new vulnerabilities often get discovered in old dependencies,
and if you make this a required build step,
well you might suddenly find that you can't deploy to production anymore,
even if your code is exactly the same.
What's more, if development stops on the project,
then you will also stop getting Dependency‑Check alerts.
An alternative way to approach this is to set this up as a
separate task scheduled to run say once a day.
That way you'll always be notified if a new vulnerability is
discovered without blocking development.
Then, think about how you might integrate Dependency‑Check
into other security or quality tooling.
I've already mentioned CI pipelines, and OWASP provides plugins for Jenkins,
for Azure DevOps, and for CircleCI, but you definitely don't need a plugin.
The core CLI will work with pretty much any build system,
and if your build system supports running Docker images,
then you won't even need to install anything.
If your role is less development and more security operations,
then you'll likely want to integrate with some kind
of continuous monitoring tool.
And again, there are OWASP provided integrations available for SonarQube,
as well as another free OWASP tool, Dependency‑Track.
Or you can output the Dependency‑Check report into a
machine‑readable format like JSON as we saw earlier,
and you can then set up your own integration with your preferred tool.
Next,
set a quality gate to alert you when a new vulnerability
is found that needs your attention.
Don't rely on a human regularly reading the
Dependency‑Check reports to let you know.
Use that fail on CVSS flag that we demoed earlier,
but what severity level should you pick?
Well unfortunately, there is no one‑size‑fits‑all answer to that question.
You'll have to take some time to consider the risk profile of
your specific application and figure out what severity level
adequately balances risk and reward.
In most cases,
you probably don't need to worry about low severity vulnerability reports.
There is definitely diminishing security returns at
that end of the severity scale,
and there is a good chance that it wouldn't even be
possible to fix them all if you tried.
So medium severity, that's a 4.0 on the CVSS scale,
is probably not a bad place to start,
and that all leads us to my final tip which is to be pragmatic.
Adding dependency scanning to a project can create a lot of
remediation work that your team might not be used to,
especially if it's a project that's already been around awhile.
If you set unrealistic goals,
then you risk overwhelming and discouraging your team and you might even
end up giving up on dependency scanning altogether.
So figure out what your team can sustain, and if in order to start doing this,
you need to only respond to high or critical
vulnerabilities or you need to skip dev dependencies,
well that's better than not knowing about any vulnerabilities at all,
so you might as well do it.
Once you've gotten the hang of things,
you can always review your strategy and tighten it up a notch.
I hope that's been helpful.
Join me in the next module as I summarize what we've learned and show you a
few additional resources that you might want to check out.