By Dan Lorenc, Chainguard
This article is part of a series showcasing learnings from the Secure Software Summit
Photo by Reproductive Health Supplies Coalition on Unsplash
The Open Source Software (OSS) Supply Chain is under attack. As evidenced by the recent Log4Shell vulnerability, the OSS supply chain is increasingly a focus for attackers seeking to exploit weak links in security. A number of research reports have recorded a significant increase in so-called “next-gen software supply chain attacks” over the past decade. These attacks look to compromise key links in the software supply chain including source code, build systems, CI/CD tools, and code testing tools, among others. Next-gen attacks are happening across all languages, all types of software and are increasing with frequency. Common forms include typosquatting, malicious code injection and tool tampering (like the CodeCov incident). In 2021, 64% of organizations reported they were affected by software supply chain attacks, according to container security company Anchore.
The increasing wave of next-gen attacks has driven new regulations mandating specific steps to inventory and make more transparent the content of software applications and the software supply chain. Specifically, Executive Order 14082, issued by United States President Joseph Biden, mandates a long list of security practices, including the inclusion of a Software Bill of Materials (SBOM) with every application run by the U.S. Federal Government. The National Institute of Standards and Technology (NIST) is creating reference architectures and templates for application security as a result of the Executive Order. In other words, regulation on software security will likely impact every company that produces code or sells products running on code (including SaaS products).
To be clear, some of the problems experienced by the OSS software supply chain are not exclusive to open source. The recent supply chain attacks on Microsoft Exchange Server and the SunBurst attack on the SolarWinds network management tool targeted proprietary code bases. That said, OSS is produced and maintained very differently than proprietary software. This does result in some unique risks. In this chapter, we will cover those risks as well as some promising initiatives underway to address those risks.
Why Is the OSS Supply Chain A Juicy Target?
There are two primary reasons. One is omnipresence and the other is weakness. It is not an exaggeration to say that OSS is omnipresent. According to Sonatype, 98% of all code bases contain OSS. This is likely an underrepresentation. You simply cannot build code from scratch today without using OSS components. It is too labor intensive and expensive.The ubiquity of OSS makes the supply chain that creates, distributed and manages OSS an obvious target. At the same time, the widespread use of OSS translates into an increasing burden on companies to maintain, update and patch all OSS dependencies in their applications.
This is an impossible task; it is far easier to insert OSS code to solve an immediate problem than to, over time, make sure that code is updated and not vulnerable. For this reason, Sonatype estimated that 92% of all applications contain outdated or vulnerable code. We have seen the impact of this inability of organizations to maintain their OSS code through attacks like the one perpetrated against Apache Struts software run by credit reporting company Equifax, a breach that exposed the sensitive personal and financial information of hundreds of millions of Americans.
In recognizing that OSS is a fruitful channel for attacks, attackers have focused more specifically on the supply chain because it is often the weakest link. Elements of the supply chain reside in the gap between responsible organizations and may be less strictly policed or less actively secured. Continuous Integration / Continuous Deployment tools, OSS libraries that can easily access other systems, package managers and open source developer tooling are all components of the supply chain that are widely used but often the responsibility of many or of part-time maintainers who write and maintain code as an unpaid avocation.
OSS-Specific Challenges
The three key benefits of OSS each create unique security and supply chain challenges. Specifically, OSS is open, free and transparent.
The Two Sides of Open
Linus Torvalds said that many eyeballs make all bugs shallow. To a degree this is true. But what if those same eyes are looking for bugs to exploit rather than fix? Not everyone on the Internet is nice and many seek to exploit the fact that anyone with a GitHub account can contribute code to critical libraries. This attracts a lot of great contributors but also a lot of bad actors and bad behavior.
The behavior is often hidden or delayed. For example, we often see bad actors ask to contribute to projects or libraries run by single maintainers that are relatively popular and used by big applications. Often maintainers struggle to keep up with the demands of these projects. A bad actor will offer to help, submit a handful of good PRs and gain commit privileges to the repository. At this point, the bad actor will then stealthily insert malware, such as a cryptojacking script.
Free Puppy. Not Free Beer.
Free is a good price. There are no purchase orders. This makes it super easy to use. Free also serves as a great distribution strategy. However, sometimes free is not worth it. If an organization depends on an application and it becomes critical, they might require fast patching, better compliance and official support relationships. Free OSS comes with no guarantee and this can be a major liability. An application’s maintainers might be writing the code and applying fixes in their spare time on weekends because they have a full-time job. In fact, research has shown that a significant percentage of the critical software powering the Internet is maintained by volunteers; this was the source of the Heartbleed vulnerability in the OpenSSH encryption libraries.
Free code also may not be updated for years. If a vulnerability is disclosed, you may not be able to get permission to merge fixes you write. If the code is abandoned and the author no longer checks comments or requests, then you are stuck and may have no choice but to fork the project. A hard fork on short notice can cause chaos and its own problems. This is what happened with a popular Golang library called JWT Go, which made its way into dependency trees across the Golang ecosystem. JWT Go was even included in Kubernetes, one of the most popular and important open source projects. When a vulnerability to JWT Go emerged, everyone realized the maintainer had abandoned it. Multiple forked versions emerged with different patches for the same bug. Chaos ensued.
It is a common refrain to ask companies to fund volunteer maintainers. There are numerous programs for this, including GitHub Sponsors, Open Collective and Tidelift. These programs are helpful but not sufficient. You can’t just hand people a small amount of money and get more secure code and professional grade maintenance. Even if you offered full-time salaries, it might not translate into well supported, secure code.
The Illusory Benefit of Transparency
Transparency of OSS is real but the idea that this code is getting audited and reviewed constantly is an illusion. Yes, the source code is distributed and open. But the sheer quantity makes it impossible to review all the code you use. If you are using millions and tens of millions of lines of code, you don’t have time or sufficient eyeballs. Even if you are spending considerable resources on code review, it is still easy to miss problems and vulnerabilities and relatively simple for malicious contributors to projects to hide malware or other bad inclusions. Reviewing the source code also does eliminate all risks. When most OSS code is consumed, it is running as a package compiled by another entity or developer.
Further, there is no guarantee that the contents of the package comes from the same source code you audited. We have actually seen this attack often with package repositories like npm and Maven, where malicious actors insert tampered builds or take over packages and insert code that is not listed as part of the package.
The CodeCov incident is one of the more recent and egregious examples. This free service for checking the code coverage of unit tests used BASH script running inside of a CI server for installation. The script. Was compromised and attackers inserted malware that could steal code secrets and export them. Those secrets might be tokens used to publish packages in npm or Maven and exposing those secrets allowed attackers to then compromise those packages. In another example, a PHP server managing source code distribution for the PHP project was compromised and multiple commits injected malicious code into the source code repository. The incident was caught quickly but it demonstrated how attacker could tamper with source code directly, bypassing code review and security processes.
All Is Not Lost
Innovative efforts to better secure open source and its supply chain are gaining momentum. The SBOM is gaining acceptance and it is getting easier to automatically generate SBOMs from CI/CD pipelines or build systems. A new initiative to make it easy to cryptographically sign code, called Sigsource, aims to remove barriers to code signing; ubiquitous code signing would make it much harder to compromise the supply chain by attacking the source code provenance problem at its root. Lastly, the Open Source Security Foundation has garnered tens of millions of dollars in funding from major technology companies and it is in the process of spinning up mechanisms to issue grants and otherwise provide a more robust financial support mechanism for OSS. These developments point to a brighter future where the OSS Supply Chain is far more robust and companies can more easily audit, track and trust all the OSS dependencies in their applications and the full supply chain that moves OSS code from developer boxes up into production environments.
To view this and other recorded sessions from the Secure Software Summit, visit: https://www.techstrongevents.com/Secure-Software-Summit.
To get a demo of static analysis of custom code, open-source dependencies, and secreets, visit shiftleft.io/request-demo/.
Top comments (0)