Understanding Open Source Vulnerabilities

Incorporating open source libraries, applications, container images or other components into your organization’s own software offers a variety of benefits. It speeds deployment processes, saves development resources and (because open source is usually free to use) may lower licensing costs.

However, any team that uses open source as part of its own software stack must manage the vulnerabilities that can lurk inside open source code. This article explains what open source vulnerabilities are, why they can be problematic, and how to manage them effectively.

What is an open source vulnerability?

An open source vulnerability is a security vulnerability in any type of open source software, such as a software library, a container image, a Helm chart or a standalone open source application. Known open source software vulnerabilities are typically published in public vulnerability databases, like NVD and MITRE CVE. Using these databases, you can determine which vulnerabilities exist for a given open source resource.

The risks of open source vulnerabilities

Like closed source software, open source can contain coding flaws that make it possible for attackers to exploit the software in some way.

Unlike most closed source software, however, open source is routinely incorporated into other software. For example, developers might import an open source library into an application that they are building. Or, an IT team might pull container images for an open source Web server (like NGINX or Apache HTTPD) or database (like MySQL) and deploy them within its own environment.

In some cases, open source components could end up within your team’s software stack through third-party products. This could happen if you use a commercial product that incorporates open source components, even if the vendor does not disclose which open source components exist within the product.

The reuse of open source code is what makes open source vulnerabilities particularly risky. If you import a vulnerable open source component into your environment but aren’t aware of the vulnerability, the open source component becomes an attack vector that threat actors could use to exploit your entire software stack.

What’s worse, open source software is sometimes incorporated into applications or environments in ways that make it hard to identify. As a result, teams may deploy vulnerable software without even realizing that the software contains an insecure open source component.

How to manage open source vulnerabilities

There are two main steps for managing and protecting against open source vulnerabilities.

The first is to know which open source components exist within the software you use. You can do this by creating a Software Bill of Materials, or SBOM, for any software that your team creates internally. You can also request SBOMs from vendors or other third-party suppliers who generate software that you use.

The second step in managing open source vulnerabilities is to perform vulnerability scanning on all software that you deploy within your stack. Vulnerability scanners automatically check software components against vulnerability databases to determine whether each component is subject to any known security advisory.

Other best practices for securing open source

Beyond creating an SBOM and scanning your software for vulnerabilities, additional best practices for using open source securely include:

• When possible, obtain open source software from trusted, established sources. Avoid obscure repositories and stick to the official distribution channels for the open source project you are interested in.
• Lock down your organization’s software repositories and registries with access controls. This helps prevent attackers from inserting vulnerable software into the repositories or registries in order to spread it within your organization.
• Use Software Composition Analysis (SCA) tools to identify open source components within codebases. SCA tools can detect open source code even if it is integrated into a broader codebase in such a way that it is not labeled within the code as an open source component, and not mentioned within product documentation. In addition, advanced SCA tools provide data on open source components beyond vulnerabilities, such as operational risk and license risk, which can help support decisions on which open source software versions to use.
• Enable version control within your repositories and registries to keep track of the specific versions of each software component you use. In many cases, a security vulnerability will only apply to certain versions of software, so it’s important to be able to determine quickly which versions you are using.
• In addition to using public vulnerability databases to validate open source software CVEs and licenses, consider using proprietary databases along with deep vulnerability knowledge form an expert security research team like the one at JFrog.
• Categorize open source security risks based on priority level. Not all vulnerabilities in open source components are necessarily exploitable; in many cases, they can only be exploited under certain configurations. Security tools that are capable of providing this type of contextual vulnerability assessment help teams determine where to focus their remediation efforts.