LEARN. PRACTICE. GROW.1. Identify the exact artifact to be used
A fictional team receives a package named release-final.zip and a report claiming it was signed. The name does not immutably identify the bytes operations will execute. Compute the received artifact’s digest and compare it with the object named by signed evidence. If the file changes after verification, the earlier decision does not cover the new bytes. An image tag or filename can point to different content over time; bind the decision to the digest and usage context. In the lab, changing the artifact while retaining the signed statement causes mismatch rejection. The signature need not be invalid: it may be a valid signature for another object. Record that distinction to guide diagnosis.
2. Separate valid signatures from authorized signers
The lab generates two independent Ed25519 key pairs. Both can produce mathematically valid signatures, but policy accepts only the configured trusted key. The identifier in the envelope locates that key; it does not let the sender replace the trusted public key with its own. After verification, also check the relationship between signer and permitted builder. A team allowed to sign development artifacts does not automatically gain production authority. Keep trust configuration under change control with owners and criteria for adding, removing or restricting identities. An empty trust list should cause rejection rather than implicit trust in any supplied key. The example uses local keys and does not verify certificates, revocation, federated identities or transparency logs.
3. Verify expected source and parameters
A trusted signature can accompany a build from the wrong repository, an older commit or unexpected parameters. Define expectations independently of the statement being checked: builder, canonical source, selected revision, build type and permitted parameters. In the exercise, debug=true and an additional skipScan parameter are rejected even when the signature is valid. Ignoring unknown fields can permit behavior the consumer never assessed. SLSA guidance connects provenance verification with roots of trust and expectations; the local code uses its own teaching format and is not a SLSA or DSSE verifier. Do not assign it a SLSA level or assume the lab established builder isolation or dependency completeness. Those aspects require evidence from the actual platform.
4. Integrate rejection and exceptions into operations
During a change window, the verifier rejects an artifact because the repository differs. Do not resolve the alert by changing policy to accept whatever just arrived. Confirm the release request, expected source and delivery chain. There may be a legitimate but unapproved change, a distribution error or an intrusion. Keep the artifact out of execution while following the designated decision process. If an exception route exists, require explicit scope, duration, owner and risk rather than turning it into permanent authorization. Preserve digests, outcomes and policy versions without copying secrets into tickets. Rollback also needs an identified, acceptable artifact; “it worked yesterday” does not replace assessment of compromise, vulnerabilities or compatibility with current data state.
5. Interpret success without promising absence of risk
When signature, digest and expectations pass, the result supports only those checks. It does not establish that software is vulnerability-free, that the signer cannot act maliciously or that every functional requirement is met. Responding to a compromised signing key may require removing trust for new decisions, identifying affected artifacts and consumers, preserving evidence and rebuilding from an assessed source. Rotating a signing key does not erase old signatures or clean already distributed artifacts. In the exercise, negative tests show different rejection reasons without executing the package. Use those results to prepare criteria, observability and trials in the real pipeline. Document what remains outside scope: trustworthy building, content analysis, distribution and release authorization.
An unauthorized key produces a valid signature but policy rejects it; another package fails digest matching despite a valid signature.
Common pitfalls
Signature treated as proof of safe software; supplied key treated as trust root; policy adapted to a rejected package; rotation treated as retroactive cleanup.
Related topics: Authenticated data and key lifecycle
Verify bytes, signer and expectations; treat content security and release authorization as additional decisions.
Reference: SLSA artifact and provenance verification · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17