4 Ways to Reduce Reliance on Bad Open Source Packages

By Lauren Hanford, Tidelift

If your organization is like most, there is a lot of open source code in your applications. Several recent studies have found that 90% or more of applications contain open source components, and for good reason. Open source code is freely downloadable, makes developers more productive, and accelerates innovation.

But the downside of using open source is that it often comes with hidden costs related to ensuring the packages you rely on are healthy and secure. The recent malicious attacks impacting log4j and xz utils shined a spotlight on open source software security and elevated it to an executive-level priority in many organizations. Against this backdrop, many application development teams are looking for new ways to ensure bad open source packages don't find a way into their applications.

What Makes an Open Source Package 'Bad'?

I like to use the phrase "bad package" as shorthand for an open source package that is bad for enterprise use. A package may be considered bad if it is abandoned, deprecated, or declared end-of-life. Or it may not have published security policies or respond to security issues — often because there is only one maintainer. Organizations are often surprised to find packages in their applications that are malware and removed from the package manager — but never cleaned up once "inside."

Related:Are We Approaching the End of Open Source?

Bad packages not only create security risk that can impact your organization's revenue, data, and customers, but they also suck up valuable development time when you need to replace them, work around them, or deal with endless cycles of vulnerability remediation.

Historically, many organizations have relied on software composition analysis (SCA) tools to identify and remediate vulnerabilities in the open source packages they are using in their applications. This is an effective way to ensure risk from existing vulnerabilities is reduced. But it is also an endless game of "whack-a-mole," involving triaging long lists of security vulnerabilities that are difficult to prioritize and separate false positives from real security risks. An SCA-only approach can not only miss early risk signals but also miss when a package has been declared end of life, which can lead to a false sense of security when in reality there is a greater risk of vulnerability or — worse — an attack.

So rather than relying on vulnerability remediation alone, many organizations are investing in proactively better understanding the health and security practices of the open source packages they use, so they can more systematically reduce their reliance on bad packages before issues arise. Here are four key ways your organization can get started with your own proactive approach to identifying and eliminating risk from bad open source packages.

Related:Secure Open Source Software Is Helping Enterprises Find Their Edge

Evaluate Packages Before Pulling Them in for Application Development

The best way to avoid risk from bad packages is to ensure they don't make their way into your application in the first place. When researching and evaluating open source packages to use, develop a clear set of checks they need to pass in order to be considered for use.

Common questions to ask include:

Actively Monitor the Open Source Packages in Use

Open source packages are constantly changing, and so it is important to monitor and review updates after making the initial decision to use a package or version. Look for early warning signs that might indicate that a package or version is going bad.

Examples of things to look for include:

Identify and Eliminate Bad Packages You've Already Adopted

While it is ideal to avoid bad packages in the first place, most organizations already have a significant number of packages in their applications that were not properly researched to ensure the packages weren't bad.

So it is often important to go back and look at the packages you are already using to try to answer questions like:

Reinforce At-Risk Packages to Keep Them From Becoming Bad

Clearly, it is important to identify at-risk packages so you can address issues with them before vulnerabilities arise. But one other way to ensure that packages important to your application aren't at risk is to do your part to keep them well-maintained and healthy.

Start with research to understand whether the maintainers of the packages you use are being reliably paid to implement secure development practices and maintain those practices and the code itself. Proactively understand the current and long-term outlook for packages before bringing them into your organization. Invest in your dependency graph financially and with code contributions so that you are doing your part to maintain its long-term health and security.

Bottom line: When you eliminate bad open source packages from your applications, you reduce security risk by eliminating potential attack entry points. You improve your team's productivity by reducing fire drills caused by insecure or undermaintained packages. And you improve your application quality by ensuring you are building with healthy and resilient open source packages.

About the author:

Lauren Hanford is vice president of product at Tidelift, leading the product and design teams' efforts through discovery and delivery. At her heart, she is a UX researcher and approaches technology from a user-centered place. As a product leader, she thrives on taking swings at hard problems and the ambiguity of taking products, and teams, from 0 to 1.