A security check should stop the line only when it is reliable, narrow and actionable, meaning a failure points to a real problem the author can fix now. For anything softer, record the finding and fix it in planned work. A check that stops the line often and wrongly teaches people to route around it.
What stop the line means
DORA's continuous integration page describes an agreement that when the build breaks, fixing it takes priority over any other work. Failing tests are treated as urgent because trunk should always be in a working state. If automated tests fail, the team stops and fixes the problem immediately.
The question is whether a security check deserves the same status.
A test for whether a check qualifies
| Question | If yes | If no |
|---|---|---|
| Is a failure almost always a real problem? | Candidate to block | Report only |
| Can the author fix it in this change? | Candidate to block | Create a ticket |
| Is it fast enough to run on every commit? | Candidate to block | Move to a schedule |
| Is there a logged way to override it? | Safe to block | Add one before blocking |
All four need to be yes. A check that fails one is better as a report.
Good candidates to block
- A newly added dependency with a known exploited critical vulnerability and a fix available.
- A committed credential found by a check you already run.
- A policy violation, such as a disallowed license or an unapproved package category.
Poor candidates to block
- Every medium finding in a large legacy codebase. The author cannot fix them in the change.
- A noisy rule with a high false positive rate.
- A slow scan that sometimes times out, which makes it flaky.
Handling the legacy backlog
Block on new findings introduced by the change, and track the existing backlog separately. This way the gate holds the line without punishing authors for old debt. It also avoids turning the trunk red permanently, which would erase the signal.
The cost of a flaky gate
Developers rerun the job until it passes, or add exclusions, or disable it. Each response weakens the control. Track how often security jobs are rerun, how many exclusions exist, and how many overrides are used. These are the early signs that stop the line has lost credibility.
Setting the rule
- Start with one narrow blocking rule.
- Publish the rule and the override path.
- Review overrides weekly for the first month.
- Widen only when overrides are rare and justified.
Link this to delivery metrics: if lead time grows after the gate goes live, see whether security gates hurt lead time.
Quick check
What should happen when the scanner itself is down?
Decide in advance whether to block or pass, and log the choice. See when the scanner is down, block or pass.
Who fixes a red trunk caused by a security check?
The author of the change, with help from security if needed. The agreement should be the same as for failing tests.
Try it yourself
Click through it at your own pace, or open it full screen.
See what a blocked pull request shows the author, and whether the next step is clear.
How Safeguard fits
Safeguard offers policies, gates and guardrails with dependency scanning, so you can choose a narrow blocking rule. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, Continuous integration: https://dora.dev/capabilities/continuous-integration/
Last reviewed: 19 October 2026.
