Introducing Qwiet AI AutoFix! Reduce the time to secure code by 95% Read More

How can one measure and mitigate the security risks in open source software? This is a crucial topic that is now becoming a major issue in the software development community. In this chapter, we will dive into the work we have done at Google, in collaboration with Open Source Security Foundation (OSSF) to make it easy for both Open Source developers and consumers alike. Make no mistake — attacks on Open Source Software (OSS) are on a constant rise. Open source supply chain attacks grew 650 percent last year – a staggering number.

During 2021 and into 2022, every month there has been a significant attack which impacted more than 1000 organizations. The most prominent recent OSS attacks happened as a result of the Log4Shell vulnerability disclosed in December 2021. Attacks on the OSS supply chain and on OSS impacted every single software organization on the planet. Everybody is scrambling to continuously patch systems as new vulnerabilities continue pouring in.

To properly navigate this environment and keep our systems safe, we as a community need to understand the security risks of OSS and be better prepared to handle them, collectively and individually. This chapter discusses how to mitigate risks and, more importantly, how to think about OSS.

Open Source Risks

There are a number of risks that make it more dangerous to consume and trust OSS without taking proper security measures.

OSS Is Free. OSS Security Is Expensive.

As a starting point, we must recognize that open source software may be free to download and require no payment, but it comes with a massive security cost.

A significant portion of the open source software is developed by volunteers in their free time. Most of the prominent open source volunteers actually have full-time jobs, and the code they contribute to projects like the Log4J logging libraries they write on nights and weekends, on their own time and not on the company dime. Not surprisingly, security often comes last in their priority list. They don’t have the resources to invest in a secure development lifecycle or have the time and bandwidth to maintain their code. This may mean that security vulnerabilities remain unaddressed for long periods of time, sometimes indefinitely.

All Bugs Are Shallow. But There Aren’t Enough Eyeballs.

In software development, Linus’s law states “…given enough eyeballs, all bugs are shallow”. This law is only true if those eyes are looking in the right place. In the case of open source, all code is open but we don’t have enough eyes paying attention to it to spot all the bugs. In addition, organizations don’t realize the security consequences of their decision before consuming a particular piece of open source software and adding it as a dependency. Dependency trees become more and more complex, and harder and harder to monitor and secure, as you keep adding more third party components to your core codebase. Each new dependency might bring additional nested dependencies — perhaps hundreds