The original version of this post described an experiment with Hugo, CI/lock, and a hosted build. The original SLSA Build Level 3 claim was withdrawn: the experiment did not reach that level. The source article was corrected on September 29, 2026; this edition carries that correction forward.

The useful outcome was a signed build record and a policy check on the resulting artifact. The experiment also exposed why a working signature, a hosted runner, and a passing verification job do not by themselves establish a SLSA level.

Act 1: The climb

The recorded workflow collected build evidence, a software bill of materials, and a vulnerability scan, then verified the artifact against a signed policy. It began with a local signing key and later used a GitHub-hosted runner with the job’s OIDC identity.

There were two distinct limits. First, the provenance at the time used https://slsa.dev/provenance/v1.0, rather than the recognized https://slsa.dev/provenance/v1 predicate type. The original result therefore could not support the advertised SLSA Build level.

Second, a build step in that job could obtain a certificate for the same workflow identity. Short-lived certificates removed the need to provision a long-lived signing key, but the signing authority was still reachable by the build. That is not the isolated provenance-generation boundary required at Build L3. See the SLSA Build requirements and the environment support matrix before assigning a level to a workflow.

Act 2: The gate

The original session reported a negative test: alter the built binary, then run verification again. The altered artifact was rejected because its digest no longer matched the attested subject. That is a useful check of artifact binding. It does not establish that a compromised build could not produce a different, validly signed statement.

Test both boundaries. Change the artifact to test digest verification; separately assess who can obtain the trusted signing identity and what they can cause it to sign. A green CI job alone answers neither question.

Act 3: Why it was fast

The session used hosted signing and evidence services, which reduced the infrastructure needed for the experiment. Its reported elapsed time describes that one session. It is not an onboarding benchmark or a promise for another team’s environment.

An agent helped execute the workflow. That does not make the agent’s account of the session an independent record of execution. Keep the source commit, signed evidence, verification output, and relevant environment configuration together so another person can inspect the claim.

Act 4: The payoff you did not have to ask for

The resulting evidence can be useful beyond one release decision. A platform team can associate an appropriately scoped test result with a technical control and retain the mapping used for review.

Those associations require configuration and review. A vulnerability scan does not establish a complete vulnerability-management process; an SBOM does not establish legal conformity; and signed provenance does not establish that the code is safe. The technical-control workflow explains where these records fit.

The receipt

The defensible account is narrower than the original headline: this was an experiment in signed evidence and artifact verification, with a subsequently corrected SLSA claim. This edited post has not rerun that historical environment or revalidated a current release.

To reproduce the supported workflow for your installation, use Your first attestation, then review the trust model. Define the claim before deciding which evidence proves it.