TL;DR: Testifysec corrects an earlier SLSA Build Level 3 claim and shows that signed evidence, a hosted runner, and a passing verification job do not by themselves establish Build L3. The experiment is useful because it separates artifact binding from trust in the signing identity and build boundary.
At a glance
What this is: Testifysec’s corrected account shows that signed build evidence can prove artifact binding without proving SLSA Build L3.
Why it matters: For IAM, NHI, and platform teams, the key issue is who can obtain the signing identity, what the build boundary permits, and whether provenance truly reflects isolated execution.
Context
SLSA claims often fail when teams confuse a signed artifact with a trusted build boundary. A valid signature can show that a digest matches an attested subject, but it does not prove that the signing identity was isolated from the build or that provenance was generated under the expected predicate type.
This article sits at the intersection of software supply chain security and non-human identity governance because the build workflow used a hosted runner, OIDC identity, and short-lived certificates. Those controls reduce friction, but they also create questions about who or what can exercise the signing authority inside the pipeline.
The correction is typical of mature supply chain analysis: it narrows the claim to what the evidence actually supports instead of treating a successful verification step as proof of end-to-end assurance.
Key questions
Q: What breaks when a build pipeline can also reach signing authority?
A: The assurance boundary breaks because the same workflow can both produce the artifact and influence the attestation that validates it. That creates a trust loop where a successful CI job may still generate a valid-looking statement from an untrusted path. Separate execution from signing so artifact creation and attestation are not controlled by the same identity.
Q: Why do signed artifacts not prove SLSA compliance by themselves?
A: Signed artifacts prove that a digest or statement was authenticated, not that the build met the isolation, provenance, and identity boundaries required for SLSA. Compliance depends on the control model around the signer, runner, and provenance format. Without that separation, the signature can be real while the assurance claim remains overstated.
Q: How do teams know attestation-based identity is actually working?
A: Look for access decisions that depend on verified runtime evidence, not just token validity. You should also see sensitive credentials invalidated when image hashes, node state or signing trust changes. If drift does not change access, the attestation control is only decorative.
Q: What should security teams do when a workflow identity can obtain certificates?
A: Treat that workflow identity as a privileged non-human identity and review whether it has more authority than the build step requires. If it can request certificates or sign output directly, the issuance path needs tighter separation, stricter scoping, or a different trust boundary. Otherwise, the certificate becomes part of the attack surface.
Technical breakdown
Why provenance format and predicate type matter
SLSA provenance is only meaningful when the statement format and predicate type match the level being claimed. A build record can include evidence, SBOM data, and scan output, but the attestation still has to reflect the recognized provenance model for the level under review. If the workflow emits the wrong predicate type, the record may be useful for review while still falling short of the trust model needed for a higher SLSA assertion.
Practical implication: validate the provenance schema before you treat a signed statement as level evidence.
Hosted runners and build identity are not isolation
A hosted runner is not the same thing as an isolated signing boundary. If the same workflow identity can also obtain a certificate or otherwise access signing authority, then the build path and the trust path are coupled. That is a governance failure as much as a technical one, because the workflow can still produce a valid signature even when the signing function is reachable from the build step.
Practical implication: separate build execution from signing authority so the build cannot influence what gets attested.
Digest verification proves binding, not trustworthiness
Digest checks answer a narrow question: does the artifact match the attested hash? They do not answer whether the attestation itself came from a safe or properly constrained signer. In supply chain terms, artifact binding and signer trust are different controls. A verification job can reject a modified binary and still leave open the harder question of whether a compromised workflow could generate a different valid statement.
Practical implication: test both the hash binding and the signer access path in your verification design.
NHI Mgmt Group analysis
Artifact verification has become the easy part of supply chain trust. The harder problem is proving that the entity producing the signature was not reachable from the same execution path that produced the artifact. In NHI terms, the signing identity is a high-value workload credential, not a ceremonial proof object. Practitioners should treat provenance as evidence only after they have separated artifact production from attestation authority.
SLSA claims fail when teams confuse evidence collection with control separation. A workflow can gather SBOMs, scan results, and signed records while still lacking the boundary needed for a stronger assurance level. This is why the corrected account matters: it demonstrates that a green CI result is not equivalent to a trusted build system. Practitioners should align the claim level to the actual control boundary, not to the presence of security artifacts.
Short-lived credentials reduce exposure, but they do not eliminate signing risk. If a build job can still request the certificate or trigger the signer, then the credential lifetime is not the main issue. The issue is delegated authority inside the pipeline, which turns a runtime identity into a signing channel. Practitioners should model build identities as privileged non-human identities with explicit issuance and use boundaries.
Signed evidence is only defensible when the trust model is inspectable. The value of the corrected post is that it ties the proof to the environment, the source commit, and the verification result without overstating the assurance level. That is the standard teams should adopt for supply chain governance: evidence must be reproducible, scoped, and separable from the build itself. Practitioners should require that same discipline before accepting any attestation-based claim.
What this signals
Supply chain governance now depends on who can mint trust, not just who can build code. When a pipeline identity can access signing capability, the trust model shifts from artifact integrity to identity control. That means teams need to review issuance paths, runner permissions, and attestation boundaries together, not as separate workstreams.
SLSA confidence should be earned at the boundary, not inferred from pipeline cleanliness. A passing verification job is useful, but it is not a substitute for proving that the signer is isolated from the build. For practitioners, the practical question is whether their attestation path would still be trustworthy if the build job were partially compromised.
For practitioners
- Define the claim before you define the evidence Map the exact SLSA level or internal assurance target first, then check whether the workflow artifacts actually prove that level rather than a narrower verification result.
- Separate build execution from signing authority Ensure the job identity that compiles or packages the artifact cannot also obtain the certificate or token used to sign the attestation.
- Validate the provenance predicate and schema Confirm that the attestation uses the recognized provenance predicate type expected for the assurance level you are claiming, not just any signed statement.
- Test verification and signer compromise as different failures Run one test that alters the artifact digest and another that examines whether the trusted signing identity can be reached from the build path.
Key takeaways
- The article shows that a signed build record can prove artifact binding while still falling short of the claimed SLSA level.
- The critical control issue is whether the build identity can reach the signing authority, because that determines whether attestation is truly independent.
- Teams should test provenance format, signer separation, and digest verification as distinct controls rather than treating one successful CI run as end-to-end assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | L3 — Build Level 3 | The article centers on why the experiment did not satisfy Build L3 evidence and isolation requirements. |
| Recommendation — Use SLSA Build L3 as the benchmark for separating build execution from trusted attestation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The workflow depends on controlled certificate and token issuance for signing authority. |
| AC-6 — Least Privilege | The same workflow identity should not hold both build and signing authority. | |
| Recommendation — Apply IA-5 to tightly govern credential issuance, rotation, and revocation for build signers. Limit build identities so they cannot access signing functions or other privileged trust paths. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article highlights how pipeline access to signing credentials changes the trust model. |
| Recommendation — Map pipeline signer exposure to TA0006 and reduce any build-path access to attestation credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Pipeline identities and signing accounts need lifecycle control and separation. |
| Recommendation — Manage build and signing accounts separately and remove unnecessary access paths promptly. | ||
Key terms
- Provenance Predicate: A provenance predicate is the structured statement that describes how an artifact was built, signed, and linked to source material. In supply chain assurance, the predicate matters as much as the signature because it defines what the attestation is actually claiming about the build process.
- Account Binding: Account binding is the process of linking an external authenticated identity to the correct local user record. In commerce environments, weak binding creates duplicates, orphaned users, or incorrect updates, so the binding rule is a core governance control, not an implementation detail.
- Signing Authority: Signing authority is the permission to create a legally or operationally valid signature on behalf of an organisation. It should be granted, monitored, and revoked like any other privileged access. In practice, the control fails when authority is assumed to live in the tool instead of the identity behind it.
- Build and Release Trust Boundary: The set of people, systems, and permissions that can modify, sign, or deploy application code. This boundary matters because protected software is only as trustworthy as the pipeline that produces it. Weak access control here can undermine any protection applied to the code itself.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to build, signing, and verification workflows without overstating assurance.
Published by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org