The most important way to protect supply chain threats? Scan code for security vulnerabilities, learn how to find vulnerabilities in code, and quickly patch them with dynamic code analysis tools.
This is part three in our series on DevSecOps and software security. Looking for more? Join our upcoming security webcast with Maya and Jonathan Kohler, Technical Director of Engineering at Nutanix, on September 10.
Do you really know what’s in your software?
Today, open source is everywhere—in almost all proprietary codebases and community projects. For organizations, the question isn’t if you are or aren’t using open source code. It’s what open source code you’re using, and how much. If you aren’t aware of what’s in your software supply chain, an upstream vulnerability in one of your dependencies can affect your application, making you susceptible to a potential compromise. In this post, we’ll dig into what the term “software supply chain security” means, why it matters, and how you can help secure your project’s supply chain.
Traditionally, a supply chain is anything that’s needed to deliver your product—including all the components you use. For a chocolate bar you buy at the store, it’s the list of ingredients, the packaging, the information on nutritional contents, and maybe information on organic ingredients or production facilities. But it’s also more than that: it’s anything that can affect your delivery of that product, too. A chocolate bar that isn’t refrigerated as it travels through a hot climate will also affect the end product that’s consumed.
Swapping from chocolate to codebase, a software supply chain is anything that goes into or affects your code from development, through your CI/CD pipeline, until it gets deployed into production. It’s anything and everything that goes into your software, like code, binaries, and other components, and where they come from, like a repository or a package manager. Your software supply chain includes: who wrote it, when it was contributed, how it’s been reviewed for security issues, known vulnerabilities, supported versions, license information—everything that touches it at any point! Your supply chain also encompasses other parts of your stack beyond a single application, including your build and packaging scripts or the software running the infrastructure your application runs on. A software supply chain also includes any information you want to know about the software you’re running to help you determine any risks in running it.
Why does a software supply chain matter for security? Today, software dependencies are pervasive. It’s common for your projects to use hundreds of open source dependencies—203 per repository on average—that you didn’t write the whole functionality yourself. Industry data suggests that 99 percent of codebases contain open source code, and anywhere from 85 to 97 percent of enterprise codebases come from open source. This means that most of your application consists of code that you didn’t write. The vulnerabilities in your third-party or open source dependencies, which presumably you can’t control as tightly as the code you wrote, create significant potential security risks.
If one of these dependencies has a vulnerability, then chances are you have a vulnerability as well. What’s scary here is that a dependency might change without you knowing it—even if a vulnerability exists in a dependency today but isn’t exploitable in your application, changes inside or outside of your codebase may make you susceptible in the future. Being able to leverage the work of thousands of open source developers means that thousands of strangers effectively have commit access to your production code. So an unpatched vulnerability, an innocent mistake, or a malicious attack to a dependency in your supply chain can affect you deeply.
A software supply chain attack occurs when malicious code is purposefully added to a component, using the supply chain of that component to distribute the code to their targets. Supply chain attacks are real. There are several methods to attack a supply chain, from directly inserting malicious code as a new committer, to taking over a committer account to do so without others noticing, or compromising a signing key to distribute software that isn’t officially part of a component. However, a software supply chain attack in and of itself is rarely the end goal. Rather, it’s an opportunity to insert malware for cryptomining, or insert a backdoor for botnet access.
Software supply chain attacks remain rare, with fewer than tens of compromises a year (that we know of). They also tend to be highly targeted; for example, nation states attacking energy sector companies, and so not a widely applicable peril. To date, broad attacks on open source security remain uncommon.
Probably the best known example of a software supply chain attack is to event-stream, a widely used Node.js library available via npm. In the fall of 2018, a new user volunteered to take over event-stream on GitHub.The author welcomed the extra help and even gave the newcomer publishing rights. A few weeks later, the new user added a new dependency to event-stream, flatmap-stream. Then the next week, that same user rewrote the code to no longer require the flatmap-stream dependency, and tried to remove it. That change was made in the codebase, but unfortunately wasn’t pushed through to where the library is hosted on npm. In October, another user added malware to flatmap-stream. Anyone who then used event-stream and pulled in the latest version of flatmap-stream would receive this malware. It’s important to emphasize that the library author is not to blame here—who doesn’t have an open source project that would welcome extra help?
Even though direct supply chain attacks like event-stream are rare, unpatched software is not. The use of open source in enterprises today is significant and isn’t expected to slow down—open source has won. Given we’re not going to stop using open source software (and we shouldn’t!), the threat today to supply chain security is unpatched software. Knowing that, how can you address the risk that a dependency of your project has a vulnerability?
Fortunately, it’s estimated that 85 percent of vulnerabilities in open source are disclosed with a patch already available, so all you have to do is apply the patch to stay secure. But being proactive and successful at addressing software supply chain threats goes beyond patching. Following DevSecOps means you need to approach security as an ongoing part of software development, which also means you need to regularly know what dependencies you use, know about vulnerabilities in those dependencies, patch them—then get back to work! As a developer, that means having a few capabilities:
We’re only a few steps along the journey of securing our software supply chains, but there’s more to get excited about beyond patching dependencies. There are a couple of ideals the industry is striving towards to increase trust in the supply chain, including ensuring integrity and verifying provenance. Supply chain integrity is about ensuring a component is what it says it is—that you can trust the ingredients listed on the chocolate wrapper. For example, this could be achieved using reproducible builds. Provenance is about knowing where a particular component came from, so that you can trust the provider of that component or metadata on that component; for example, with signed builds or transparency logs. These are closely related to the concept of a software bill of materials (SBOM), which would give you a list of the components in your software like a verified list of ingredients from the chocolate manufacturer.
Our goal is for GitHub to lead and enable developers, maintainers, enterprises, and researchers in securing the world’s software. To do that, we’re investing to ensure the open source community has the tools they need to secure their software, and making it easy for developers and enterprises to manage what dependencies they consume.
As a developer, understanding and maintaining dependencies is the first step. This is usually achieved with software composition analysis (SCA), the set of tools which help you determine what dependencies you use, discover vulnerabilities in those dependencies, and patch them—that is, exactly what we’ve been talking about. On GitHub, SCA capabilities are provided by a few features:
To recap, a software supply chain is anything that goes into or affects your code. Even though supply chain compromises are real and growing in popularity, they’re still extremely rare—and so the most important thing you can do to protect your supply chain is patch your vulnerabilities. Then to successfully secure your software supply chain, you need to understand the dependencies in your environment, know about vulnerabilities in those dependencies, and quickly patch them. Enable GitHub-native SCA capabilities: dependency graph, Dependabot alerts, and Dependabot security and version updates to automate the hard work of dependency management and patching.
Want to see how supply chain security looks like in practice? Join me and Jonathan Kohler, Technical Director of Engineering at Nutanix, for our next GitHub webcast on September 10. We’ll dive into understanding your supply chain, your dependencies, and how Nutanix builds a secure supply chain with GitHub.
When
September 10, 2020
11:00 am PT / 2:00 pm ET
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
With push protection now enabled by default, GitHub helps open source developers safeguard their secrets, and their reputations.
Maya Kaczorowski 
