It's nearly impossible to build a modern application without relying on third-party libraries. Open source software has been an amazing boom to software development. It's been instrumental in allowing developers to build increasingly more complex applications that make the internet what it is today.
However, third-party libraries also present a few problems from a security perspective. For instance, as a developer, you can be doing everything right in your codebase security wise — utilizing the right patterns for avoiding Cross-Site Scripting (XSS) and SQL injection (SQLi), for instance. But a single vulnerability in a library can leave you vulnerable despite your best efforts. The open source software (OSS) security problem isn't going away. More package managers are starting to include vulnerability checks as part of their workflow, but not all are there yet.
Read on for ways you can find open source vulnerabilities using Sonatype's free service offering, OSS Index.
Challenges with third-party libraries
Staying up to date with the security state of dependencies is almost a full-time job. For each dependency, you could search the internet and see if anything pops up. You could also search common sources of information about open source vulnerabilities.
The most popular source is the Common Vulnerabilities and Exposures (CVE) feed from the National Vulnerability Database (NVD). This database contains known vulnerability information for software and libraries. Doing this regularly to identify software vulnerabilities for even one package is a lot of work, and forget about doing it for all of the packages that your project is using. The other drawback is that for each vulnerability, we may have to dig a bit to identify the versions that are vulnerable.
Adding to the difficulty, not all package managers include vulnerability information as part of their management tools, so we need an alternative. In the article "Getting Started With DepShield: An Introduction," I introduced Sonatype's DepShield GitHub extension. This OSS scanner extension automatically scans your codebase for issues in third-party libraries and then automatically creates issues in GitHub for any identified vulnerabilities.
However, not everyone can use a DepShield OSS scan to find open source vulnerabilities since it requires that the project be hosted on GitHub. Fortunately for us, this tool is powered by Sonatype's Open Source Software (OSS) Index, which we can use regardless of our developer environment.
Sonatype's Open Source Software (OSS) Index
OSS Index is a free service that Sonatype provides for developers to check if any library has known, disclosed vulnerabilities. OSS Index provides an easy-to-use search feature for quickly finding open source vulnerabilities in any library.
It's important to understand specifically what this means and the limitations of OSS Index.
OSS Index contains aggregate information from many sources of vulnerability information, including:
- The Common Vulnerabilities and Exposures (CVE) Entries
- A growing list of public vulnerability sources
- Community contributions
- Security-related bug-tracker issues identified by dedicated OSS Index researchers
OSS Index can help you to find open source vulnerabilities in your software supply chain, but it does not provide curated security details or remediation advice. It's important to keep in mind that OSS Index is not a complete open source software security solution. If OSS Index doesn't show any vulnerabilities for a library you're searching for, it doesn't mean it's free from any vulnerabilities. It only means that there are none known to OSS Index through one of its sources or contributors.
Searching for open source vulnerabilities in libraries
Let's take OSS Index for a spin by looking up information for the ever-popular jQuery JavaScript library. We can search for any library on OSS Index by name. This type of search returns a listing of all of the relevant package managers that include jQuery along with any components with similar names.
Searching for just jQuery results in the following:
Since package managers handle package maintenance differently, there will most likely be differences between versions across these packaging systems. In order to get the most relevant results, you need to find the library in the ecosystem you're using. On the components listing page, you can scroll through the listings to find your package manager, but you can also include the package manager in the search term.
Package coordinates
You'll notice that the component name in the previous screenshot has the pkg prefix. OSS Index organizes libraries using a coordinate system that makes it easy to search for a library in a specific package manager as well as for specific versions of the library.
For example, if you want to limit results to only jQuery libraries in the NuGet ecosystem, you can prefix the search with the following:
pkg:nuget/jquery
This will limit results to the NuGet ecosystem:
Likewise, if you wanted to search the Python PyPI package system for jQuery you could use the following:
pkg:pypi/jquery
OSS Index contains information on many development ecosystems as can be seen on the Ecosystems page:
If you further wanted to limit the results to a specific version of the library in the NuGet ecosystem, the search term can also include the version:
pkg:nuget/jquery@1.6.0
For more detailed information on what you can use for search terms, refer to the OSS Index Coordinates documentation.
Viewing vulnerability details
Let's get into the details of the vulnerability information now. The first result in the above component search, pkg:nuget/Jquery, is for the core package.
Click that link to go to the component overview page:
This page provides information on the ecosystem and coordinates, as well as links to the package and library source code. The information we're interested in is at the bottom under "Vulnerabilities," where you will find open source vulnerabilities listed with their severity and other information.
As shown above, this package contains three critical and ten severe vulnerabilities. In order to see details on these vulnerabilities, you have to sign in with a Sonatype account. You can get a free account by signing up here.
Log in and come back to this page to see a listing of all known vulnerabilities:
This listing orders vulnerabilities by severity according to the Common Vulnerability Scoring System (CVSS). The CVSS is an open industry system for assessing the severity of a vulnerability. Let's dive into the first one with the title "[CVE-2016-10707] jQuery 3.0.0-rc.1 is vulnerable to Denial of Service (DoS) due to removing a log."
The information for each vulnerability includes the CVSS score as we saw before, as well as links to the relevant Common Weakness Enumeration (CWE) and CVE identifiers if they exist. Very importantly, the page shows all the components that includes the library and the specific versions that are vulnerable.
How to read version information
Sonatype OSS Index uses set-notation for specifying versions and version ranges. The previous vulnerability was only present in version 3.0.0-rc1 of jQuery. The bracket notation indicates that it's included in this version.
If you view the vulnerability detail page of another jQuery vulnerability, such as "CWE-79: Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)," you'll see an example that includes a more complex version specification.
The version range here is [1.4.0,1.11.3],[1.12.4,3.0.0-beta1). Breaking this down, it indicates the following:
-
[1.4.0,1.11.3] — This vulnerability is present in any version of the library from 1.4.0 to 1.11.3, including versions 1.4.0 and 1.11.3.
-
[1.12.4,3.0.0-beta1) — This indicates that the vulnerability is present in any version from 1.12.4 up to, but not including, version 3.0.0-beta1.
Next, let's use this information to identify a non-vulnerable version that we can update to.
Identifying the non-vulnerable package
In a perfect world where software developers never have to worry about backward compatibility. Once we identify software vulnerabilities, we would be able to just upgrade to the most recent version. Sadly, we can't always do that without creating a lot of additional work. Often we want to know the next minor version we can upgrade to in order to fix the vulnerability.
As an example, let's say we were using jQuery version 1.11.3 and want to know if there is a minor version that isn't vulnerable to this issue we can upgrade to. Looking at the jQuery downloads page, we can see the next version is 1.12.0.
This version isn't in the vulnerable version ranges, but let's look it up on OSS Index to make sure, using the following search term:
pkg:nuget/jquery@1.12.0
According to OSS Index, this library has no known public vulnerabilities:
Hopefully, we can upgrade to this version of the library without too many breaking changes to our existing application. This isn't always possible and highlights an important reason to stay up to date on all libraries and not allow any of them to get too far out of date. It results in technical debt that also can have serious security implications.
Take time to research your libraries
Despite the effort, it's really important to take stock of your current third-party libraries and spend time understanding the climate around them. Are they too old? Is the library still receiving updates? What's the cost in time of updating to the most recent version?
As a developer, I've been there, spending weeks updating an application due to old dependencies before being able to move forward with new business requirements. As a security consultant, I've also seen the other side of this: Finding multiple vulnerabilities in an application due to outdated client-side and server-side software where the application was fairly solid in other respects.
In closing, you should never underestimate the amount of technical and security debt that letting third-party libraries lag behind can introduce. Stay on top of this debt by building time into schedules for refactoring existing code and doing updates whenever possible. Along with keeping the codebase current, this will also greatly eliminate open source software security issues. Keeping current with new releases will enable you to update the dependency with less effort.
Sonatype has many open source plugins for a lot of package management systems which can be found on GitHub. Don't let an open source vulnerability put your application and its users at risk. Using these open source tools is a fantastic way to start building security automation into your software development life cycle (SDLC). Get going on this today and when you come to the conclusion you'd like more, check out the Sonatype Platform.
