8 Ways to Find and Fix Open Source Vulnerabilities

Overview

As consumer demands evolve and agile methods dominate the world of software development, more organizations are tightening their software development lifecycles (SDLCs). Shorter release cycles enable software applications to stay relevant and provide the services their customers need, but they also allow less time for building, testing, and repairing code. One way to reduce your workload while keeping up with a fast development environment is to use open source software (OSS). Most software, including commercial software, contains open source code, which is free and modifiable, and which developers don’t have to build from scratch.

Open source software is lower cost than proprietary software, and it has the added advantage of an open source community, which monitors and assesses the safety and utility of OSS products. More than anything, open source is simply a necessity because it saves time. The code is ready-made and has proven functionality, while the open source license offers you the flexibility to adjust the code to suit your own needs.

However, the ubiquity of OSS also has a downside. A 2017 report by Black Duck found that 96% of commercial applications used open source components, with known vulnerabilities in 67% of these. In 2018, the situation was even worse, with 78% of codebases containing vulnerabilities.

Open Source Risks

As with proprietary code, open source code can contain vulnerabilities that hackers can exploit, resulting in issues like denial of service (DoS) attacks or unauthorized access to your system. When developers use code from open source libraries, they could also be introducing vulnerabilities into their applications. Likewise, new security vulnerabilities are often discovered in old libraries.

Visibility is a major issue, with many organizations failing to keep track of the dependencies in their products, while smaller companies often neglect to scan their code for potential vulnerabilities. As open source components age, they generate a greater risk. The US government-sponsored Common Vulnerabilities and Exposures (CVE) list recorded more than 8,000 new vulnerabilities in 2017, but this list by no means covers all known vulnerabilities.

Even large companies are not immune. For example, the Equifax breach of September 2017 compromised the personal information of over 148 million people. The source of this breach was a vulnerability in the Apache Struts open source software, which the company was aware existed. Security scans did not pick up the compromised versions of Apache Struts, and while a patch was available well before the breach occurred, Equifax failed to apply it in time. In 2017, a third of applications using this software also contained the Struts vulnerability.

Other risks relate to license and compliance issues. While open source licenses allow you to use and modify the software, they may still set out terms with which you need to comply. It is possible that some open source libraries are infringing on copyright laws. Consider also that open source products don’t always come with adequate warranties or liabilities.

How You Can Manage Open Source Vulnerabilities

As a distributed ecosystem, open source is harder to manage than proprietary software and requires a different approach to security. Here are 8 ways you can mitigate the risks of OSS:

• Find Vulnerabilities:

Perhaps the most important aspect of open source risk management is visibility. You cannot apply patches to vulnerabilities you don’t know exist. You should maintain a list of all the open source components you use, detailing the open source library in which they were found. You should also integrate vulnerability scans into your development process to keep this list updated.

• Bake Security into the SDLC:

You should build security checks into the development process so you can catch vulnerabilities early. This helps ensure that vulnerabilities don’t make it into your final product. While running scans early in the SDLC can slightly delay development, it reduces the time

• Promote Communication and Collaboration:

Developers and security teams should work together, extending the collaborative DevOps framework to encompass security. Developers should receive training so they understand the various security risks and remediation practices. Everyone should discuss security frequently from early on in the SLDC.

• Create Open Source Management Policies:

Organizations should have policies in place outlining discovery and management procedures. This includes designating who is responsible for identifying open source components in the codebase, keeping inventory of the libraries used, finding vulnerabilities and applying patches. There should also be a framework for assessing the security and legal risks involved with specific components.

• Automate Security:

Tracking the various open source databases to find vulnerabilities can be time-consuming. You can save time by automating simple, repetitive tasks like identifying open source components in your codebase, monitoring databases, and running tests. Automated tools can also help with code analysis and implementing fixes.

• Use the Right Tools:

You can use Software Composition Analysis (SCA) tools to identify open source components in your source code and to keep you updated regarding vulnerabilities. SCA tracks community databases and provides actionable alerts for new vulnerabilities. Tools like static code analysis scanners can help you identify open source risks, while services like Black Duck audit open source products to assess compliance and security risks.

• Take Advantage of the Open Source Community

The main source of information regarding new vulnerabilities and fixes is the open source community. Researchers and security teams rigorously test OSS code to discover vulnerabilities, publishing their findings on open source platforms or vulnerability databases. However, this information is not always easy to find. You have to take responsibility for making sure you are aware of any new vulnerabilities in the open source components you use, and you have to apply the updates yourself.

• Avoid Components With Known Vulnerabilities:

While you can usually fix issues in a vulnerable product, you shouldn’t use components with known vulnerabilities unless it is absolutely necessary. There are solutions you can use to identify vulnerable components in open source libraries, and some organizations have automated policies that block developers from committing risky code. You should also remove old components where possible, as they are more likely to have exposed vulnerabilities.

Conclusion

Open source software is a major part of many applications and enables fast, consistent, cost-effective, and safe development. However, it is important to understand the risks involved. As long as you stay on top of the security vulnerabilities in your code and fix them in time, you should be able to reap the benefits of the vast range of OSS products available.