Maintained and documented by Satyam Agnihotri · Content reviewed
Each record below names a claim, its evidence category, expected and observed result, source origin, date, revision where established, and limitation. Filters help compare related records; all entries remain readable without JavaScript. “Not verified” is an evidence status, not a passing result.
The source baseline is the preserved GCP implementation. Recorded execution comes from the owner’s docs/my-validation/ collection, whose README records 2026-08-23. The offline predicate and identity checks were executed on 2026-10-04 for this handbook. They did not query a live registry or cluster.
12 records. All records are readable without JavaScript.
No evidence matches these filters. Choose a broader category or clear the control filter.
recorded-live-validation · accepted
The pictured main workflow completed its build, signing and verification jobs.
Expected in this setup: The main workflow builds/pushes, signs/attests and verifies its selected digest.
Recorded result: Capture shows Success for a main workflow at commit 27a94b0, with build, sign and Verify jobs green.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision 27a94b0
Captured main workflow for source revision 27a94b0; distinct from the accepted live-workload artifact. · Select the image to read it at full resolution.
This is a captured workflow attempt, not a newly observed Actions run.
The displayed artifact digest begins a0073f8f and differs from the 32a90d live-admission capture.
README run/revision context must not be substituted for the commit visibly shown in this image.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. Unmodified original. Public canonical GitHub handle/repository, source commit and historical registry scope retained; no workstation metadata or credential visible.
The pictured CI verification accepted authenticated SPDX and SLSA v0.2 claims for its digest.
Expected in this setup: Authenticated claims identify the expected digest, signer, issuer, builder, entrypoint and source.
Recorded result: Decoded verification output shows SPDX packageCount 115 and provenance builder/entryPoint/source/sourceCommit fields.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision 27a94b0
Historical CI output for a0073f8f…; verification confirms the captured claims, not an entire supply-chain assurance level. · Select the image to read it at full resolution.
Package count is this capture's output, not a measure of SBOM completeness or package safety.
SLSA v0.2 is a schema label; no assurance level established.
This digest differs from the later live-acceptance test digest.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. Unmodified original. Public workflow identity, source commit, digest and historical registry scope retained. No credential or personal workstation path visible.
The pictured application was Healthy and Synced to canonical main at capture time.
Expected in this setup: Argo reconciles the selected Helm release and reports healthy workload resources.
Recorded result: Capture shows Healthy, Synced to main(c67aefd), Sync OK to 9bf574c, two running Pod nodes.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision c67aefd
Argo reconciliation captured on 2026-08-23; current sync c67aefd and last-sync 9bf574c are separate observations. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible labels:
APP HEALTH Healthy
SYNC STATUS Synced to main(c67aefd)
Auto sync is enabled.
LAST SYNC Sync OK to 9bf574c
Succeeded 5 hours ago (Sun Aug 23 2026 14:56:28 GMT+0530)
Two Pod nodes: Running 1/1
What this does not establish
Healthy/Synced describes captured reconciliation, not cryptographic verification by Argo.
Current sync revision and last-sync revision are different visible fields; neither is automatically the artifact build revision.
The picture does not independently establish policy revision or all admitted image fields.
Visual review of original capture. Collection capture date attributed to docs/my-validation/README.md; this task did not rerun its cloud experiment. Unmodified original. Application status, public source revisions and timestamps retained; no user-info contents or credential visible.
The captured trusted Helm release passed API-server dry run; the application separately had two available replicas.
Expected in this setup: A workload using the signed selected digest is accepted in the matched namespace.
Recorded result: Service and Deployment configured under server dry run; live Deployment listed 2/2 ready and available.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
The signed release passes server dry-run; a separate query reports two available replicas. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
service/supply-chain-demo configured (server dry run)
deployment.apps/supply-chain-demo configured (server dry run)
RESULT: PASS - trusted workload admitted by API server / Kyverno
NAME READY UP-TO-DATE AVAILABLE AGE
supply-chain-demo 2/2 2 2 5h14m
TRUSTED IMAGE DIGEST
sha256:32a90d832fdf76794fa5477e42e1fdcec28c9eb6e0deee48ad466d1f7d9fc563
What this does not establish
Server dry run does not itself create the observed live replicas; the capture includes separate live-read commands.
The source commit that built this image and the exact installed policy revision are not established by this screenshot.
Acceptance is historical, not proof of today's controller or workload status.
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 captured API-server dry run rejected a matching unsigned image.
Expected in this setup: Reject the matched image without required approved signature and attestations.
Recorded result: mutate.kyverno.svc-fail denied the request; signature reported no signatures found and attestations reported no matching attestations.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
API-server dry-run rejects the matched unsigned test image. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
Unsigned image digest:
sha256:18549c45e5d1d87804372cb8082cefbee1019b9c592d816d14817cc12472ca17
admission webhook "mutate.kyverno.svc-fail" denied the request
resource Pod/default/unsigned-image-test was blocked
verify-image-signature: no signatures found
verify-provenance-attestation: image attestations verification failed, verifiedCount: 0, requiredCount: 1, error: no matching attestations
verify-sbom-attestation: image attestations verification failed, verifiedCount: 0, requiredCount: 1, error: no matching attestations
RESULT: PASS - unsigned image DENIED; no signatures found
What this does not establish
This is one server-side dry-run request, not a persisted negative deployment.
Three missing claims occur together; it does not isolate each attestation requirement independently.
Unmatched registries and excluded namespaces were not tested in this capture.
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.
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.
Both captured mixed-image fixtures with an unsigned initContainer were denied.
Expected in this setup: An approved regular image must not excuse an unsigned matched init image in the same Pod.
Recorded result: API-server dry runs for test-mixed-containers and test-init-unsigned were denied, each citing unsigned-test with no signatures and no matching attestations.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
Both mixed-image fixtures containing an unsigned initContainer are denied. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
TEST 1 - Mixed trusted + untrusted containers
resource Pod/default/test-mixed-containers was blocked
verify-image-signature: supply-chain-demo:unsigned-test: no signatures found
verify-provenance-attestation: no matching attestations
verify-sbom-attestation: no matching attestations
RESULT 1: PASS - mixed-container bypass DENIED
TEST 2 - Unsigned initContainer
resource Pod/default/test-init-unsigned was blocked
verify-image-signature: supply-chain-demo:unsigned-test: no signatures found
RESULT 2: PASS - unsigned initContainer DENIED
What this does not establish
The baseline YAML shows both fixtures use an unsigned initContainer alongside a signed regular container.
This does not establish unsigned regular sidecar or ephemeral-container subresource coverage.
The capture's final broad phrase about protected bypass paths is narrowed to the fields actually tested.
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 shell executed as UID/GID 10001 and a Critical Falco event was then recorded.
Expected in this setup: Record unexpected shell execution in the application namespace with the configured Falco rule.
Recorded result: The command returned id output and Falco logs showed the named Critical shell rule.
Historical GCP, europe-west1; current environment not checked · observed 2026-08-23 · source revision unknown; not inferred from the documentation baseline
The controlled shell returns UID/GID 10001; Falco subsequently records a Critical shell event. · Select the image to read it at full resolution.
Transcript / inspected observation
Selected visible output:
uid=10001(appuser) gid=10001(appgroup) groups=10001(appgroup)
"priority": "Critical"
"rule": "Shell Spawned In Signed Workload Pod"
Critical Unexpected shell spawned in hardened pod
user=appuser
ns=default
cmdline=sh -c id
RESULT: PASS - Falco detected the controlled runtime shell
What this does not establish
Detection happened after successful shell execution; no prevention or automatic termination observed.
The rule condition does not verify signatures.
The captured image tag does not establish a manifest digest or build commit.
No external notification or incident-response completion captured.
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 committed policy requires three claims only for matching application images outside explicit exclusions.
Expected in this setup: The policy expresses signature, SPDX and SLSA verification requirements.
Recorded result: Three Enforce rules, exact signer/issuer, required digest verification, five namespace exclusions, one imageReferences path and three provenance conditions are present.
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.
Discord delivery and incident response were not demonstrated in the recorded validation.
Expected in this setup: Only an enabled, configured and executed alert test could establish external delivery.
Recorded result: The validation README says the alerting path was disabled pending a real webhook; no Discord capture.
Historical optional GCP alerting path; disabled per validation README · observed date unknown · source revision unknown; not inferred from the documentation baseline
Transcript / inspected observation
Recorded statement: No Discord alert was captured because the alerting path is disabled until a real webhook is supplied.
What this does not establish
Optional Terraform resources do not establish enabled deployment.
A runtime log alone does not prove event delivery or response.
Source inspected against the pinned baseline; execution scope stated explicitly. No screenshot or sensitive runtime state published.
Ephemeral-container updates, unmatched-image handling and verifier outages have no established live result in this catalogue.
Expected in this setup: Fresh isolated tests and installed configuration inspection are required to establish each behavior.
Recorded result: No recorded test found for ephemeral-container subresource, isolated unsigned regular sidecar, registry outage or controller outage.
Offline detached baseline inspection; no cloud mutation · observed date unknown · source revision unknown; not inferred from the documentation baseline
Transcript / inspected observation
No execution transcript exists for these cases.
What this does not establish
Absence from reviewed evidence is not proof of a vulnerability or capability.
Enforce and webhook name do not establish the complete version-specific outage contract.
Source inspected against the pinned baseline; execution scope stated explicitly. No screenshot or sensitive runtime state published.
The complete fourteen-image gallery provides website-hosted screenshots and accessible full-resolution links. All fourteen original captures retain their bytes and dimensions. Public source identities and historical registry scope remain relevant attribution and verification context.
The terminal captures include personal workstation metadata. The owner requested all original images and subsequently authorized publishing them with the handbook on Cloudflare. Their original bytes and technical body remain intact, with the visible metadata disclosed in their provenance notes. No additional redaction was selected; any future derivative needs a separate instruction and explicit display provenance. Selected output transcripts remain readable alongside the images. These excerpts are not full logs; omitted prompts and machine identifiers do not change the recorded decision.
The older upstream docs/evidence/ files remain separate historical source material. This catalogue does not relabel those captures as the owner’s deployment proof. Website browser screenshots are also separate: they test website appearance and behavior rather than cloud security.
The approved CI and attestation images show 27a94b0 and an a0073f8f… artifact digest. The trusted live-test capture shows 32a90d…. The Argo screenshot shows current sync c67aefd and last successful sync 9bf574c. The runtime screenshot’s tag metadata is not a manifest digest. Each observation retains its own revision association rather than borrowing a convenient value from another file.
A denial of an unsigned image supports a scoped missing-claim decision. It does not isolate every attestation requirement. The combined wrong-trust test changes two expectations at once. The mixed/init tests both exercise initContainers. A detected shell is an executed shell, and optional notification delivery is unverified.
For the reasoning behind these interpretations, start with how to read evidence and known gaps. A future update should add a distinct evidence record only after inspecting the actual result and its provenance.
