DEVOPSdigest

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.