A guided tour of the strongest claims

Start with the artifact and ask which authorities may speak about it. This tour is designed for a reviewer who wants to understand the connected design before inspecting every file.

1. Find the object that stays the same

Open the Helm values. The application selects a repository and a sha256: digest. The deployment template renders repository@digest. That is the precise artifact admission should inspect, rather than whatever a tag happens to identify later.

Read artifact identity next. The digest establishes content identity. It does not establish origin, safety, or permission to deploy.

2. Locate publication and signing authority

The release orchestrator runs a local image scan on pull requests and reserves the publish/sign/verify chain for canonical main. The cloud identity exchange grants registry access. Keyless signing creates a statement from the signing workflow identity. These exchanges serve different purposes even though they originate in the same GitHub job environment.

The final federation source restricts the repository but does not independently restrict the Git ref. That limitation belongs in the review: the workflow guard carries the main-only boundary, so workflow changes and repository administration remain important authorities.

3. Read one exact verification contract

CI verification checks cryptographic identity and explicit statement fields. It compares the built digest, provenance builder, source URI, signing workflow entrypoint, current source commit, and source materials. Admission checks a related but smaller contract at the Kubernetes boundary. The difference explains why neither a green CI result nor a signature by itself is sufficient permission to deploy.

4. Compare an acceptance with a denial

Use trusted acceptance and unsigned rejection to inspect historical observations. Ask whether the namespace and image are actually in policy scope. Then inspect container-field coverage: the records include a mixed-container fixture and an unsigned initContainer fixture, while ephemeral-container coverage remains unverified. A single admitted Pod does not establish every path through a policy.

The original validation summary identifies the captured environment and date. Do not use older upstream transcripts as proof of this owner’s deployment.

5. Cross the boundary after admission

Runtime observation explains why the allowed artifact can still emit a suspicious shell event. Falco observes a process; it does not reverify its signature or stop the shell in this configuration. The controlled shell record demonstrates detection. External Discord delivery remains optional and unverified.

Finish with shared trust dependencies. A compromised trusted workflow can create a malicious image and sign misleading claims that multiple later verifiers accept. The review should evaluate those shared assumptions as carefully as the number of controls.