From reviewed proposal to verified release artifact
Use 2–3 hours within P1's existing 10–14-hour supply-chain allocation for an artifact-substitution challenge. It is a concrete form of the already-required changed-bytes/wrong-identity tests, not extra pipeline work. Semester 09 remains 535–770 hours. All P1–P5 and module gates remain required.
The identity chain
A reviewed proposal can be correct while the shipped artifact contains different bytes. Carry a candidate revision from the previous semesters into the existing build pipeline. Record reviewed source revision, relevant build inputs, builder identity, resulting artifact digest and the digest actually selected for deployment. Tie test results to the candidate they exercised. A branch name or mutable tag does not identify fixed content.
A digest establishes an identity comparison; it does not establish that the content is safe. A valid signature establishes a relationship to a signing key under the verifier's policy; it does not prove the signer was authorized for this environment. Provenance helps connect build inputs to an output, but must itself be verified and checked against expected policy. Keep these claims separate.
Controlled substitution challenge
Run only in the existing local or disposable pipeline, using synthetic artifacts and test identities. First demonstrate the allowed artifact through the actual verification path. Then change bytes after verification and before selection, or replace the selected mutable reference with a different artifact. Show that the final gate rejects the mismatch before deployment. Checking a digest and then deploying a mutable name without binding the checked object leaves a gap.
Repeat the original wrong-builder and missing-signature cases. Record expected identity, observed identity, policy decision and retained verifier output without credentials. Test a legitimate rollback through the same verification path; urgency does not make an unverified old artifact acceptable. If the target toolchain cannot be run, preserve the plan and mark actual enforcement pending. A handwritten manifest or Python equality example does not complete P1.
Connect assistance to release responsibility
Whether a patch was authored by a person, generated or repaired with assistance, keep its provenance declaration attached to the review record. Do not put raw secrets, private prompts or customer data into a public attestation. Assistance metadata describes origin and review scope; the required source, build and artifact checks still decide admission.
If the candidate changes after review, identify affected evidence and rerun it on the new revision. Do not transfer a passing test badge to a changed artifact. Explain the remaining limits: compromised trusted builder, incomplete test coverage, runtime configuration drift and dependency resolution can require additional controls. State which are covered by existing pipeline evidence and which remain unresolved.
P1 calibration
Require the original level 2 for actual SBOM, signing/verification and provenance work. Its substitution subcheck must now bind the verified digest to the final selected artifact, reject changed bytes and wrong identity, and accept an authorized unchanged artifact and legitimate rollback. A check which rejects everything does not pass. A successful tabletop rehearsal is preparation, not evidence of deployment enforcement.
At the existing delayed defense, change the artifact after tests or select a different environment's signer. Locate the broken evidence link, state a concrete rejection condition and show how a legitimate release would proceed. Preserve independent reviewer status and the original versioned policies.
NIST SSDF 1.1 provides the identified secure-development reading for this exercise; use existing signing/provenance tool documentation for exact commands. Checked 2026-10-23. No claim of framework certification follows from this one challenge.