A go/no-go checklist for a security upgrade confirms five things: the fix addresses the vulnerability you are exposed to, the build is reproducible, tests and a smoke check pass, a rollback path exists, and someone is watching the rollout. If any item is missing, the answer is no-go until it is fixed or consciously waived.
Why a checklist at all
Security upgrades are done under time pressure, which is when skipped steps cause outages that make the next upgrade harder to approve. A checklist moves the decision from a mood to a list. It also gives the person approving the change something to point at later.
Keep it short enough to finish in ten minutes. Anything longer gets ticked without being read.
The checklist
Copy this into the pull request template.
Before merge
- The advisory is linked, and the affected version range includes what we run.
- The fixed version is the one in the lockfile, not just in the manifest.
- We checked whether our code reaches the vulnerable function, and recorded the answer.
- The lockfile diff was read. Any package that crossed a major version has a note.
- The unit and component suite passed, and the smoke test passed on a build made from the lockfile.
Before rollout
- A rollback is written down: the previous artifact or lockfile, who runs it, and how long it takes.
- Database or config changes are backward compatible, so rolling back does not strand data. See expand and contract migrations.
- A rollout plan exists: staged where possible, with the metrics to compare and the point where we stop.
- The on-call person knows the change is going out.
After rollout
- Error rate and latency for the new version matched the old over the agreed window.
- A request that would have hit the vulnerability now behaves safely, and the result is saved as evidence.
- The ticket records the version, date and who verified.
Stop rules
Decide in advance what turns a go into a stop. Examples that work in practice:
| Signal | Action |
|---|---|
| Smoke test fails | Stop, do not widen, bisect the change |
| New version error rate above control by an agreed margin | Roll back, investigate |
| Rollback not tested or not written | No-go until written |
| Advisory scope unclear | Escalate, do not guess |
Agree the margin before the rollout. Choosing it after you see the numbers is how bad releases get rationalized.
Waivers
Sometimes the right call is to ship with an item missing, for example during an active exploit. Allow it, but require a named approver, the missing item, the reason and a date to close the gap. A waiver with a date is a decision. A waiver without one is a habit.
How this connects to urgency
A checklist should not slow an emergency. For a vulnerability under active exploitation, the same list applies with shorter windows and a smaller smoke set. Our guide to emergency versus routine patching covers how to decide which lane a change belongs in.
Safeguard's policies and gates can enforce parts of this list automatically on a pull request, such as requiring that a fix pull request pass your checks before merge. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which conditions block the merge and which only warn.
Quick check
Who should approve a go?
The service owner, with a second reviewer for changes to authentication, cryptography or data handling. The approver should be able to read the checklist and say why each item passed.
Is a rollback plan needed for a patch bump?
Yes. A one-line rollback, such as redeploying the previous artifact, is enough, but it must exist before you start.
Last reviewed: 19 October 2026.
