Yes. Use one policy with three strengths: warn in development, block known-bad in staging, and enforce in production. Developers get fast feedback without being stopped from working, and production gets a hard line. Keep the rules identical across tiers so nothing is a surprise at promotion, and vary only the action.
Why one rule set with three actions
If staging has different rules from production, you find out about violations when you try to ship. If dev has no rules, developers never see the feedback early. The better design is a single list of rules, each with an action per environment: log, warn or block. Kubernetes' own pod security admission works this way. The Pod Security Admission documentation describes modes that either enforce, audit or warn for the same standard, which makes a tiered rollout natural.
An example matrix
| Rule | Dev | Staging | Production |
|---|---|---|---|
| Image from approved registry | Warn | Block | Block |
| Image referenced by digest | Log | Warn | Block |
| Critical finding with a fix available | Warn | Block | Block |
| Critical finding, no fix available | Log | Warn | Warn with expiry |
| Base image older than limit | Log | Warn | Warn, block when far past limit |
| SBOM present for the digest | Log | Warn | Block |
| Runs as root | Warn | Warn | Block |
These are example values, not a standard. Start from your risk and tighten as your pipeline matures.
What each tier is for
Dev is a learning tier. The purpose of a warning there is to change what the developer does before the pull request, so keep messages short and link to the fix.
Staging is a rehearsal. Blocks there should match production, with the exception of rules you are still rolling out. Failing in staging is cheap, which is the point.
Production is where blocks have real consequences. Add a planned bypass for emergencies. See emergency exceptions to a failing gate.
Rolling out a new rule
- Add it in log mode everywhere and read the results for two weeks.
- Switch dev to warn.
- Fix or exempt the top offenders.
- Switch staging to block.
- Switch production to block.
A rule that blocks on day one tends to be turned off by day three. See rolling out admission policy with warn and audit first.
Watch for environment leaks
Tiering fails when the environment boundary is soft. If a developer can deploy a production workload into the dev namespace, or the same cluster hosts both, the tiers describe intentions rather than controls. Use separate clusters or strong namespace controls, and remember that namespaces are not a security boundary on their own.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a gated pull request and note what a developer sees when a rule would fail.
Where Safeguard fits
Safeguard supports policies, gates and guardrails that can warn or block on findings, so the same rule can carry a different action per environment. Start from a free scan.
Quick check
Should dev ever block?
Rarely. Block only for things that are never acceptable anywhere, such as an unapproved registry. Warn for the rest.
Why not have strict rules everywhere?
Developers route around controls that stop them from working. Warnings in dev keep feedback early without halting experiments.
Sources
Last reviewed: 19 October 2026.
