A CI security gate is a step that runs a scanner and fails the build when results break a rule. The script takes an hour. Keeping the gate fair, fast and trusted, with exceptions and a fallback when the scanner is down, is the real work.
Build a minimal gate
- Run the scanner on the pull request.
- Compare results against a baseline so old findings do not block new work. Gitleaks supports this with a baseline path, reporting just new findings.
- Use exit codes. Gitleaks returns 0 for no leaks and 1 for leaks or an error, and the leak code can be changed with an exit code flag.
- Fail on a narrow rule first, such as new critical findings with a known fix.
- Print a message that tells the developer what to do next.
gitleaks git --baseline-path baseline.json --report-path report.json
What you must maintain
| Item | Why it needs care |
|---|---|
| Baseline | Goes stale as code changes |
| Allowlists | Grow without review unless owned |
| Rule thresholds | Need tuning as noise changes |
| Runtime | Slow gates get skipped |
| Fallback | Decide what happens when the scanner or its data source fails |
Exceptions are the hard part
Developers will hit false positives. Give them a documented route: an inline marker or ignore file with a reason, reviewed by a named person, with an expiry date. Without it, they will find their own route around the gate.
Test the gate itself
Add a deliberately bad test change to a sandbox repository and confirm the gate blocks it. Run that check on a schedule so a broken gate is noticed.
Compare with a managed gate
A platform gate brings policy as configuration, exception workflow, and a fallback mode. You trade control for upkeep. If your rules are unusual, a custom script may fit better, and the two can coexist.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
Measure whether the gate works
Track three numbers: how often the gate blocks, how often a block is overridden, and how long the gate adds to a build. A gate that never blocks may be too lax. One that is overridden often is probably noisy. One that adds minutes will be bypassed. Review the numbers monthly and adjust the rules rather than leaving them as first written.
Try it yourself
Click through it at your own pace, or open it full screen. Open a failing pull request and see what a developer needs from the message to fix it.
Quick check
What should a first gate block?
A narrow rule such as new critical findings with a fix available, so developers learn to trust it.
What if the scanner is down?
Decide in advance whether to warn or block, and record the choice in your runbook.
Sources
Last reviewed: 19 October 2026.
