Identifying Open-Source Vulnerabilities: Tips and Tools By Gilad David Maayan
Open source components enable faster development. You don’t have to build from scratch, and you can quickly add upgrades. The downside of open source is that you never know what code you’re going to get, and what threats and vulnerabilities it might pose on your otherwise spotless codebase. This article discusses the common security pitfalls of open source, and introduces ways to detect and fix threats and vulnerabilities.
Open-Source Risks You Should Know About
When including open-source components in your systems and applications, there are a few unique risks you should be aware of. With proprietary components, you can rely on your own teams or vendors to ensure that components are secure. However, with open-source components, this is not always the case.
Publicity of exploits
Open-source projects make their code publicly available. This enables community members to collaborate on open-source development. Part of this collaboration is making vulnerabilities known to the community and any users of the project. This allows community members to develop patches when necessary and ensures that users can take proper precautions until and after a patch is developed.
After a patch is developed, open-source vulnerabilities are also made available to the wider public. This information is often available from a variety of sources, including various vulnerability databases and threat intelligence feeds.
Unfortunately, information that is made public to users is also accessible by potential attackers. If users do not monitor vulnerability information or do not keep their components up to date, attackers can easily exploit this information.
Copyright infringement
Open-source components are created by a range of community members and are typically overseen by volunteer teams. This means that project maintainers have limited ability to verify the true source of code. If a community member submits code taken from proprietary sources or uses code in a way that is prohibited, it is difficult to know.
When you include components that have proprietary code, even if you aren’t using them commercially, you can be held liable. An example of this was seen with the SCO Group, which sued IBM for using UnixWare source code in Project Monterey. In this case, IBM allegedly included Unix components in its development of Linux systems.
Operational risks
Using open-source code can save you money on licensing but it typically introduces extra maintenance and development work. Open-source components do not come with built-in support, upgrades, or turnkey installation like proprietary components do. This means that your teams need to do all the work of integration, customization, and maintenance that would normally be covered.
Managing open-source components requires tracking what components you have and where components are. If you are unaware of the components you are using you cannot keep your open-source up to date. You also can’t standardize your version use. Likewise, you need to periodically verify that the projects you are using are still active. If an open-source project is dropped it is no longer updated and patches are not issued.
Ways to Find and Fix Open Source Vulnerabilities
Using open-source components can create vulnerabilities in your applications and systems. However, you can manage these vulnerabilities, ensuring that you get the benefits of open-source without the risks.
Become Familiar with CVSS v3
The Common Vulnerability Scoring System (CVSS) is a standard used to classify the severity of vulnerabilities. Many vulnerability information sources and databases use this system to help teams prioritize vulnerabilities.
CVSS v3 is the latest version of this system. This version includes some significant changes from the previous versions. To ensure you’re using it properly, make sure to familiarize yourself with these changes.
Create an Inventory
The most effective way to keep track of your components and ensure that your systems remain up-to-date is to create an inventory. Software composition analysis (SCA) tools can help you with this. These tools can identify what components you’re using, where components are located and can help you track when vulnerability information is released.
Alternatively, to track open-source components in your own applications you can use build automation tools, such as Maven or Gradle. With these tools, you can create dependency trees that enable you to track versions used and identify component locations.
Establish an Open-Source Policies
To ensure that components are vetted and included uniformly you should create a clear open-source policy. This policy should define any testing that components are subject to before inclusion. It should also specify any restrictions according to project size, source, or release frequency.
In this policy, make sure to clarify whether developers can include open-source code snippets. If the answer is yes, account for how these snippets should be tracked.
Monitor for Vulnerability Announcements
Open-source projects do not directly inform you when releases are made public or vulnerabilities are announced. Instead, it is up to you to monitor mailing lists, check documentation pages, and to track vulnerability information feeds or databases.
A good source to start with is the National Vulnerability Database (NVD). This database provides vulnerability information for a wide range of projects as well as information for remediation.
Use Automation
Depending on the tools you are using to manage your open-source components, you should be able to automate some of the process. For example, you can set up automated alerts informing you when patches are released.
You can also use dynamic application security testing (DAST) tools to evaluate components in-situ. If vulnerabilities are found you can then take the appropriate actions, including informing project maintainers if the vulnerability is newly identified.
Adopt the Right Tooling
There is a wide variety of tools you can use to identify and audit for vulnerabilities regardless of whether issues have been officially discovered or made public. Below are a few open-source tools worth considering:
- Commit Watcher—a tool that enables you to scan repository commits for undisclosed security patches or leaked secrets. This tool can help you ensure that your own commits are clean and that you are fully aware of any relevant changes to projects you are using.
- w3af—a framework that enables you to test for and identify web application vulnerabilities. It can help you identify over 200 known vulnerabilities and includes features for payload injection that you can use to verify security measures.
- OWASP ZAP—a tool that enables you to perform penetration testing on your web applications. It tests for all of the most common vulnerability types and can be extended through plug-ins for customized testing.
Conclusion
In today’s demanding development environment, hardly anyone builds from scratch. You usually start from something, and that something is open source. The problem is that when using public components as the skeleton of your codebase, you might introduce vulnerabilities into your project. You also risk copyright infringement when using unchecked open source libraries.
To avoid these issues, you should always check components before using them. You should also create an inventory of code components, and continuously monitor for vulnerabilities and licenses. To save time, you can use automation tools, but be sure to check for proper integration before introducing a new solution.
About the Author:
Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.