10 Questions Organizations Should Be Asking Before Using an Open Source Project
February 29, 2024

Lauren Hanford

Open source code is the bedrock of modern application development. Many applications are built almost entirely from open source components. This is not an accident: open source has become ubiquitous because of its many benefits that speed up innovation.

Yet many organizations have also been burned by their open source component choices. Sometimes a new open source package is hastily picked without fully vetting who developed it or how they keep it up to date and secure. Other times, work on a component is simply abandoned by an open source maintainer, who has lost interest, or doesn't have the time or incentive to do the work required to keep it up to date. Even if the organization researched the package up front when they first selected it, this information can change quickly, and it is easy to get tripped up by a package that used to be actively maintained, but no longer is.

Bad open source packages suck up valuable development time. Hours are consumed trying to "rip and replace" a problematic component that is no longer being actively maintained, or to identify and patch ongoing security vulnerabilities that continue to crop up in a package that is being undermaintained. Sometimes your organization itself is the issue because you are unable to upgrade to a newer version of a package and are stuck figuring out how to continue to keep a version that has been deprecated on life support.

Traditionally organizations have relied on software composition analysis tools (SCA) as the primary means for identifying bad open source releases. But while SCA tools can show you where the vulnerabilities are today, they are less useful at predicting which packages will have recurring problems or difficult-to-fix vulnerabilities in the future.

The easiest way to avoid having to replace vulnerable open source packages is to not bring them in at all.

This is where organizations need to start making additional investments in open source software security: proactively doing the research before bringing in an open source component to ensure you are making good decisions. By doing this research ahead of time, you can take control of your own security future, only bringing in components that follow the secure development practices that will reduce the likelihood of future vulnerabilities.

So what should you be looking for when making open source package choices for your applications? Here are ten critical questions to ask yourself before using an open source project:

1. Is the project abandoned or is it actively maintained?

The first and most important question to answer is whether there is still active work on the project. Using unmaintained projects means future potential issues will not be fixed, which will make dealing with any issues your responsibility. Abandoned projects are "de facto" end-of-lifed, even when nobody has actually documented that.

2. Is the project or version officially deprecated, or has it been end-of-lifed?

When a project is deprecated, it means that those who created or maintain it have indicated that users should move away from the project, most often because it is end-of-life already or will be end-of-life soon. Older versions may be end-of-lifed even if new versions are still receiving updates, because it is too much work (or simply impossible) to back port changes to those older versions. Using deprecated projects or versions means future issues will not be fixed, which will make dealing with these issues your responsibility.

3. Who are the maintainers and how many maintainers are behind the project?

The more you can learn about the maintainers who are actively working on the project the better. While having a single maintainer is more common than you think and is not necessarily the sign of a vulnerable project, having multiple maintainers is a good sign that there is not a single point of failure that might cause the package to go unmaintained in the future.

4. Who has publishing rights on upstream package managers?

As part of your research into the maintainers behind the project, you'll also want to look for projects where only approved maintainers have the publishing rights to contribute code.

5. Does the project have security practices such as multi-factor authentication in place?

With the rise in software supply chain attacks where contributor accounts are compromised and malicious code is inserted directly into a project, it is important to know whether the maintainers require two-factor authentication to make it more difficult for their credentials to be stolen.

6. Does the project have a history of responding to security and other issues?

Spend time reviewing the maintainers' track record of responding to previous security and maintenance issues. Does the project have an official security disclosure policy and process, and have they followed it in the past? How quickly do they respond to and address vulnerabilities that have been reported?

7. What is the version history and which is the recommended version?

It is important to choose a version of the package that is aligned with your organization's security policies. This might mean staying on the latest version, or it might mean using a previous version that has been evaluated and determined to be safe.

8. Is the project or release impacted by any existing vulnerabilities?

You'll want to ensure there are no open or unresolved vulnerabilities on the package or in its dependency graph to avoid adding new risk by bringing in this package.

9. What are the associated project and release dependencies?

Many open source projects rely on direct and transitive dependencies — additional open source code that the project calls to complete its functions. It is important to research a project's dependencies to avoid accidentally bringing in a security vulnerability from a project dependency. You'll also want to trust that the package maintainer is upgrading any dependencies that their package is using.

10. Is the license compatible with your organization's legal guidelines?

Open source project creators have a wide variety of licenses to choose from that guide usage. Some licenses prevent commercial use, others come with legal stipulations that may not be acceptable to your organization. Make sure to check the license the package is using to ensure it aligns with your organization's policies and avoid unnecessary legal risk.

These 10 questions will help organizations take the first step to implementing a proactive approach to open source security. By doing this up front research to avoid problematic packages alongside scanning for known package risk, companies can ensure they have an even more robust set of protections in place so they can fully take advantage of the innovative potential of open source without opening their organization up to undue risk.

Lauren Hanford is VP of Product at Tidelift
Share this

Industry News

April 11, 2024

Check Point® Software Technologies Ltd. announced new email security features that enhance its Check Point Harmony Email & Collaboration portfolio: Patented unified quarantine, DMARC monitoring, archiving, and Smart Banners.

April 11, 2024

Automation Anywhere announced an expanded partnership with Google Cloud to leverage the combined power of generative AI and its own specialized, generative AI automation models to give companies a powerful solution to optimize and transform their business.

April 11, 2024

Jetic announced the release of Jetlets, a low-code and no-code block template, that allows users to easily build any technically advanced integration use case, typically not covered by alternative integration platforms.

April 10, 2024

Progress announced new powerful capabilities and enhancements in the latest release of Progress® Sitefinity®.

April 10, 2024

Buildkite signed a multi-year strategic collaboration agreement (SCA) with Amazon Web Services (AWS), the world's most comprehensive and broadly adopted cloud, to accelerate delivery of cloud-native applications across multiple industries, including digital native, financial services, retail or any enterprise undergoing digital transformation.

April 10, 2024

AppViewX announced new functionality in the AppViewX CERT+ certificate lifecycle management automation product that helps organizations prepare for Google’s proposed 90-day TLS certificate validity policy.

April 09, 2024

Rocket Software is addressing the growing demand for integrated security, compliance, and automation in software development with its latest release of Rocket® DevOps, formerly known as Aldon®.

April 09, 2024

Wind River announced the latest release of Wind River Studio Developer, an edge-to-cloud DevSecOps platform that accelerates development, deployment, and operation of mission-critical systems.

April 09, 2024

appCD announced its generative infrastructure from code solution now supports Azure Kubernetes Service (AKS).

April 09, 2024

Synopsys announced the availability of Black Duck® Supply Chain Edition, a new software composition analysis (SCA) offering that enables organizations to mitigate upstream risk in their software supply chains.

April 09, 2024

DataStax announced innovative integrations with API extensions to Google Cloud’s Vertex AI Extension and Vertex AI Search, offering developers an easier time leveraging their own data.

April 08, 2024

Parasoft introduced C/C++test CT, a comprehensive solution tailored for large teams engaged in the development of safety- and security-critical C and C++ products.

April 08, 2024

Endor Labs announced a strategic partnership with GuidePoint Security.

April 08, 2024

Hasura announced the V3 of its platform, providing on-demand API composability with a new domain-centric supergraph modeling framework, a distributed supergraph execution engine and a rich and extensible ecosystem of open source connectors to address the challenges faced during integration of data and APIs.

April 04, 2024

DataStax has entered into a definitive agreement to acquire AI startup, Logspace, the creators of Langflow, an open source visual framework for building retrieval-augmented generation (RAG) applications.1