Workflow execution and blocking behavior

The executable graph begins at root .github/workflows/. Reusable workflows do not independently trigger releases. Imported workflows under infrastructure/.github/ are retained provenance material; GitHub Actions does not discover them at that nested path.

Entry points

Entry workflow	Trigger and scope	Important behavior
pr-check.yml	Every pull request to main	Detects relevant changes; skips individual jobs when irrelevant so check contexts can still resolve
deploy.yml	PRs to main; main pushes matching application, Docker, workflow, or action paths; manual dispatch	PR builds a local image only. Privileged release jobs require main; manual build also requires confirmation deploy
infrastructure-terraform.yml	PR/main push matching infrastructure/**; manual dispatch	Validates six directories with formatting, backend-disabled initialization, and validation; does not apply

The PR relevant-path filter includes application, Dockerfile, workflow/actions, policy, Terraform, infrastructure, Helm, and CODEOWNERS paths. Deploy’s main push filter is narrower. A Helm-only main change therefore updates Git desired state without necessarily rebuilding an artifact, which supports manual digest promotion. Adding a file under the historical .github/workflows/** scope could trigger a build on main; inspect the current Azure graph separately before a documentation push.

Authority by job

pr-check.yml has read-only contents plus security-events: write and pull-requests: read, needed for SARIF and change detection. Its jobs do not request a cloud exchange or signer identity. Deploy’s PR-image job explicitly narrows permissions to contents read and security-events write, builds with push: false and load: true, and scans the local image.

Deploy declares id-token: write for its release graph. Main-only job conditions guard build/push, signing, and verification. This is a workflow restriction; the GCP provider separately accepts the canonical repository and does not independently constrain its ref. Cloud and signer authority therefore depend on the reviewed workflow remaining correct.

The main sequence is build-push → sign-attest → verify. Signing consumes the build’s digest output. Verify depends on both build and signing. The parallel sbom-vex job is not a dependency of that chain. Concurrency queues runs per ref with cancel-in-progress: false to avoid interrupting statement production mid-flight.

Blocking behavior

Check	Blocking decision	Limit
Semgrep	--error; outcome is captured so reports upload, then a final policy step fails relevant blocking scans	--config auto is a changing rule source; a passing scan is not a proof of safe logic
Trivy filesystem	HIGH/CRITICAL; exit 1 when fail-on-findings is true	A filesystem scan differs from final-image inspection
PR image Trivy	HIGH/CRITICAL; exit 1; baseline .trivyignore supplied	Local artifact is scanned without registry authority
Main final-image Trivy	HIGH/CRITICAL; exit 1; exact pushed digest	Image already exists in the registry if scanning fails; signing is blocked
Policy tests	Identity suffix consistency and JMESPath conditions on captured predicate	Local regression tests are narrower than live webhook decisions
Verify	Cosign checks plus digest, source, builder, entry-point, commit/material filtering	Trusted producer assertions can still be false if the producer is compromised
CycloneDX/depscan	Reachability step is continue-on-error and ends with `

The exception list is part of the image-scan policy. Its comments record reachability and architecture rationales, but several entries still refer to incomplete issue tracking. The handbook does not independently validate every exception rationale or treat a suppressed finding as repaired.

Outputs and retention

Build outputs the immutable digest; signing uploads the SPDX JSON SBOM with 90-day GitHub artifact retention and pushes image signature plus SPDX/SLSA attestations to the metadata repository. Verify emits a summary of actual checked fields. Separate CycloneDX and reachability artifacts use 30-day retention. Image scans upload SARIF, including failure paths. These outputs have different consumers and lifetimes; registry statement availability still matters for fresh admission.

There is no Helm digest-edit, pull-request creation, or Argo sync job in this GCP graph. A maintainer reviews and commits the verified digest separately. Likewise, a Terraform ruleset definition and CODEOWNERS file do not prove current remote enforcement; the historical handoff marks ruleset activation pending.

Source anchors

Deploy graph, PR checks, scanner policy, image build, research reports, and infrastructure validation.