Why do signed artifacts not prove SLSA compliance by themselves?

What signed artifacts actually prove

Signed artifacts establish that a digest, package, attestation, or statement was signed by a key that can be verified. That is useful, but it is only one control point. A valid signature can tell you who or what authenticated the object, not whether the build was isolated, whether the signer was trustworthy, or whether the provenance metadata reflects the actual build path.

The distinction matters because SLSA is about the integrity of the whole build-and-release chain, not just the final artifact. A signature can survive a weak process, a compromised runner, or a misleading provenance statement. In other words, the signature may be cryptographically real while the assurance claim is still too broad.

For readers mapping this to a supply-chain program, the SLSA model is explicitly concerned with provenance and build integrity, not with signatures as a standalone guarantee. A signed object is evidence inside that model, not a substitute for it.

Why the build environment and provenance boundary are part of the claim

SLSA compliance depends on separation between the artifact, the signer, and the build environment. If the same principal can both build and sign without meaningful isolation, then the signature says little about whether the output came from an expected source path. Likewise, if provenance is only a self-asserted record, the signature may validate the record without validating its trustworthiness.

This is why controlled runners, restricted signing authority, and provenance formats with verifiable linkage are central. The relevant question is not simply "was it signed?" but "was it signed in a process that preserves the expected trust boundaries?" That is the difference between artifact authentication and supply-chain assurance.

Practitioners working in CI/CD should treat identity boundaries in the build system as part of the control model, not as an implementation detail. NHIMG’s CI/CD Pipeline Identity Security Guide is relevant here because pipeline identity, runner trust, and token scope are often what determine whether the signer actually means anything.

External guidance on authenticated claims can also help frame the boundary correctly. For example, RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants shows the same general principle: a signed assertion can authenticate a party, but the surrounding trust model still determines what that assertion is allowed to prove.

What practitioners should verify before treating signatures as compliance evidence

Two artifacts with identical signatures can imply very different levels of assurance depending on how they were produced. A compliant SLSA posture needs evidence that the build ran in the expected isolation model, that the signer was not also the untrusted builder, and that the provenance document is bound to the exact artifact digest and build steps you expect.

That is why a signature should be treated as one verification input, not the endpoint. If the artifact is signed but the build process is opaque, mutable, or shared with untrusted work, the safer interpretation is "authenticated output" rather than "SLSA-compliant supply chain." The assurance claim should follow the control design, not the presence of cryptography alone.

The strongest operational use of signatures is to support provenance checking, admission decisions, and release gating after the build trust model is already in place. If those upstream controls are weak, the signature may still be useful, but it does not close the gap created by untrusted build conditions or weak signer separation.

Practitioner Guidance

What to verify: Confirm that the signer, build runner, and provenance generator are separated in a way that prevents a single compromised path from fabricating both the artifact and its assurance record. If one identity can control the build and the signature, the evidence is weaker than it looks.

What good looks like: The artifact digest, the provenance statement, and the build environment each have traceable, independently controlled trust boundaries, so the signature supports a broader chain of evidence instead of pretending to replace it.

Practitioner takeaway: Use signatures to authenticate build outputs, but use provenance and environment controls to justify SLSA compliance; if those controls are missing, the signature is proof of signing, not proof of supply-chain integrity.

Related resources from NHI Mgmt Group

• How should security teams prove DORA compliance for AI agents that act autonomously?
• How should organisations prove EU AI Act compliance across the AI lifecycle?
• How can teams prove who actually signed a document?
• How can security teams prove that compliance tasks were completed on time?