A valid image signature can still fail a verifier’s authorization decision. This historical test uses a known signed digest and deliberately makes the verifier expect claims the artifact does not carry. The request is denied, showing that accepted cryptographic origin must also match the configured trust contract.
The important experimental limit is that two expectations change together. This is one combined test, even though its error output lists two rule failures.
The test fixture is a Pod in default using the known signed 32a90d… image. Its supply-chain-security-test: invalid-trust label selects a temporary test policy. That policy has background: false and validationFailureAction: Enforce, with two rules:
reject-wrong-keyless-identity expects not-the-signing-workflow.yml@refs/heads/main instead of the actual approved signer workflow.
reject-wrong-provenance-source keeps the canonical signing identity but expects git+https://github.com/devSatym/untrusted-fork@refs/heads/main in the provenance source URI.
The normal policy remains distinct from this deliberately failing test contract. The fixture image is not changed to a different signer, and the test does not mutate the image’s content.
Expected behavior is denial because the known claims cannot satisfy the two wrong expectations. The capture shows the temporary policy created, a server dry-run request denied, the signer subject mismatch, a failed provenance attestation check, and the temporary policy deleted afterwards.
recorded-live-validation · rejected
A known signed test digest was rejected when one temporary policy changed both signer subject and provenance source expectations.
Expected in this setup: Reject a known signed image when the configured trust expectations do not match its claims.
Recorded result: The request was denied with subject mismatch and provenance attestation-check failure; temporary policy deletion is visible.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
A temporary policy with changed signer/source expectations rejects a known signed digest and is then deleted. · Select the image to read it at full resolution.
One combined experiment changes two expected fields; not two isolated proofs.
The signer itself is not changed and the image is not shown being tampered with.
The transcript uses ellipses only for repeated canonical repository prefixes and omits incidental terminal metadata.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. The original screenshot is approved for display at the owner’s explicit request for all evidence images and subsequent Cloudflare publication. Original terminal metadata remains visible. No additional pixel redaction was selected or applied. The selected transcript omits incidental prompts without changing the recorded result.
The visible subject mismatch compares the expected wrong workflow with the actual sign-attest.yml subject. The provenance message reports attestation checks failed under the wrong-source rule. This supports the configured test policy rejecting the known signed artifact with both mismatches active.
Why the test must not be split into two claimed proofs
Two denial lines do not turn one input into two isolated experiments. To isolate signer enforcement, a test would change only the subject expectation while keeping source expectations correct. To isolate source enforcement, another request would keep the signer expectation correct and change only the source condition. The historical collection does not show that pair of independent requests.
Likewise, this capture does not demonstrate malicious re-signing, altered payload bytes, a fork successfully publishing to GAR, or compromise of an approved workflow. Those are different threat scenarios. The result is useful without relabelling it as something broader.
The screenshot includes deletion of test-invalid-trust-expectations; the fixture uses a narrow label selector to limit its affected requests. This task reviewed those outputs and did not apply a test policy to any cluster. Reproducing the experiment requires an owned environment, known signed digest, exact signing subject, working verifier access, and careful temporary-policy scope.
A fork or tag checkout would change the workflow identity context and cannot automatically satisfy the canonical main trust contract. An owned reproduction must deliberately rebind its expected identity and source, preserving a record of those changes. That is different from weakening the original baseline to make a test pass.
Continue to container-field cases for another example where a test’s exact input matters more than its broad title.
