There is one last improvement we can make to this scan.
JavaScript, in particular,
relies very heavily on external packages in our software build process.
These are known as development dependencies,
or dev dependencies,
and they're used for things like transpiling and bundling the code,
running development tests, and so on.
But once the build has completed,
those packages don't actually get included in the finished product,
that's in contrast to production dependencies,
which will actually be shipped in the code that gets deployed
on a server or run in a user's browser.
Because dev dependencies often significantly outnumber production dependencies,
having them included in the scan makes it really hard to
properly identify and remediate the real threats.
The noise can really drown out the signal here.
In the Globomantics search app,
only one out of the nine reported vulnerable
dependencies is actually present in production.
It's understandably then very tempting to ignore
development dependencies altogether,
especially in JavaScript applications where they are really prevalent,
but is that safe?
Well let's take a look at how Globomantics build and deploy
their web app to try and understand the risks.
There is nothing too out of the ordinary here.
Developers code the web app on their laptops,
then push their code,
including the list of required dependencies to a build server.
The build server automatically installs all of the listed dependencies,
both dev and prod dependencies, and builds the web app.
The finished app, which now only contains the production dependencies,
is then deployed to the web server.
When users visit the search site,
their browsers download a copy of the JavaScript application,
including those production dependencies.
If we were to take dev dependencies out of our vulnerability scan,
we'd be able to focus much more effectively on the
right‑hand side of this diagram,
keeping our production application and our end users secure.
But on the other hand,
dev dependencies can still be dangerous and you can see
that if we completely ignore them,
then we're actually failing to secure our development and build
processes in the left‑hand side of this diagram.
After all,
we are downloading code written by strangers off the internet and
running it on our development infrastructure,
often with a high‑level of trust too.
Now without access to our machines,
most accidental vulnerabilities would be almost impossible for an
attacker to exploit in this development scenario,
but intentionally malicious packages have been known to run cryptominers,
steal secrets, and install ransomware on development infrastructure.
We'll definitely want to know about that in our dev dependencies.
We can solve this problem neatly by running two separate scans on our web app,
one with all dependencies included to check for any really nasty,
high severity development dependencies and a second stricter scan with
dev dependencies excluded so that we can make sure that we have a really
close eye on those production dependencies.
Dependency‑Check gives us an option to skip dev
dependencies for the Node Audit Analyzer.
It's the flag ‑‑nodeAuditSkipDevDependencies.
We'll go ahead and run that final command on our web app.
When that's complete,
you'll see that we have only one single vulnerability in our
production application and that is the dompurify library.
It's marked as critical, so we'll probably need to do something about that.
We'll talk about that in the next clip.