Okay.
You've installed Dependency‑Check, you've configured it just the way you want it,
you run it against your app, and you have a bunch of vulnerabilities reported.
Well, now what?
Unfortunately, using the tool is the easy bit.
Deciding what to do with the output is tricky and it can be very time consuming,
but don't panic.
First, prioritize.
If you're staring at a lot of vulnerabilities in that report,
and you might be if this is the first time running
Dependency‑Check on that project, it can be overwhelming.
So click on the severity column to sort descending
and just take them one at a time.
For each vulnerable dependency, you have a few options.
The first question you should be asking is can we patch this vulnerability?
If the issue is in a popular well‑maintained open source package,
then there is a very good chance that there is already a fixed version of
that package by the time the vulnerability is reported.
Often,
the easiest thing to do is just to upgrade that
dependency to a version that isn't vulnerable,
especially if you're using a package manager that can help with the upgrade.
Why spend lots of time trying to investigate the issue if you can
type a couple of commands and just make it go away.
Whether or not you can patch, of course, depends on a few things.
Obviously, if no patch has been released yet, well that's going to be a problem.
Unfortunately,
a common reason for this is that an affected dependency
just isn't in active development anymore,
which means a patch probably isn't coming.
Or you might also find that a patched version does exist,
but other libraries in your project depend on that vulnerable
version in a way that prevents you from updating.
This is common when you have very complex dependency graphs and
vulnerabilities surface inside those transitive dependencies,
that's the dependencies of your dependencies that you didn't directly require.
If you're already doing continuous deployment,
then a quick patch release should be straightforward,
but if your release schedule is more constrained or a
release is very time consuming to do,
you might need to do further analysis to decide
whether to justify issuing a patch.
Finally, if the vulnerability is very serious,
even if you can patch it right away,
you may still want to do some analysis to just understand the
impact and perhaps try and confirm that it wasn't exploited in your
system before you were able to patch it.
If you can't just simply patch it and move on,
you're going to have to do some investigating to see
if it really does apply to you.
First, understand that Dependency‑Check reports possible vulnerabilities,
and just because a vulnerability is listed,
it doesn't mean that your specific application actually has that floor.
Often,
the vulnerability is only triggered in very specific circumstances or
configurations and it may well be that your app doesn't use the affected library
functionality or it's not configured in a vulnerable way.
You can start by reading the description for that
vulnerability in the Dependency‑Check report,
and if that doesn't give you enough information to decide,
follow the links to the various external databases like
the NVD and the GitHub advisories.
They're often a very helpful resource.
You might also find some good information just by
searching the web for the CVE identifier.
If after all that, you're confident that the vulnerability doesn't apply to you,
then you can go ahead and suppress the report so that
it doesn't appear going forward,
and I'll show you how to do that in the next clip.
Now there is some risk associated with suppressing vulnerability reports.
It can be extremely hard to figure out whether you are affected,
especially if you're dealing with a transitive dependency
where it may not be possible to tell how it's being used and
you could make a mistake here.
And even if your app isn't affected now,
if the vulnerable dependency remains in your project,
it could very easily become affected with a harmless looking
configuration change or a code commit at some time in the future.
For those reasons, I recommend that if you suppress a particular warning,
you do it only temporarily so that you're reminded to review
it later on to see if a fix has come out and to check that
you're still not vulnerable.
It's also really important that you document the reason why
you're suppressing the vulnerability,
whether that's for the benefit of another developer who
comes across it or for you in 6 months time.
After all, you may have spent quite a bit of time investigating this,
and it would be a shame for all of that work to get forgotten.
Finally, if there is no fix available,
you've determined that your application is vulnerable and it's sufficiently
serious that you can't wait for a fix to be released,
you're going to have to make your application safe somehow.
This could mean swapping out the vulnerable dependency for an alternative
library or making a code or configuration change to prevent the
vulnerable functionality from actually being used.