Yes, define one before you need it. An emergency path for urgent security fixes shortens the route to production while keeping a minimum of review and logging. Without it, teams either wait through the normal queue or bypass controls in a panic. Decide the rules in calm weather.
Why a separate path
Most changes go through the normal pipeline, which may include approvals and scheduled windows. When an actively exploited vulnerability affects you, that timeline may be too slow. A defined path lets people move fast without inventing process under stress.
DORA's metrics help frame the stakes. Change lead time is the time from commit to production, and deployment frequency shows how often you can ship. Teams with short lead times and frequent deployments usually have a shorter emergency path to begin with, because the normal one is already fast.
What the path should contain
| Element | Content |
|---|---|
| Trigger | Criteria for using it, such as known exploitation affecting a reachable component |
| Authority | Who may declare an emergency, and a backup |
| Minimum review | One reviewer other than the author, even if brief |
| Automated checks that still run | Build, core tests, dependency scan on the change |
| Rollback plan | Written down before deploy |
| Logging | Ticket, approver, times, commit, and reason |
| After-action | A short review within a few days |
Notice that review shrinks, it does not vanish. A fix that introduces a second flaw is a common way for an emergency to become a worse one.
How it appears in DORA metrics
DORA defines deployment rework rate as the share of deployments that are unplanned but happen as a result of an incident in production. An emergency deployment for an exploited issue fits that description. If it needs a rollback or hotfix afterwards, it also counts toward change fail rate and failed deployment recovery time. Tag each emergency deployment with its cause, as in our post on tagging security hotfixes.
Do not treat a high count as shameful. A high count with fast, clean fixes is better than a low count from ignoring advisories.
Steps to put it in place
- Draft the trigger and the roles, and agree them with engineering, security and the on-call lead.
- Write the minimum checks and the logging fields.
- Run a drill using a past advisory, and time it from decision to production.
- Fix the slowest step found in the drill.
- Review each real use afterwards and adjust.
Common mistakes
- Using the path for convenience. Review use monthly.
- Skipping logging. You will need it for audits and for learning.
- Having no one with authority on weekends.
- Never practicing, so the first run is the real one.
Quick check
Should every critical vulnerability use the emergency path?
No. Use it when exploitation is known or likely and the component is reachable. Others go through the normal path with priority.
Who approves it out of hours?
Name a primary and a backup in the runbook, and test that they can be reached.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory is surfaced against what you run. That moment is the trigger for the path.
How Safeguard fits
Safeguard offers zero-day discovery, reachability analysis and autonomous remediation with fix PRs (off by default, every category on Manual), which help decide when to invoke an emergency path. Try a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
