BlastGuard kill-switch: blast radius before promote

Scanner ticket counts are not a control plane. A CVE that never reaches a running, internet-exposed workload is noise. A CVE that does — and still ships through CI or GitOps — is a missing kill-switch.

This guide is scoped to BlastGuard and the BlastGuard case, with the Policy as Code Guardrails case as the pattern companion. Claims about decisions, exit codes and remediation apply on that project's corpus only (fixtures, kind demos, documented CI runs).

Why finding counts fail as a gate

Most pipelines already run Syft/Grype (or equivalent) and attach an SBOM. That answers "what is in the image?" It does not answer:

• is the vulnerable package present in a running workload?
• is that workload network-reachable from a path that matters?
• was execution observed for the risky component?
• did a signed VEX statement bind to this exact digest?

Without those answers, CI either blocks everything (noise) or ignores severity thresholds (false calm). The Policy as Code Guardrails case documents the gate pattern; BlastGuard is where supply-chain decisions that policy can enforce are proved on a corpus.

Decide on reach, not on ticket volume

BlastGuard's documented lifecycle:

1. Discover — SBOM, advisories, VEX, Sigstore provenance enter the twin.
2. Trace — walk CVE → package → image → workload → service → ingress; prune VEX / not-running / unreachable branches.
3. Decide — return ALLOW / WARN / QUARANTINE / BLOCK with an explicit reason; CLI exit codes gate CI or GitOps promotion.
4. Verify — after a fix image, recompute radius; zero affected running paths means remediation proved.

Admission (Kyverno / policy-controller) is a reference integration fed by these decisions, not an in-tree replacement for the scanner stack. BlastGuard sits above Syft/Grype/GUAC/Sigstore.

Fail-closed when evidence is thin

From the case evidence narrative (checked 2026-11-02):

That posture matches the agent and GPU planes on this site: unavailable or incomplete policy must not become an implicit allow (Agent Security Contract, GPU Admission on Kueue).

Where the kill-switch sits in GitOps

Treat the decision CLI as a promotion gate:

• CI — non-zero exit on BLOCK / incomplete inventory stops the merge or the image promote job.
• GitOps — same exit code in a PreSync / promotion workflow before Argo CD or Flux moves desired state (Argo CD vs Flux).
• Human override — WARN can page; BLOCK should not be a dashboard-only event.

Do not invent a second policy language inside the CD tool. Keep the decision envelope exportable and hash-checkable, then let GitOps reconcile only what the gate allowed.

How this relates to agent security

Supply-chain kill-switches and MCP tool gates solve different planes:

Wire them with the same habit: explicit verdict + evidence + fail closed.

Operational checklist

• Ingest SBOM + advisories + VEX + provenance into a twin you actually maintain
• Require inventory_complete (or equivalent) before any ALLOW that claims "no blast radius"
• Bind VEX / attestations to exact digests; reject prefix or name mismatches
• Gate CI and GitOps promote on CLI exit codes from the decision engine
• Rehearse BLOCK on an exposed path and WARN on an internal twin of the same CVE
• After patch, re-run until remediation is proved (radius zero on running paths)
• Keep Kyverno/admission as consumer of decisions, not a second opaque policy island
• Export decision envelopes next to ASC / GPU admission evidence for one audit story

References

• BlastGuard case: https://justrunme.com/cases/blastguard/
• Repository: https://github.com/justrunme/blastguard
• Evidence file: https://github.com/justrunme/blastguard/blob/main/docs/EVIDENCE.md
• Policy as Code Guardrails: https://justrunme.com/cases/policy-as-code-guardrails/
• Agent Security Contract: https://justrunme.com/cases/agent-security-contract/
• Argo CD vs Flux: https://justrunme.com/guides/argocd-vs-flux/