A container signature tells you who signed a digest. Provenance describes how the artifact was built, from which source and configuration, and by which builder. Those are different facts. A deployment policy that checks a signature but never verifies the provenance can prove that a trusted account approved an artifact without proving that the artifact came from the expected build path.
SLSA's verification model starts with the artifact and its provenance attestation. The consumer checks that the artifact matches the subject digest in the provenance, that the provenance signature is valid, and that the builder identity is connected to a preconfigured root of trust. Then it compares the source, build definition, and builder against policy. A provenance document that is internally signed but names the wrong builder should not be accepted.
Pin the builder, source, and subject
Define the expected builder identity and the expected source repository. A branch name alone may be mutable, so bind the source to a commit or a protected reference where the build system can provide it. Pin parameters that change the code or build environment, such as the Dockerfile, build arguments, base-image digest, and dependency lock state, when the builder records them.
Verify that the provenance applies to the exact artifact being deployed. A valid attestation for a different image digest is useless even if the repository and commit are correct. Resolve tags to digests before verification and keep the digest in the deployment record. A tag that changes after admission must not be able to turn a verified name into an unverified image.
Know what the level does not cover
Higher SLSA build levels provide stronger guarantees about the build service and the provenance generation, but the final consumer still has a policy problem. The build may be trustworthy while the source repository allows unreviewed changes. The artifact may be reproducible while an attacker controls a dependency. The provenance may be accurate while the deployment platform admits an image from an unintended namespace.
Map those gaps to other controls: branch protection, code review, dependency pinning, secret isolation, registry permissions, admission policy, and runtime monitoring. Do not inflate a build-level claim into a statement that the software is free of vulnerabilities.
Test the rejection paths
Create an image from the expected builder and source, then alter one variable at a time: wrong repository, different commit, unsigned provenance, tampered subject digest, unexpected builder, and a valid attestation for a different image. Confirm that admission and release tooling reject each case with a useful reason. Test the path when the attestation is unavailable and when the trust root has rotated.
Keep the verification result with the deployed artifact. A later incident investigation should be able to show which provenance, builder, source, policy revision, and verifier result were accepted. Provenance is most useful when it remains connected to the deployment decision, not just to a successful CI log.