Yes, but by design and with a record. A hotfix path can run a narrower, faster set of checks, keep comments to blocking issues, and allow a named approver to override. It must also schedule the full scan afterwards. An improvised bypass is a loophole. A designed one is a control.
The problem to solve
During an outage, the normal pull request flow feels slow, and people reach for the admin merge button. If the only way through is to disable the security check, it gets disabled with no record and sometimes stays off. A defined hotfix path removes that temptation.
What changes in hotfix mode
| Aspect | Normal | Hotfix |
|---|---|---|
| Checks run | Full set | Fast set: dependency changes, high confidence rules |
| Comments | Capped, ranked | Blocking issues only |
| Gate | Policy as written | Same for critical findings, warn for others |
| Approver | Code owner | Code owner plus on call lead |
| Afterwards | Nothing | Full scan within a set window, ticket opened |
The gate for critical, reachable findings should not relax. An emergency fix that introduces a new critical vulnerability trades one incident for another.
How to trigger it
Use a label or a branch naming rule that only specific people can apply. GitHub protected branch settings and code owner requirements let you require review even for urgent changes, and you can restrict who can apply labels in your own tooling. The key is that the trigger is explicit, visible and logged, so it can be reviewed later.
Record the override
For every use of hotfix mode, capture who, when, why, which checks were narrowed, and the follow up ticket. This is the same evidence an auditor would want for an emergency change. Our post on standard, normal and emergency change classes in pull requests shows one way to label them.
Close the loop
Within a set window, run the full scan on the merged change. If it finds new problems, open a normal pull request to fix them. Report the count of hotfix uses each month. A rising count is a signal that your normal path is too slow, which is the real problem to fix.
Test the path before you need it
Run a drill. Make a small change, apply the hotfix label, and confirm the narrowed checks run, the approver rule works, and the follow up task appears. A path nobody has exercised will fail at the worst moment.
Try it yourself
Click through it at your own pace, or open it full screen.
Identify which gate conditions you would keep in a hotfix and which you would loosen.
Safeguard policies and gates can be configured per path or condition, which supports a narrower emergency profile. Try the free scan.
Quick check
Is a hotfix label a security risk?
It can be if anyone can apply it. Restrict who can use it and log every use.
Should hotfixes skip dependency checks?
Generally no. Dependency review is fast and catches costly mistakes, so keep it in the narrow set.
Sources
Last reviewed: 19 October 2026.
