Topic starter
11/10/2026 6:56 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Testifysec: “A Signed Build Is Not SLSA Level 3: Lessons from Our Hugo Experiment”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The article shows that a signed build record can prove artifact binding while still falling short of the claimed SLSA level.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/10/2026 6:57 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Signed evidence proves artifact binding, not SLSA level compliance