Software supply chain security has rocketed into the public consciousness after a major cybersecurity attack against the U.S. federal government was made public in late 2020. In this post, we’ll go over the history of the response to that attack, how that’s impacted the U.S. government as well as anyone who produces software, a community-developed framework for how to think about this problem holistically, and how to use GitHub, particularly, to improve the security in the second half of your software supply chain.
An abridged history
In late 2020, details of a major cyberattack against the U.S. federal government were made public. Like many cyberattacks, it made use of malware, but what was novel about this attack is that the malware was included in a widely-used security product during the build process. That way the malware was not visible to employees accessing the product’s codebase, and the targets were already regularly installing and updating the product.
Because of how powerful and effective this attack was, it set off a wave of responses across the U.S. government and private industry, starting with a May 2021 White House Executive Order on Improving the Nation’s Cybersecurity with section 4 detailing (using letters “a” through “x”!), steps to enhance software supply chain security.
For the sake of brevity we won’t detail the entire U.S. federal response, but fast forward to 2024 and software supply chain security is an ongoing concern. In May 2024, the White House released v2 of the National Cybersecurity Strategy Implementation Plan with initiative 5.5.4 calling to “promulgate and amplify Cybersecurity Supply Chain Risk Management (CSCRM) key practices across and within critical infrastructure sectors.” In August 2024, the Office of the National Cyber Director summarized feedback it received from the open source community and private sector into 12 activities to address in the coming year, including “(5) Strengthen the software supply chain.”
These recommendations aren’t just for U.S. federal agencies. Companies selling cloud services to the U.S. government need to comply with frameworks like FedRAMP, which uses the NIST 800-53 control system and hopefully at this point you aren’t surprised that it includes “PM-30: Supply Chain Risk Management Strategy.”. But even companies who aren’t selling to the U.S. government it’s a good idea to have internal policies around software supply chain security management, which can then provide evidence of compliance for SOC2 or ISO 27001 audits.
What does software supply chain mean?
Hopefully, I’ve convinced you that having a plan for securing your software supply chain is a good idea. But what does that look like in practice? How do you get started?
The Open Source Security Foundation (OpenSSF), which itself is part of the Linux Foundation, brings together people who produce and use open source code to improve security practices. There are several frameworks for thinking about software supply chain security, but the one I’ve found most user-friendly comes from the OpenSSF called Supply-chain Levels for Software Artifacts (SLSA). If you’ve been to a software security conference since 2020, you’ve probably seen this project’s depiction of the software supply chain:
As you know, producing software is a complex process, and a lot can go wrong along the way. At GitHub, we’ve previously written about practices for writing secure code and handling dependencies, so here we’re going to focus on the second half of the software supply chain: ensuring the integrity of our build and making sure the software consumers run hasn’t been tampered with.
I could hardly say it better than the U.S. Cybersecurity and Infrastructure Security Agency in their Defending Against Software Supply Chain Attacks publication:
Providing a mechanism for verifying software release integrity (in particular, the protection of the code signing certificate) to help customers ensure that the software they acquire has not been subjected to tampering.
Using GitHub
Code signing is hardly new, but many implementations are full of pitfalls and usability hurdles. Securely managing private key material is tricky, and many systems don’t have any way to recover if your private key is accidentally made public. GitHub built artifact attestations to make it deadsimple for you to sign any software you build in GitHub Actions. It uses the workload identity available via the Actions OIDC token to securely obtain a code signing certificate. You don’t need to manage a long-lived private key, and key rotation is built into the service. To use it you just need to add a workflow step to do the signing, and you can use the gh CLI to verify the signatures, including offline verification support.
If you’re just looking for an easy way to get started with signing and verifying builds, you can stop here. But there are some more advanced features in artifact attestations that you might also be interested in as you continue your security journey.
To explain, let’s go back to the SLSA framework, in particular the build track. Using artifact attestations rockets you from level 0 (not having anything) to level 2 (signed provenance). Provenance is more than just a signature over the bytes of your build. Because the code signing certificate is obtained with the workload identity of the build, there’s a lot of additional useful information in that certificate: the exact repository the build came from, the path to the build instructions, the exact SHA of the source code and build instructions, what branch the build came from, and how the build was triggered. When you’re using the gh CLI to verify the build signature, the least amount of information you can provide is what owner or repository the build came from. But you can additionally enforce policy on any of these fields, like requiring that builds come from branches that are protected by rulesets.
In fact, SLSA build track defines a level 3 where the build takes place in an isolated environment with controlled inputs. On the GitHub platform, this maps to having your build take place in a reusable workflow where your organization has vetted the build instructions, and then when verifying artifact attestations specifying which workflows you allow builds to come from. To help, we’ve written up documentation specifically for using artifact attestations with reusable workflows.
Conclusion
Software supply chain security is an emerging and massive topic. Instead of trying to tackle everything at once, we recommend starting by signing your builds with artifact attestations and verifying those signatures before you run them. Even if your organization doesn’t require it today, it’s a good practice to get into and is something more consumers will be asking about in the near future. We’re here to grow along with you, and as your security needs mature, we’ll be ready to help you tackle more advanced capabilities.
Written by
