Enforce each policy at the earliest point where it can be checked reliably, and repeat the important ones later. Source checks are fast, plan checks see real values, and checks against live cloud state catch changes made outside code. No single point is enough.
The five places
1. Editor or pre-commit. The cheapest feedback. Good for syntax, formatting and obvious rules such as missing encryption flags. Easy to skip, so never the only gate.
2. Pull request on source. Scans configuration files before merge. Fast and visible to reviewers. Limitation: values built from variables, modules and data sources are not fully known from source alone.
3. Pull request on the plan. Evaluates the planned changes with resolved values. Catches things like a variable that expands to an open CIDR. Costs more, since the pipeline needs credentials to produce a plan, and the plan file itself is sensitive because saved plans can contain secrets in cleartext.
4. Admission or apply time. Blocks the change at the moment of deployment, in the cluster or the deploy pipeline. Strong because it cannot be bypassed by skipping earlier steps, but feedback arrives late.
5. Against live state. Scans what exists in the cloud account. The only place that sees console changes and resources created outside code, and the place where drift appears.
What each one catches
| Risk | Best place |
|---|---|
| Missing encryption flag | Source check |
| Open CIDR from a variable | Plan check |
| Public bucket created by hand | Live state |
| Privileged workload in a cluster | Admission |
| Secret committed in a variable file | Editor and source |
| Policy bypassed by an admin override | Live state |
A simple rule for placement
- Put cheap, deterministic rules early.
- Put rules that depend on resolved values at plan time.
- Put must-never-happen rules at the apply gate as well.
- Put everything you care about in a live scan too, because people change things by hand.
The important policies run in at least two places.
Make failure modes explicit
Decide for each rule: does a failure block the merge, or warn? Start new rules in warn mode, measure noise, then switch to block. A gate that blocks on false positives trains people to look for bypasses. Record every exception with an owner, a reason and an expiry date.
Who owns what
- Platform or security team: the policy library and the gates.
- Application teams: fixing findings, or requesting exceptions.
- Auditors or compliance: evidence that the gate ran, and what it decided.
Safeguard's policies, gates and guardrails apply rules at pull request time, and its compliance and evidence automation keeps a record of the results.
Click through it at your own pace, or open it full screen.
Quick check
If we scan pull requests, do we still need a live scan?
Yes. Pull request checks cannot see console changes or resources created outside code. A live scan covers those.
Should new policies block immediately?
Usually start in warn mode, measure false positives, then move to block once the rule is trusted.
Sources
Last reviewed: 19 October 2026.
