Supply Chain Security: What Comes After Code and Dependencies?
The 2020 SolarWinds attack was a turning point. Malware slipped into a widely used security product during its build process — invisible to developers and delivered through normal updates. The response was swift and broad, starting with a May 2021 White House Executive Order on Improving the Nation’s Cybersecurity. Section 4 alone ran 24 sub-items covering steps to shore up software supply chain security.
That focus hasn’t faded. In May 2024, the White House’s v2 of the National Cybersecurity Strategy Implementation Plan included a call to promote supply chain risk management practices across critical infrastructure sectors. A few months later, the Office of the National Cyber Director distilled community feedback into 12 activities for the coming year, one of which was to strengthen the software supply chain. Government customers also feel the pressure: cloud providers for the federal government must meet FedRAMP requirements, which rely on NIST 800-53 controls including PM-30: Supply Chain Risk Management Strategy. Even outside those mandates, internal supply chain policies make it easier to demonstrate compliance in SOC 2 or ISO 27001 audits.
Mapping the Problem with SLSA
The Open Source Security Foundation (OpenSSF), part of the Linux Foundation, has produced several frameworks to help developers think through this space. The most approachable is probably Supply-chain Levels for Software Artifacts (SLSA):
Software production is complex, and the second half of that process — the build and distribution stages — is where tampering and compromise often do their damage. The U.S. Cybersecurity and Infrastructure Security Agency puts it plainly:
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.
Code Signing Without the Key Management Headache
Code signing is a well-understood mitigation, but traditional implementations carry real burdens: managing private keys securely, and dealing with the fallout when a key leaks. GitHub’s artifact attestations attempt to remove that friction. The feature uses the workload identity from the Actions OIDC token to obtain a code signing certificate automatically. No long-lived private key to store or rotate. Adding it to a workflow is a single configuration step, and verification happens through the gh CLI, with support for offline verification.
Artifact attestations go beyond just proving the bytes haven’t changed. Because the certificate is tied to the build’s workload identity, it carries rich metadata: the repository the build originated from, the path to the build instructions, the exact SHA of the source and instructions, the branch, and the trigger event. When verifying a signature, you supply the owner or repository as a minimum, but you can also enforce policy on any of those fields — for example, requiring that builds come from branches protected by rulesets.
This maps conveniently to SLSA build levels. With artifact attestations you jump from level 0 to level 2 (signed provenance) almost immediately. SLSA build level 3 demands an isolated build environment with controlled inputs; on GitHub, that roughly translates to running builds in reusable workflows your organization has vetted, then confirming during verification that builds come from those allowed workflows. GitHub maintains documentation specific to that pattern.
A Practical Starting Point
Supply chain security is broad, and addressing it wholesale can be overwhelming. A more sensible entry point: sign every build with artifact attestations and verify those signatures before running anything. It won’t be a requirement for every organization today, but it’s becoming a common expectation — and the infrastructure is already there to start.
