A good gate policy fits on one page and answers six questions: what is covered, what blocks, what warns, how to get an exception, who may bypass in an emergency, and when the policy is reviewed. If a developer cannot find the answer in two minutes, the policy is too long.
The six sections
| Section | Question it answers | Example line |
|---|---|---|
| Scope | Which repositories and branches? | All repositories deploying to production, protected branches |
| Blocks | What fails the build? | New Critical findings in runtime dependencies; known exploited findings |
| Warns | What is reported but not blocked? | High findings, dev dependencies, unknown licenses |
| Exceptions | How do I request one? | Pull request to the exceptions file, security review, expiry required |
| Bypass | Who, when, how recorded? | Release on call team during incidents, ticket required |
| Review | When does this change? | Quarterly, owner named |
Write rules, not aspirations
"We take vulnerabilities seriously" is not a rule. "New Critical findings fail the build" is. Each line should be testable by a machine or a reviewer.
Use the language of your tools, such as the severity names and scope names your scanner uses, so the policy maps to configuration without translation.
A starter text
Scope: all services that deploy to production.
Blocks: new findings rated Critical in runtime dependencies;
any finding on the known exploited list in shipped code.
Warns: High findings; dev dependency findings; unknown licenses.
Exceptions: recorded in policy/exceptions, with owner, reason,
approver and an expiry no longer than 90 days.
Bypass: release on call team only, ticket required, reviewed
within one business day.
Review: quarterly by the security lead.
Steps to adopt it
- Draft with a developer and a security person in the same room.
- Run the draft rules in observe mode for two weeks.
- Adjust, then publish the page where developers already look, such as the repository.
- Enforce through configuration kept in version control.
- Link each rule to the check that enforces it.
Keep policy and configuration in sync
Drift is the enemy. If the page says Critical and the pipeline says High, auditors will notice. Review the two together, and treat a mismatch as a defect.
Do not name the scanner in the policy. Tools change, rules should not have to.
Quick check
Should the policy list every license?
Link to the approved list instead. Keep the one page for rules, not data.
Who signs off the policy?
Security and engineering leadership together, so enforcement has support.
Safeguard's policies, gates and guardrails let you express rules like these and keep them under version control. Start with the free scan at gold.safeguard.sh/scan to see which rules would have fired.
Last reviewed: 19 October 2026.
