The minimum defensible test set for an emergency patch is a build from the lockfile, a startup and health check, a smoke test of your critical journeys, one test that the vulnerable behavior is now blocked, and a small staged rollout with a ready rollback. Everything else is deferred, with a named owner and a deadline.
What counts as an emergency
Emergency means active exploitation or an exposure you cannot mitigate in time, not just a high score. If you are unsure which lane a change belongs in, read emergency patch versus routine patch criteria first. Most patches are routine and deserve the full process.
The emergency test set
| Step | Purpose | Typical time |
|---|---|---|
| Build from the lockfile with the fixed version | Reproducible artifact | Minutes |
| Start the service and pass health checks | Catches import and config errors | Minutes |
| Smoke test of the three or four critical journeys | Catches obvious breakage | A few minutes |
| One test of the vulnerable behavior, before and after | Shows the fix took effect | Minutes |
| Small production slice, per-version comparison | Catches what tests miss | As needed |
| Rollback ready and verified to exist | Safe retreat | Prepared in advance |
This is a floor. Add checks as time allows, in this order: unit tests for callers of the package, then the integration suite, then the rest.
Preparation makes it possible
You cannot invent a fast pipeline during an incident. Prepare before:
- A smoke suite that runs in a few minutes. See what a smoke test should check.
- Immutable artifacts so rollback is a redeploy.
- A pipeline path that skips the slow nightly jobs but not the safety gates.
- A short list of the critical journeys, kept current.
- A kill switch for risky features. See feature flag kill switch for security incidents.
What not to skip
Do not skip the lockfile-based build, because a rebuild from loose ranges can change other dependencies at the worst moment. Do not skip the rollback check. Do not skip telling the on-call person. Those three cost almost nothing and prevent the worst outcomes.
What to defer and how to track it
Write each deferred item as a ticket: the full suite run, a deeper integration pass, performance checks, a review of the lockfile diff, documentation. Give each an owner and a date within days. When the emergency is over, run the deferred items against what shipped. If they find a problem, you want to learn that before the next incident.
Mitigate first if you can
If a temporary mitigation exists, such as disabling the affected feature, blocking a request pattern at the edge or restricting access, apply it while you test the patch properly. A mitigation that buys a day of testing is often a better trade than an untested patch. See emergency mitigation when no patch exists yet.
After the incident
Review how long each step took and which one you wished you had. Trim the slow ones, automate the manual ones and repeat the drill. Record in the change ticket what was tested and what was deferred, so the record is honest.
Safeguard's zero-day discovery and monitoring can surface a new advisory affecting your inventory, and its reachability analysis helps you judge how urgent it is for your code. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory is matched to the components you actually run.
Quick check
Can I skip tests entirely in an emergency?
You can shorten them, but not drop them. A broken patch during an attack is worse than a delayed one, so keep the smoke test and rollback.
Who signs off on reduced testing?
Name an approver in the ticket, such as the service owner, with the deferred items and their dates listed.
Last reviewed: 19 October 2026.
