Yes, run the gate on reverts too, because a revert is still a code change and can reintroduce old problems. But configure it to judge the revert against what is deployed today, so a rollback that removes risk is not blocked by findings that already exist.
Why reverts are a special case
A revert is the fastest way to undo a bad release, and it usually happens under pressure. That pressure is exactly when teams are tempted to switch the gate off. A gate that blocks every rollback teaches people to bypass it, and bypasses made in an incident are the ones nobody reviews afterwards.
GitHub describes reverting a merged pull request as creating a new pull request that reverts the original merge commit. It is an ordinary pull request, so your required checks apply to it like any other. That is the right default. The question is what the checks compare against.
The trap: a revert can bring old vulnerabilities back
Suppose a release upgraded a library to fix a known vulnerability, and the release broke something else. Reverting the whole pull request also reverts the library upgrade. The code you restore is the code that had the vulnerability.
A gate that only looks at new findings in the diff will flag this correctly, because the old dependency version is newly present compared with the current main branch. A gate that does not run on reverts will let it through silently.
What the gate should do on a revert
| Situation | Suggested gate behaviour |
|---|---|
| Revert removes risk or leaves it the same | Pass, with the normal checks running |
| Revert reintroduces a dependency version with a known vulnerability | Block or require a named approver |
| Revert touches only application logic, no dependency changes | Pass if no new findings |
| Gate itself is failing for unrelated reasons during an incident | Use the documented emergency path, not a disabled check |
The rule underneath is simple: compare the post-merge state to the current production state, not to an ideal clean state. If the revert makes things no worse, it should pass fast.
Steps to set this up
- Confirm that reverts are not excluded by branch name or commit message filters. Many pipelines skip checks on branches whose names start with revert, usually by accident.
- Make the gate diff based, so it reports findings introduced by the change. If a revert restores an old dependency version, that shows up as a new finding against the current main branch.
- Keep the checks quick. If the full scan takes long, consider a fast path that scans only changed manifests, with the full scan running after merge.
- Define the emergency path in writing: who can approve, how long the override lasts, and where it is recorded. See the override log post for what to capture.
- After the incident, open a follow-up change that re-applies the fix without the breaking part, so the vulnerable version is not left in place.
Common mistakes
Excluding revert branches from CI is the most common one. The second is treating a revert as pre-approved because the original change was approved. The original approval covered the original code state, not the one you are rolling back to. The third is forgetting the follow-up, which leaves a known vulnerable version in production for months.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a change is judged against what the pull request introduces, which is the same logic a revert needs.
Safeguard policies and gates can evaluate pull requests this way, with an audited override path for urgent changes. You can try a free scan at gold.safeguard.sh/scan to see what your current dependencies look like before you decide on thresholds.
Quick check
Can I skip the gate for a revert during an outage?
Prefer a fast, diff based gate over skipping it. If you must override, use a named approver, a short expiry and a log entry, then review it afterwards.
Does a revert need a fresh security review?
Not a full one. It needs the automated checks, and a human look only if the revert changes dependencies or reintroduces code that was removed for security reasons.
Sources
- GitHub Docs, Reverting a pull request
Last reviewed: 19 October 2026.
