Yes. A pull request gate teaches when its failure message names the problem, explains the risk in a sentence, and shows the fix, at the moment the developer is already looking at the code. A gate that only says "blocked" trains people to work around it.
Definition
A gate is an automated check that must pass before a change can merge. A teaching gate is one whose output is written for the developer, not for the security group. It pairs enforcement with a tiny lesson.
Anatomy of a teaching message
- What: "Hardcoded credential found in config.py line 12."
- Why: "Anyone with repository access, and anyone who sees this commit later, can use it."
- Fix: "Move it to the secrets manager and load it at runtime. Rotate the exposed value."
- Where to learn more: a link to a short internal note or a worked example.
- Who to ask: the team's champion or a channel.
Keep it under 100 words. If a message needs more, write a lab and link it.
Block, warn or inform
| Severity or type | Behavior | Why |
|---|---|---|
| Exposed secret | Block | Immediate harm, easy to fix |
| Known exploited vulnerability in a reachable path | Block | High risk |
| High severity, no fix available | Warn, require a recorded decision | Cannot fix, can manage |
| Medium findings | Warn with a deadline | Avoid fatigue |
| Style or low issues | Inform | Do not train people to ignore the gate |
Choosing the blocking set is a policy decision, so write it down and agree it with engineering leads. A gate that blocks too much will be disabled.
Tuning rules
- Start in warn mode for two weeks and look at the volume.
- Fix noisy rules before enforcing.
- Provide a clear exception path with an owner and an expiry date.
- Report on how often each rule fires and how often exceptions are used.
- Retire or rewrite messages that people routinely misunderstand.
Make learning visible
Once a month, the champions look at the top three gate failures and decide whether to write a lab or change a default. If a rule fires on the same mistake repeatedly, the problem is the template or the tooling, not the person.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what the message says when a change fails, and ask whether a new developer would know what to do next.
Where Safeguard fits
Safeguard provides policies, gates and guardrails, along with dependency scanning, so teams can decide which findings block a merge. You can try a free scan.
Quick check
Will gates slow developers down?
Noisy ones will. Start in warn mode, tune, and block only for clear, fixable problems.
Should every failure link to training?
Link the common ones. For rare cases a clear message is enough.
Last reviewed: 19 October 2026.
