To patch a vulnerable dependency in an emergency: find every service that uses it, choose a fixed version or a mitigation, run an accelerated test, deploy through your pipeline, and verify the deployed artifact. NIST describes emergency patching as the normal process on a highly accelerated schedule, not a different process.
Step 1: Find where it lives
Search lockfiles and built artifacts for the package, including transitive copies. Check images too, since a library can sit in a layer outside the repo. An up to date SBOM turns this from hours into minutes.
Step 2: Confirm you are affected
Read the advisory. Is your version in range? Is the vulnerable function reachable in your code? A vulnerable package that never calls the bad code is lower urgency than one on a public endpoint. Reachability analysis helps here.
Step 3: Choose the response
| Situation | Response |
|---|---|
| Fixed version exists, low change risk | Patch now |
| Fixed version exists, major version jump | Patch if you can test fast, otherwise mitigate and schedule |
| No fix yet | Mitigate: disable feature, restrict access, filter inputs |
| Dependency abandoned | Replace or fork, mitigate meanwhile |
NIST lists emergency mitigation and unpatchable assets as their own scenarios, and says mitigations should be replaced by permanent fixes with scheduled removal.
Step 4: Make the change small
Bump only the vulnerable package to the minimum fixed version. Dependabot security updates follow the same idea, opening a pull request to the minimum version that includes the patch. Avoid bundling unrelated upgrades into an emergency change.
Step 5: Test fast, not skip
Run the full automated suite. Add a quick manual pass on the path that uses the library. NIST notes that even in an emergency it may help to deploy first to a few canary assets, for a period that could last minutes to hours.
Step 6: Deploy and verify
- Deploy to canary, then widen.
- Check the running artifact reports the fixed version, not only the repository.
- Rebuild and redeploy every service and image that carried the library.
- Look for signs of earlier exploitation if the issue was exploited in the wild. See were we exploited before the patch.
Step 7: Close the loop
Write down the timeline, the services touched, and anything slow. Update the inventory, and add a regression check so the vulnerable version cannot return. Plan the permanent fix if you used a mitigation.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a fixed version and a proposed change show up together.
Where Safeguard fits
Safeguard's dependency scanning and fix PRs for dependency issues support this flow. Autonomous remediation is off by default and every category starts on Manual, so you approve each change.
Quick check
Should I merge without review in an emergency?
Keep at least one reviewer, even if fast. A rushed unreviewed change is a common cause of a second incident.
How do I know every service was patched?
Compare the inventory before and after, and verify the deployed artifact on each service, not just the merged pull request.
Sources
Last reviewed: 19 October 2026.
