First release and fresh evidence

The first release should produce a small, reviewable chain of evidence. A green build is insufficient: the selected digest, signed statements, GitOps desired state, admission decision, and observed workload must refer to the intended artifact. This procedure describes an owned reproduction after its identity contracts have been reviewed. No release pipeline or cloud test was executed for this website.

1. Observe the unprivileged path

Open a relevant pull request in the owned reproduction repository. Record the source revision, changed paths, change-detection result, Semgrep result, Trivy filesystem result, local-image scan, and policy tests. Confirm that registry build/push, signing, and verification jobs are skipped for the PR event. A check definition is not evidence of branch protection; inspect and record the owned repository’s live rules separately.

2. Build on the trusted branch

After the approved merge, observe the trusted main workflow or the deliberately rebound equivalent. Its image scan addresses the pushed final digest and blocks signing if the HIGH/CRITICAL policy fails. Retain the build’s digest output; the source commit tag is a convenience label, not the release identifier.

Record scanner date, database/tool version where available, and .trivyignore revision. A passed scan means no blocking finding under that policy at that time. The baseline ignore file includes accepted exceptions and several entries with incomplete tracking context; do not summarize its result as “zero vulnerabilities.”

3. Retain verification results before promotion

Record the signing workflow’s subject and issuer, the digest, SPDX predicate type, package count, and provenance contract fields. The strict CI check validates source commit and materials as well as builder, entry point, source URI, and subject digest. Download the SBOM while its GitHub artifact retention window is open. Never retain or print the raw GitHub OIDC token.

The optional CycloneDX/depscan job is separate from the signed image SBOM. Its research analysis does not gate signing or verification; a missing report does not turn the signed SPDX check into a different assurance claim.

4. Review the selected digest

Manually update the owned Helm values with the exact verified digest. Review the repository address and digest together, render the chart, and review the change. The GCP baseline contains no automated digest-promotion job. A newer verified digest can coexist with an older deployed digest until the human promotion occurs.

Before reconciliation, submit the rendered chart with a server-side dry run to the owned cluster. This contacts Kubernetes and admission but does not persist the workload. Inspect the result and the actual live policy, then allow the reviewed Argo CD Application to reconcile.

helm template supply-chain-demo k8s/helm/supply-chain-demo > /tmp/supply-chain-demo-rendered.yaml
kubectl apply --dry-run=server -f /tmp/supply-chain-demo-rendered.yaml
kubectl -n argocd get application supply-chain-demo
kubectl get deployment supply-chain-demo -o jsonpath='{.spec.template.spec.containers[*].image}'

5. Observe failure paths and runtime separately

In a disposable, owned test namespace within policy scope, run reviewed unsigned, mixed-container, and unsigned-initContainer fixtures and retain the server responses. The wrong-trust fixture changes signer and source expectations together; record it as one combined experiment. Do not describe it as two isolated proofs. Remove temporary policies promptly after their evidence is retained.

A controlled shell event requires a separate operator decision because it executes a process inside a running Pod. Retain its UTC timestamp, Pod identity, actual command, Falco rule output, and permissions used. A CRITICAL event is detection, not prevention or a completed incident response. External delivery remains unverified while enable_runtime_alerting is false.

Source anchors

Release orchestration, strict verifier, and historical validation record.