Fortunately, there are tools that can help us have confidence about the open
source components that we're building into our software.
These are called Software Composition Analysis, or SCA tools, and
typically they work in three stages. First, they analyze the target
application to build an accurate, specific list of all the components used
in it, down to the exact version number. There are a few different ways
this can work, including looking at dependency files directly or by
reading metadata or manifests.
And a good tool often combines more than one approach.
Crucially, this has to include not just direct dependencies of
an application, but also dependencies of those dependencies,
which often get forgotten about.
Then, an SCA tool will compare this list against a database
of known vulnerable packages and versions.
There are a few different sources for this.
The most well known is the National Vulnerability Database,
or NVD, maintained by the US government.
These databases are constantly being updated and added to by
vendors and security researchers from all over the world, so the
results of an SCA scan can change over time.
Finally, the SCA tool will do something useful with the information
it has gathered, and typically this is a report telling you which
vulnerabilities were present and in which dependencies they were
found. That might be in human readable format or it could be a
structured data format, which another tool could pick up and read.
This kind of automation is essential for the speed and the
scale of modern software development.
Doing these checks by hand would be crazy time consuming, so SCA tools are
absolutely key for teams looking to embrace DevSecOps. Dependency‑Check
produced by the OWASP group that I mentioned earlier is one example of an SCA
tool, and we're going to spend the rest of this course learning about how
OWASP Dependency‑Check works and how we can use it effectively with the
Globomantics search application as an example. A lot of the general advice and
best practices that we'll explore will be applicable to other SCA tools,
though. Dependency‑Check follows that same three‑step pattern that I mentioned
before.
There are a few specific things worth mentioning about the way it
works. Dependency‑Check is a command line tool, or at least the
cool tool which we'll be looking at today is there are some extra
bits I'll mention later.
It has full support for Java, .NET, and JavaScript, and it has experimental
support which can be enabled for Python, Ruby, Swift, and PHP. Primarily,
Dependency‑Check uses the National Vulnerability Database, but in some
cases it will also check the GitHub Advisory Database, the Retire.js
database, and the Sonatype OSS Index. Dependency‑Check is designed around a
series of analyzers.
An analyzer is a specific methodology for collecting
dependency data, and it's usually focused on a particular
technology or file type. For example,
there was a JAR analyzer for looking at Java dependencies. By
default, all of the analyzers get run in a scan, so you can get
great results with minimal configuration.
We'll look more at analyzers in an upcoming demo.