Reference and decisions

Use this section when you need an exact field, an execution dependency, or the reason a design accepts a particular trade-off. The handbook’s unit of explanation is a security responsibility. This index reconnects those responsibilities to their concrete implementation tools without making a tool’s presence an assurance claim.

Tool-to-concept map

Tool or format	Responsibility in this baseline	Where to inspect
GitHub Actions	Separate PR checks from main artifact publication and statement production	Workflow execution map
Semgrep	Find source patterns under the configured rule policy	Blocking and informational checks
Trivy	Scan filesystem and built-image content with HIGH/CRITICAL gates and exceptions	Workflow gates
Google Workload Identity Federation	Exchange an external GitHub identity for short-lived cloud access	Infrastructure authority map
Artifact Registry	Store image content and separately addressed statement metadata	Registry contract
Cosign / Sigstore	Sign a digest and statements with a verifiable workflow certificate identity	Verification contract
Syft / SPDX	Enumerate the final image’s packages into a signed inventory statement	CI and admission comparison
SLSA provenance v0.2	Express workflow-produced claims about builder and source	Provenance limits
CycloneDX / cdxgen / depscan	Produce separate source-dependency and reachability research reports	Informational analysis
Helm / Kubernetes	Express the selected immutable image and workload settings	Application and container reference
Argo CD	Reconcile reviewed desired state from Git	Promotion responsibility
Kyverno	Verify the configured image trust contract at Pod admission	Verification contract
Falco / Falcosidekick	Observe process behavior and optionally route events	Runtime infrastructure
Terraform	Define foundation resources, identities, and optional modules	Infrastructure map
Gatekeeper / Ratify	Retained earlier implementation and compatibility context	Inactive components

An inventory is not a vulnerability verdict; a signature is not review approval; a reconciled Deployment is not runtime safety. These distinctions explain why the tools are connected rather than interchangeable.

Attribution and revision boundaries

The canonical monorepo combines application/security work originally sourced from musaumakau/supply-chain-security and infrastructure/runtime work originally sourced from musaumakau/gcp-infrastructure-modules. This attribution is recorded in the pinned repository merge record. It does not assert that current upstream branches equal this baseline.

The handbook is grounded in the preserved GCP commit, while the documentation website is a new static project and current application main is Azure. Source links identify the historical implementation revision explicitly. Original upstream evidence under docs/evidence/ is context; personal baseline captures under docs/my-validation/ have a different provenance and should be evaluated as such.

Choose the next reference

Start with CI versus admission for a security review, the application fields for a configuration question, or decisions for alternatives and deferred controls. The website engineering summary explains the static handbook’s own design and report material; its threat model is separate from the GCP delivery system.