Ask the demo to block a pull request using a rule you choose, then to allow it after an approved exception. That one exercise shows whether policy gates are real controls or just comments. Also ask what happens when the scanner itself is down.
What a gate is
A gate is a check in your pipeline that passes or fails a change based on a rule. A typical rule might be "fail if a new dependency has a critical vulnerability with a fix available". A gate that only posts a comment is advice. A gate that can stop a merge is a control.
The block and allow test
- Write the rule yourself. Keep it simple, such as blocking new findings above a severity you pick. Do not use the vendor's template without reading it.
- Prepare two branches. One adds a dependency with a known vulnerability. One adds a clean dependency.
- Open both pull requests. Watch the checks.
- Expect one fail and one pass. If both pass or both fail, ask why.
- Request an exception. Ask how a developer asks for one, who approves it, and whether it expires.
- Re-run. After approval, the blocked PR should pass without code changes.
What to look at
| Area | Good sign | Concern |
|---|---|---|
| Message | Says what failed and how to fix it | A bare red cross |
| Scope | New findings only, by default | Fails on old debt developers did not add |
| Exceptions | Reason, approver, expiry date | A permanent silent bypass |
| Audit trail | Who approved and when | No record |
| Speed | Result in minutes | Long waits stall developers |
The second row matters most for adoption. If a gate blocks pull requests over problems that already existed, developers will resist it. Starting with new findings only, and tightening later, is the usual path.
Failure behavior
Ask the awkward question: if the scanning service is slow or unreachable, does the pipeline fail closed (block) or fail open (pass)? Neither answer is wrong. A team shipping hotfixes may need open. A regulated team may need closed. The point is that you choose, and that the choice is documented.
Report only first
A sensible rollout runs the rule in report-only mode for a couple of weeks. Developers see what would have been blocked, you tune the noise, and then you switch to enforcing. Ask whether the tool supports this mode per rule.
Who owns the rules
Ask where rules are stored. Rules kept as configuration in version control can be reviewed and rolled back. Rules living only in a web console are harder to audit. Neither is automatically better, but you should know which you are getting.
Where Safeguard fits
Safeguard provides policies, gates and guardrails as GA capabilities, so you can set rules for pull requests and builds. The demo below walks through a gated pull request.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what the developer sees when a change is blocked, and whether the message tells them how to proceed.
Quick check
Should a gate block on all existing findings?
Usually not at first. Block new findings, track the backlog separately, and tighten over time.
How long should a gate check take?
Long enough to be accurate and short enough that developers do not work around it. Measure it on your largest repository during the demo.
Last reviewed: 19 October 2026.
