![Industry Perspectives Industry Perspectives](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/bltcf2b437471bc0d1c/664ba3979c1fd769482032c6/IndustryPerspectives_ITP_Light.png?width=700&auto=webp&quality=80&disable=upscale)
Insight and analysis on the information technology space from industry thought leaders.
4 Ways to Reduce Reliance on Bad Open Source Packages
Follow these four steps to proactively identify and eliminate risks from problematic open source packages.
August 12, 2024
![magnifying glass hovering over the words "open source" magnifying glass hovering over the words "open source"](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/bltae99d0374b3f9a75/66ba24c8d49fea3893358d96/open-source-with-magnifying-glass.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
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."
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.
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:
Does it conform to my organization's license policies?
Is it actively maintained or is it deprecated?
Are the maintainers actively responding to security issues? How active is the community that is producing new releases?
How healthy are the packages' dependencies and sub-dependencies?
How will you or your team need to prepare to contribute to the community?
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:
A new release comes out, which may lead to end of support for older versions that you may still be using.
A new version is released under a different license type.
The package is marked deprecated or abandoned.
The package seems to be regularly impacted by vulnerabilities.
The package's dependencies are introducing risk.
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:
Is the package using enterprise-grade secure software development practices?
Has it been marked abandoned or deprecated, or does it have an end-of-life date approaching?
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.
About the Author
You May Also Like