For years, the security conversation around software distribution centered on a single question: is this binary signed? A valid digital signature was treated as the seal of trust, the proof that an artifact came from who it claimed to come from and had not been altered. That assumption was always incomplete, and the supply chain attacks of the past several years have exposed exactly how incomplete it was.
The uncomfortable reality is that a signature only proves the last step. It confirms that whoever held the signing key approved the final artifact. It says nothing about whether the source code that went into that artifact was the code the developers actually wrote, whether the build environment was compromised, or whether a malicious step was injected somewhere between the commit and the compiled output.
This is the gap that the Supply-chain Levels for Software Artifacts (SLSA) framework is designed to close, and SLSA Level 3, in particular, is where code signing helps create a verifiable chain of custody that spans from source to binary. This blog explains what SLSA Level 3 requires, how it works hand in hand with code signing, and how organizations can build the verifiable provenance that modern software supply chain security depends on.
Why Is a Signature Alone No Longer Enough?
To understand why SLSA matters, it helps to be precise about what a code signature does and does not prove. When a binary is signed, the signature establishes two things: that the artifact was approved by an entity holding the corresponding private key, and that the artifact has not been modified since it was signed. Both of those guarantees are valuable, and code signing remains an essential security control.
But it does not prove that the source code compiled into the binary matches the source code in your repository. It does not prove that the build ran in a clean, uncompromised environment. It does not prove that no unauthorized build step injected additional code along the way. And it does not prove that the person or system that triggered the signing operation was authorized to release that particular artifact. A signature is a statement about the final object, not about the journey that produced it.
The most damaging supply chain attacks exploit precisely this blind spot. They do not attack the signature, because attacking the signature is hard and well defended. Instead, they attack the build process upstream of the signature, so that malicious code flows through the legitimate pipeline and emerges with a perfectly valid signature attached. The signature is real but the trust it conveys is misplaced, because the thing being signed was already corrupted before it reached the signing step.
What organizations need, and what consumers of software increasingly demand, is verifiable evidence about the entire production process, not just the final approval. They need to be able to answer questions like: which exact commit produced this binary, what build platform compiled it, what inputs went into it, and can all of that be cryptographically proven rather than simply asserted. That body of verifiable evidence is called provenance, and generating tamper-resistant provenance is the core purpose of the SLSA framework.
What Is SLSA and Why Does It Exist?
SLSA stands for Supply-chain Levels for Software Artifacts and is a vendor-neutral security framework that was originally proposed by Google in 2021 and is now maintained as a project under the Open Source Security Foundation (OpenSSF). Its purpose is to provide a common, industry-agreed set of standards for describing and verifying how software artifacts are built, so that both producers and consumers can reason about supply chain integrity using a shared vocabulary.
The framework is built around a single central concept: provenance. Provenance is verifiable metadata that records where, when, and how a software artifact was produced. A complete provenance record identifies the source repository and exact commit, the build platform that performed the build, the inputs and parameters that went into it, and a cryptographic digest of the resulting artifact. When this provenance is generated by a trusted build system and signed in a way that the build steps themselves cannot tamper with, it becomes tamper-evident proof of how the artifact came to exist.
It is important to be clear about what SLSA is and is not. SLSA is not a tool, a scanner, or a product that you install. It is a specification that defines what “secure” looks like at progressive levels of maturity, and it is designed to be enforceable automatically through policy engines. It also complements rather than replaces other security practices. Vulnerability scanning identifies known weaknesses in code and dependencies, while SLSA verifies that the build itself was not tampered with. The two address different threats and are strongest when used together.
The framework has evolved meaningfully. SLSA v1.0 was released in April 2023 and focused the specification on the Build Track with levels 0 through 3. SLSA v1.1 was officially approved in April 2025, tightening the precision of the requirements and converting several earlier recommendations into stricter normative requirements. SLSA v1.2, which introduced the Source Track addressing the integrity of the source code itself, followed in November 2025. The framework continues to mature, but the Build Track remains the stable, widely adopted foundation, and it is where the relationship with code signing is most direct.
The SLSA Build Track defines four cumulative levels, numbered 0 through 3. Each level builds on the one below it, which means that meeting Level 3 requires also satisfying the requirements of Levels 1 and 2. This cumulative structure is deliberate, because it allows organizations to adopt SLSA incrementally rather than attempting a complete overhaul of their build pipelines all at once.
| Level | Core Requirement | Primary Threat Addressed |
|---|---|---|
| Level 0 | No provenance at all | No protection; no verifiable evidence of how artifacts were built |
| Level 1 | Provenance exists, describing how the artifact was built | Accidental distribution of wrong versions; basic traceability |
| Level 2 | Provenance is signed and generated by a hosted build platform | Prevents the build tenant from falsifying provenance |
| Level 3 | Hardened, isolated build platform with signing secrets inaccessible to build steps | Prevents forged provenance even from compromised credentials or insider threats |
What Does SLSA Level 3 Actually Require?
SLSA Level 3 introduces two demanding requirements that go well beyond simply signing provenance. Understanding them precisely is the key to understanding how Level 3 builds a genuine chain of custody.
The first requirement is build isolation. The build steps must run in an isolated environment that cannot be influenced by other build processes, and that environment must not be reused between builds. In practice this means ephemeral, sandboxed environments such as freshly created containers or virtual machines that are provisioned specifically for a single build and then destroyed. This isolation prevents one build run from interfering with another, even within the same project, which closes the door on a whole class of attacks where a compromised build contaminates subsequent builds.
The second and most consequential requirement is that provenance must be unforgeable. It must be impossible for the build platform’s own users, including the people who define the build steps, to falsify provenance information. This is achieved by ensuring that all provenance is generated by the build service inside a trusted control plane, and critically, that the secret material used to sign the provenance is never accessible to user-defined build steps. The signing keys belong to the build platform, not to the build configuration that users control.
This second requirement is what makes Level 3 so powerful, and it is where the connection to code signing becomes structural rather than incidental. At Level 3, even a malicious insider who has full access to the build configuration cannot forge provenance, because the signing key that vouches for that provenance lives in a part of the system the insider cannot reach. The signature on the provenance is therefore a trustworthy statement about the build, not something a compromised build step could have manufactured.
The result is that Level 3 provenance answers the questions a signature alone cannot. It does not just say “this artifact was approved.” It says “this artifact was built from this exact source commit, on this hardened platform, through this process, and here is cryptographic proof generated by a system that the build steps themselves could not have tampered with.”
How Encryption Consulting Can Help
Building a verifiable chain of custody from source to binary brings together exactly the disciplines that define Encryption Consulting’s expertise: protecting signing keys, governing how they are used, and producing the auditable evidence that both security and compliance now demand. The connection between SLSA Level 3 and code signing is not incidental, because both ultimately rest on the integrity of the signing infrastructure, and that is where our work is focused.
Our CodeSign Secure platform provides the signing foundation that a Level 3 chain of custody depends upon. It protects private signing keys inside FIPS 140-3 and FIPS 140-2 Level 3 validated hardware security modules (HSM) from vendors including Thales, Entrust, Utimaco, and Securosys, so that the key material used to sign both artifacts and provenance never exists in software form and cannot be extracted by a compromised build step.
This directly addresses the SLSA Level 3 requirement that signing secrets remain inaccessible to user-defined build steps. The platform enforces role-based access control over who can request and approve signing operations, applies RFC 3161 timestamping so signatures remain verifiable across the long lifecycle of released software, and records every signing event in an immutable audit trail that captures what was signed, when, by whose authority, and through which pipeline stage.
That audit trail is the verifiable evidence that turns a claim of build integrity into something a consumer or regulator can actually check. Because CodeSign Secure integrates directly into CI/CD platforms including Azure DevOps, Jenkins, and GitLab, signing becomes a governed, policy-enforced stage in the pipeline rather than a manual step, which is precisely the model that SLSA’s automated, build-platform-driven approach requires.
Beyond the platform itself, our advisory teams help organizations design the broader architecture that a verifiable chain of custody requires, from assessing the current maturity of your build and signing pipeline against the SLSA levels, to structuring the key management and isolation controls that Level 3 demands, to aligning the resulting evidence with the regulatory frameworks such as the NIST SSDF, Executive Order 14028, and the EU Cyber Resilience Act that increasingly expect it.
For organizations that also need the underlying hardware key protection delivered as a managed capability, our HSM as a Service offering provides FIPS-validated, vendor-agnostic key protection that can anchor both artifact signing and provenance signing without the burden of operating the hardware in house.
Conclusion
The time where a valid signature was sufficient proof of software trustworthiness has ended. The most damaging supply chain attacks of recent years did not break signatures; they corrupted the build process upstream of signing, so that malicious code emerged with a perfectly legitimate signature attached. Closing that gap requires verifiable evidence about the entire journey from source to binary, and that is what SLSA, and SLSA Level 3 in particular, was designed to provide.
The relationship between SLSA Level 3 and code signing is the key insight. They are not competing approaches but complementary layers of a single chain of custody. Provenance establishes how an artifact was built and proves it could not have been forged even by an insider, while code signing establishes that the artifact and its provenance are authentic and unaltered.
As regulatory frameworks increasingly demand verifiable rather than self-asserted build integrity, and as enterprise and government buyers begin requiring minimum SLSA levels as a condition of procurement, the ability to produce a verifiable chain of custody for every binary is moving from a security ideal to a business necessity. The organizations that build this capability now, starting with the signing foundation and working incrementally toward Level 3, will be the ones positioned to prove, not merely promise, that their software can be trusted.
At Encryption Consulting, our CodeSign Secure platform and advisory services are built to provide that foundation. If you are working toward a verifiable chain of custody for your software supply chain, we would be glad to help.
