Understand the claim, inspect the contract, then read the evidence.
From source code to trusted execution
Security is a chain of decisions
Section titled “Security is a chain of decisions”Who can publish an image? Who endorses its origin? Who selects the release? Who evaluates the request to run it? These are different authorities, even when they act on the same immutable digest.
- GitHub Actions evaluates changes and builds the digest.
- Artifact Registry stores the image and separately stored signatures/attestations.
- A human selects the digest in Git; Argo requests reconciliation and Kyverno evaluates admission.
- Falco detects configured execution events after the workload starts.
Solid arrows indicate the stated handoff, not a claim of independent trust. Optional relationships are described in the text equivalent. Historical components are labeled in the caption.
The connected design · select a stage to inspect its handoff
01 / Review a change
Can this change safely enter the trusted build path?
Input: PR revision. Output: Checks without publish authority. Verifier: PR checks.
Read this stage →02 / Build exact content
Which artifact did the release checks evaluate?
Input: Trusted main revision. Output: Image digest. Verifier: Trivy.
Read this stage →03 / Sign the digest
Which workflow endorsed these exact bytes?
Input: Digest and workflow identity. Output: Signature. Verifier: Cosign.
Read this stage →04 / Select a release
Which verified digest is permitted to run?
Input: Verified digest. Output: Reviewed Git digest pin. Verifier: Reviewer and Argo CD.
Read this stage →05 / Decide admission
Does the requested image meet this namespace and registry policy?
Input: Requested Pod image. Output: Allow or deny. Verifier: Kyverno.
Read this stage →06 / Observe runtime
What does an admitted process do next?
Input: Running process events. Output: Detection. Verifier: Falco.
Read this stage →Choose a path through the handbook
Section titled “Choose a path through the handbook”You can understand the whole design without reading every prerequisite first. Start with the questions that matter to your review.
Follow authority across boundaries and test the limits of each claim.
Start locally, then plan an owned historical environment with explicit rebinding.
What happens when trust breaks?
Section titled “What happens when trust breaks?”A trusted digest enters the workload
The historical evidence records a digest-pinned workload running under the configured trust policy. This establishes the tested path in that environment.
Read the allow and deny evidence →An unsigned image meets a boundary
The matching unsigned image is rejected at admission. Unmatched registries, excluded namespaces, and untested subresources remain separate questions.
Inspect the exact policy scope →Evidence that you can inspect
Section titled “Evidence that you can inspect”The edition is pinned to the preserved GCP implementation, not current main’s Azure system. Code inspection, local tests, and historical captures carry separate labels. A valid signature establishes an authenticated claim; it does not make the application invulnerable.
Read the baseline boundaries, browse the evidence catalogue or all fourteen screenshots, or inspect the canonical project. Upstream attribution and primary references are recorded in the reference index.
More engineering projects
Each project has its own documentation. Planned sites are listed as destinations under preparation.
Resilience Gate
A planned independent project documentation site. Its scope and evidence will be described when a reviewed edition is available.
Proposed hostname resilience.devsatym.xyz
Azure AKS GitOps Observability
A planned independent documentation site for the AKS, GitOps, and observability project. This GCP handbook makes no claims about its deployed state.
Proposed hostname aks.devsatym.xyz
