A test result is useful only when its claim, input, environment, and limitations are clear. A green workflow screenshot, a policy YAML file, and an API-server denial answer different questions. This section connects the preserved evidence to those questions without treating a historical capture as a currently running environment.
The strongest reading sequence is accepted versus unsigned, wrong trust expectations, container-field scope, and runtime shell detection. The catalogue gathers all reviewed records; known gaps identifies untested questions.
| Label |
What this edition actually did or found |
What it cannot establish alone |
| Code inspected |
Read the pinned workflow, policy, manifest, or infrastructure |
That the configuration was deployed or currently effective |
| Local test |
Executed an offline check against the detached baseline |
Registry access, authenticated claim validity, live webhook behavior |
| Recorded live validation |
Reviewed original historical captures and their accompanying record |
That the system runs now, or that all captures share a run/revision |
| Not verified |
Found no adequate recorded or newly executed result |
Either successful enforcement or a proven bypass |
A server-side dry run sends a request through the API-server admission path without persisting the requested object. It is stronger evidence of that admission decision than YAML inspection, but does not show that a new Pod was scheduled or ran. The acceptance capture separately queries an already running Deployment; those observations must remain separate.
A workflow file describes how a candidate should be verified. A successful captured run shows selected jobs completed historically. A screenshot of decoded provenance fields does not let this website’s browser independently authenticate the cryptographic claims. The site is a static explanation of reviewed evidence, not a live verifier.
The implementation baseline is the full GCP source commit cbbc807c0c150e106affa89fbb1b9e8349005749. The capture context comes from the original validation collection, whose README records 2026-08-23. A build or deployment revision must come from the individual observation where it is established. This edition’s 2026-10-04 review date is neither the capture date nor a cloud deployment date.
The CI/attestation screenshots show source commit 27a94b0 and a digest beginning a0073f8f. The live-acceptance screenshot shows digest 32a90d…. The Argo image shows current sync c67aefd and last sync 9bf574c. The runtime image reports a tag but does not establish the manifest digest. These are related historical observations, not one verified trace assembled by substituting metadata.
The wrong-trust test changes both expected signer subject and expected provenance source in one temporary policy. It records one combined denial experiment. The mixed and init fixtures both use an unsigned initContainer next to a signed regular container. Their labels do not create proof for untested regular sidecars or ephemeral containers.
The runtime shell command successfully returns id output before Falco logs are read. That is detection after execution, not prevention. The rule name does not add a signature check. Optional Discord configuration without recorded delivery remains an evidence gap.
The complete screenshot gallery delivers all fourteen reviewed captures. The owner authorized publishing these original images with the handbook on Cloudflare. They preserve their original bytes, commands, results, technical identities and dimensions. Terminal/account metadata remains visible where it was present and is disclosed in the gallery’s provenance notes. Any future redacted derivative requires a separate instruction and an explicit record of the display changes. Selected accurate transcripts remain available alongside commit-pinned source originals.
New browser screenshots created during website testing establish the documentation UI’s appearance. They are stored separately from cloud evidence and do not support admission or runtime claims.
local-test · acceptedOffline evaluation of the actual Rule 3 conditions matched the supplied provenance predicate fixture.
Expected in this setup: All shipped Rule 3 JMESPath expressions resolve expected values in the captured predicate shape.
Recorded result: Three conditions passed; the identity-consistency shell check also passed from the baseline working directory.
Offline detached baseline inspection; no cloud mutation · observed 2026-10-04 · source revision cbbc807
Transcript / inspected observation
Executed 2026-10-04:
OK: invocation.configSource.entryPoint -> .github/workflows/sign-attest.yml
OK: builder.id -> https://github.com/actions/runner
OK: invocation.configSource.uri -> git+https://github.com/devSatym/gcp-supply-chain-security@refs/heads/main
All Rule 3 conditions match the real provenance predicate shape.
All certificate identity references are consistent.
What this does not establish
- The Python test does not authenticate a signature or query registry/admission.
- The shell check includes preserved historical Gatekeeper files and checks string consistency, not active deployment.
- One predicate fixture is not exhaustive malformed-claim or negative-case coverage.
Source inspected against the pinned baseline; execution scope stated explicitly. No screenshot or sensitive runtime state published.
Inspect the untouched, commit-pinned original →
The offline predicate test above is a new check genuinely executed for this handbook. Its narrow result is valuable precisely because it does not pretend to validate a cloud deployment. Start the cloud-evidence cases with what was accepted and rejected.