To merge two CI security gates, list what each one checks, define the merged set of checks, run the new gate in report only mode beside the old ones, compare outcomes on real pull requests, and switch repositories over in stages with a documented way to roll back.
Start with what each gate really does
Gates have names that hide their content. Open each pipeline and write down what runs, in what order, what it reads, and what makes it fail. Typical checks: dependency vulnerability findings above a threshold, license rules, secret or configuration checks handled by other tools, signature or provenance checks, and policy rules on new packages.
Note the details that differ: the threshold, whether a fail blocks merge or only warns, and how exceptions are applied.
Define the merged gate
Write the merged gate as a short spec, not as pipeline code first.
- Which checks run on every pull request, which on the main branch, which on release
- What each check blocks and what it only reports
- How exceptions are requested and expire
- Where results are shown to developers
Keep the first version modest. It is easier to add a check than to remove one that teams rely on.
Run in parallel
For a few weeks, run the new gate in warn mode next to the existing ones. For each pull request, compare: did the new gate agree with the old one? Collect disagreements into a list.
| Disagreement | Likely cause |
|---|---|
| New gate blocks, old passes | Different threshold or new rule |
| Old blocks, new passes | A check was missed in the new spec |
| Both pass, different findings | Different data sources or timing |
| Flaky result | Tool timeout or network dependency |
Resolve each one on purpose. Some will reveal that an old gate was too loose, some that the new one is too strict.
Watch the cost of time
A slow gate gets bypassed. Measure how long the merged gate adds to the pipeline, and set a budget. See how long can a security scan take in CI, time budgets.
Cut over in stages
- Pilot with one friendly repository on each side.
- Move low risk repositories next.
- Move critical repositories after a clean period.
- Remove the old gates only when the last repository has moved.
Keep a one line rollback: a flag or a pipeline include that restores the old gate. Test the rollback before you need it. A related walkthrough is change a live CI gate policy: replay, announce and roll back.
Decide what happens when the gate itself fails
If the scanning service is unavailable, does the build pass or fail? Decide, write it down, and apply it equally to both teams. Related: what should an API do when its policy engine is down.
Try it yourself
Click through it at your own pace, or open it full screen. Follow the check results on the pull request, and note which ones block and which only inform.
Safeguard offers policies and gates for pull requests that can start in a warning role, so you can compare results before anything blocks a merge.
Quick check
Should we run both gates forever?
No. Parallel running is a short comparison phase. Duplicate gates double the cost and the noise.
What if the two gates fail different builds?
Review each disagreement, decide which result is right, and adjust the merged spec before cutover.
Last reviewed: 19 October 2026.
