Hello everyone.
My name is Matt Kendall, and welcome to this course,
Supply Chain Risk Management with OWASP Dependency‑Check.
The use of open source components when building software is so
commonplace now it's hard to find examples of software projects
that don't use third‑party libraries.
That's just how we build software these days,
and it's great for speed, innovation, and developer experience.
But it does bring with it some scary risks, especially around security.
Many organizations and many teams have rigorous peer
review and testing on their own code,
but that same level of scrutiny isn't always applied to the open source
components that form the foundation of that very same software.
It's believed that around two‑thirds of all applications
contain open source vulnerabilities.
Over the last few years, this is a risk that has only been getting bigger.
We've seen many serious security breaches occur because a
third‑party component had some flaw in it,
which attackers were able to exploit.
To take a now infamous example, in 2021,
it was discovered that a critical vulnerability existed in
the open source Java logging library, Log4j.
The vulnerability called Log4Shell was given the highest possible score,
and it was estimated to affect hundreds of millions of devices.
The Log4Shell vulnerability gained enough media attention that
most software teams immediately realized they needed to check
whether they used this component.
But there are plenty of other vulnerabilities lurking
out there in open source components, some malicious,
but most accidental oversights.
For many teams,
protecting themselves from these vulnerable
components fails at the very first hurdle,
which is knowing that you're even using that component.
The software supply chain can be complex and it can be opaque.
This risk has widespread recognition within the software security
industry. OWASP, the Open Web Application Security Project, is a
nonprofit software security foundation who have been monitoring web
application security risks since 2003.
The use of vulnerable or outdated components was recently ranked as number 6 in
their list of top 10 security risks, up 3 places since 2017.
The National Institute of Standards and Technology also has supply chain risk
management as a core part of their cybersecurity framework.
Now that I've outlined the problem that we need to solve, let me
introduce you to the example scenario that we're going to be
working with as we go through this course so we can have a bit of
context and realism to our demos.
We're going to help the Globomantics corporation with
the security of one of their systems.
It's a search tool for corporate data hosted on their internal network.
The system design looks like this. The search platform
is the heart of the application.
Rather than create this from scratch, they installed Apache Solr,
the popular open source search platform on a dedicated server.
This has access to a custom API, which they did write
themselves using the .NET technology.
The API is also the point of interaction with the
rest of their corporate network.
Then there's the web application,
another custom app written by the Globomantics team in JavaScript. It
pulls data from the API and it shows it to their users.
Don't worry too much about the technical details.
The important thing to take away is that we have three
different systems, a mix of off‑the‑shelf and custom‑built
software in a few different technologies,
and it needs our attention.