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 in CI/CD, and how organizations can build the verifiable provenance that modern software supply chain security depends on.
Code signing alongside SLSA Level 3, defined: pairing SLSA Level 3’s own requirement, an isolated, ephemeral build environment plus provenance that only the build platform’s trusted control plane can sign, with a separately governed artifact-signing layer, HSM-backed keys, short-lived workload identity, and M-of-N approval, that Encryption Consulting recommends as a complementary practice rather than something SLSA itself mandates.
Key Takeaways
- SLSA Level 3 requires the build platform’s own provenance-signing secret to be inaccessible to user-defined build steps, and requires an isolated, non-reused build environment. It does not, by itself, require HSM-backed product code signing, M-of-N approval, or OIDC-based workload identity; those are valid complementary controls, not normative SLSA requirements.
- A secrets-free signing stage uses short-lived, workload-scoped identity (OIDC token exchange) instead of a static API key sitting in pipeline variables indefinitely.
- Approval gates (M-of-N) should apply to production-tier releases, not every internal build, so velocity on lower-risk artifacts isn’t sacrificed for compliance theater.
- Verification is a separate, mandatory step: a downstream gate checks both the artifact signature and the SLSA provenance attestation before an artifact is promoted.
- A rejected or failed signing request should hard-block the release; rollback after the fact means revoking trust in the artifact, not deleting it.
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. It’s worth being precise about which secret this is: it’s the provenance-signing secret held by the build platform’s own control plane (for example, a hosted CI provider’s internal Sigstore-based signer), not necessarily an organization’s own HSM-protected code-signing key used to sign the product artifact itself. SLSA does not specify how that provenance-signing secret must be protected, whether by HSM, software vault, or another mechanism, only that user-defined build steps cannot reach it.
This second requirement is what makes Level 3 meaningful, and it is where a well-governed code-signing practice becomes a natural, complementary addition, though SLSA itself does not prescribe how an organization’s separate code-signing keys must be managed. 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.”
Implementing Code Signing in CI/CD for SLSA Level 3
Everything above explains what SLSA Level 3 itself requires: an isolated build environment and unforgeable, platform-generated provenance. This section describes Encryption Consulting’s recommended architecture for building a genuinely trustworthy pipeline around that baseline, HSM-backed artifact signing, workload identity, and approval gates. These controls strengthen the overall chain of custody and are strongly recommended, but they are supplementary security practices layered on top of SLSA, not literal SLSA Level 3 requirements. For a broader look at why code signing belongs in CI/CD in the first place, see Using Code Signing in CI/CD Pipelines; what follows here is specifically the isolation, identity, and approval architecture that Level 3 demands on top of that.
Prerequisites
Before wiring Level 3-grade signing into a pipeline, confirm the following are in place:
- A CI/CD platform that supports OIDC or workload identity federation for its runners (GitHub Actions, GitLab CI, Azure DevOps, and Jenkins with the appropriate plugin all support this today).
- An HSM-backed signing service reachable from the pipeline over an authenticated API or CI/CD plugin, so the private key never enters the runner’s filesystem or environment.
- A defined set of named approvers and a quorum policy (M-of-N) for production-tier signing requests.
- A provenance generator compatible with the in-toto attestation format; most hosted CI providers’ native build-provenance features and the SLSA reference implementations both produce this.
- A verification gate downstream, in the deployment pipeline or at the point of consumption, capable of checking both the artifact signature and the provenance attestation before promoting a build.
Reference Architecture
A Level 3-capable pipeline has the same shape regardless of which CI platform runs it:
- Source control triggers the pipeline; the commit and branch identify the workload for identity federation.
- The CI orchestrator provisions a fresh, isolated build environment, a container or VM created for this build only and destroyed afterward, satisfying the Level 3 isolation requirement.
- The build produces the artifact and its content digest inside that isolated environment.
- The pipeline requests signing through an authenticated call to the HSM-backed signing service; the private key stays behind that service’s boundary at all times.
- The signing service checks RBAC and, for production-tier releases, an approval quorum, before performing the key operation.
- The CI platform’s trusted control plane, not a user-defined build step, generates the SLSA provenance attestation and has it signed the same way.
- The signed artifact and its signed attestation are published together to the artifact registry.
- A downstream verification gate checks both before the artifact is promoted to the next environment.
Least-Privilege Service Identity
Static, long-lived API keys or service-account passwords stored as CI/CD secrets undermine the same isolation goal that SLSA Level 3’s provenance-signing requirement is built on, even though SLSA’s specific text addresses only the build platform’s own provenance-signing secret. Extending that same protection to code-signing and other pipeline credentials is a recommended complementary practice. The safer pattern is workload identity federation: the CI job authenticates using a short-lived OIDC token scoped to that specific repository, branch, and job, which is exchanged for a narrowly scoped, time-limited credential at request time rather than a standing secret sitting in pipeline configuration indefinitely.
- Scope the token to the specific repository, branch, and job, not the whole organization or account.
- Match token lifetime to the pipeline run’s duration rather than issuing something that outlives the job.
- Use a separate identity per environment or tier, so the identity used for a development build is not the same one authorized to request a production signature.
Secrets-Free HSM-Backed Signing
The build job never receives, stores, or handles the private key or a static signing credential at any point in this model. It authenticates with its short-lived workload identity, submits a signing request describing what needs to be signed, and receives back a signature or a signed and attested artifact. The private key operation happens inside the HSM, gated by the policy layer described below; no build script has a code path that could exfiltrate the key, because the key was never reachable from that script’s execution context in the first place.
Approval Gates
Approval policy needs to be defined deliberately rather than applied uniformly:
- Which release tiers require M-of-N approval, typically production-facing artifacts, while internal or development builds can sign automatically under a looser policy.
- Who the eligible approvers are for each tier, mapped to groups in the existing identity provider rather than a hardcoded list in the pipeline config.
- What happens on approval timeout: whether the pipeline fails closed or falls back to a slower, explicitly manual path.
- Whether the approval requirement is enforced by the signing service’s own policy engine rather than by pipeline logic a modified build step could bypass.
Sample Workflow
Put together, a single release run through this architecture looks like this:
- A commit triggers the pipeline in a freshly provisioned, single-use build environment.
- The build compiles the artifact and computes its content digest.
- The build job authenticates to the signing service using a short-lived, workload-scoped OIDC token.
- The signing service checks the requester’s identity and role against policy; for production-tier releases, it opens an M-of-N approval request.
- Once approved (or immediately, for lower-risk tiers), the HSM performs the signing operation; the private key never leaves the HSM boundary.
- The CI platform’s trusted control plane generates a SLSA provenance attestation describing the source commit, build platform, and inputs, and that attestation is signed the same way, inside the HSM, not by a user-defined build step.
- The signed artifact and its signed attestation are published together to the artifact registry.
- A downstream verification gate checks both the artifact signature and the attestation before the artifact is promoted to the next environment.
Verification
Signing is only half the control; verification is what makes it enforceable rather than advisory. A deployment gate, or an external consumer, should independently confirm two things before trusting an artifact: that the signature is valid and chains to an expected key, and that the accompanying SLSA provenance attestation is present, correctly signed, and describes a build that matches policy, expected source repository, expected build platform, no unexpected parameters. The SLSA project’s own slsa-verifier is the reference tool for checking provenance attestations against policy, and Sigstore’s cosign verify-attestation performs the equivalent check for container images bound to the image digest. Both are designed to run as a required, non-bypassable pipeline stage rather than an optional audit step.
Failure Handling and Rollback
A signing request should fail closed. If the approval quorum isn’t met, if the HSM is unreachable, or if the identity token fails validation, the pipeline stops and the artifact is not published, not signed with a fallback key and shipped anyway. Rollback in this model means revoking trust in an already-distributed artifact, not deleting it: revoke or blocklist the specific key version or certificate used to sign it, and update the verification policy so that artifact’s signature no longer passes the gate described above. Because the audit trail records exactly which key, approver, and pipeline run produced the artifact, identifying what needs to be revoked after an incident doesn’t require reconstructing the timeline from scattered logs.
Audit Evidence
The evidence an auditor or verifier actually needs is the pairing of two records for every release: the signing event log (what was signed, under which policy, approved by whom, at what time) and the provenance attestation (which commit, which build platform, which inputs). Neither is sufficient alone, the signing log proves authorization; the attestation proves what was actually built. Centralizing both under one HSM-backed platform means an auditor gets a single, consistent source of evidence across every pipeline and artifact type, rather than reconciling logs pulled from several disconnected build systems.
Troubleshooting
| Symptom | Likely Cause | What to Check |
|---|---|---|
| Signing request rejected | Approval quorum not met, or the requester’s identity token scope doesn’t match the job’s repo/branch | Confirm the token audience/scope and the configured approver group for that release tier |
| Attestation verification fails downstream | The attestation was generated by a build step instead of the CI platform’s trusted control plane, or the build ran in a reused, non-isolated environment | Confirm the CI platform’s native attestation feature is enabled and the runner is ephemeral, per the Level 3 isolation requirement |
| Signature valid but provenance missing | Signing and attestation are two separate calls in the pipeline, and one was skipped or failed silently | Make attestation generation and signing atomic, or add a required gate that checks both are present before publish |
| OIDC token exchange fails intermittently | Token lifetime too short for a long-running build, or clock skew between the runner and the identity provider | Extend token lifetime to match job duration, and verify time sync on self-hosted runners |
SLSA Build Track: What Changes Between Level 2 and Level 3
| Aspect | Level 2 | Level 3 |
|---|---|---|
| Build environment | Hosted build service | Hosted build service, ephemeral and isolated per build |
| Provenance generation | Signed by the build platform | Signed by the build platform’s control plane; unforgeable even by build configuration |
| Signing secret access | Held by the build platform, may be indirectly reachable | Never accessible to user-defined build steps (the SLSA requirement); HSM protection for an organization’s own code-signing key is a recommended, separate addition, not itself an SLSA mandate |
| Insider threat coverage | Not addressed | Addressed; an insider with build config access cannot forge provenance |
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 supports the same underlying goal as the SLSA Level 3 requirement that provenance-signing secrets remain inaccessible to user-defined build steps, applying equivalent protection to the organization’s own code-signing keys as a complementary control. CodeSign Secure’s HSM backing is not itself the SLSA Level 3 requirement, which concerns the build platform’s own provenance-signing secret; it is a recommended practice that strengthens the broader chain of custody alongside it. 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.
Frequently Asked Questions
What does “code signing in CI/CD” mean at SLSA Level 3, specifically?
SLSA Level 3 itself only requires that the build platform’s own provenance-signing secret be inaccessible to user-defined build steps, generated inside its trusted control plane. Extending that same protection, HSM-backed keys, no static secrets, workload identity, to the organization’s own code-signing operation is a recommended complementary practice, not a literal part of the SLSA specification.
Do all builds need M-of-N approval before signing?
No. Approval gates are typically scoped to production-tier releases; lower-risk internal or development builds can sign automatically under a looser policy, which keeps velocity high without weakening controls on the artifacts that actually ship.
What tool verifies SLSA provenance after signing?
The SLSA project’s own slsa-verifier is the reference tool for checking provenance attestations against policy. For container images, Sigstore’s cosign verify-attestation performs the equivalent check bound to the image digest.
What happens if a signed artifact needs to be revoked after release?
The specific key version or certificate used to sign it is revoked or blocklisted, and the verification policy is updated so that artifact’s signature no longer passes the gate. The audit trail identifies exactly which key, approver, and pipeline run to target.
Is SLSA Level 3 the same thing as code signing?
No. Code signing proves an artifact is authentic and unaltered since signing. SLSA Level 3 proves the build process that produced the artifact could not have been tampered with, even by someone with access to the build configuration. They are complementary controls, not substitutes for each other.
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.
