On day one of a new flaw in a component your devices ship, work in this order: scope which releases and devices contain it, apply any mitigation you can push quickly, decide who is exposed, tell the people who need to know, and only then stage the fix. Speed comes from having the inventory ready before the day.
Hour by hour
| Window | Goal | Output |
|---|---|---|
| First hour | Confirm the advisory and name an owner | One incident lead |
| Hours 1 to 3 | Scope by SBOM search and device join | List of releases and units |
| Hours 3 to 6 | Find mitigations | Config change, service disable, firewall rule |
| Hours 6 to 12 | Exposure and customer decision | Which groups are at risk |
| Hours 12 to 24 | Communicate and build the fix | Notice draft, fix branch, test plan |
These are targets, not promises. A small team may take longer, but the order holds.
Steps in more detail
- Confirm the facts. Read the advisory from the maintainer or a trusted database. Note affected versions and any exploit evidence.
- Search release SBOMs. Include vendored and transitive copies, and the releases that no longer ship but still run.
- Join to devices. Count by model, release, and reachability from the network.
- Look for a mitigation. Disabling a service, changing a setting, or blocking a port can reduce risk before any firmware moves.
- Decide exposure. Reachable and internet facing units come first.
- Tell customers and partners. Say what you know, what you do not, and what to do now. Avoid claiming a device is safe until you have checked.
- Build and stage the fix. Use your normal approval step, small first group, and stop rules. Do not skip them for speed, since a bad emergency update can be worse than the flaw.
What to prepare in advance
Keep a current SBOM for every live release, an owner list for each component, a template for customer notices, and a rehearsed emergency build path. Practice finding a named component across all releases in under an hour.
What not to do
Do not announce a patch date you cannot meet. Do not rely on a single data source, since early advisories change. Do not mark a device not affected without checking its release.
After day one
The second day is for follow through. Keep monitoring the advisory for changes in affected versions or exploit status. Track the staged rollout against your stop rules. Update the customer notice when facts change, and say so. Once the fix is out, hold a short review: how long scoping took, what data was missing, and what to prepare for next time.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory is tied to the components you already track. That tie is the scoping step in minutes instead of days.
Safeguard stores SBOMs and matches new advisories continuously, and its zero-day discovery work flags issues in components. Try gold.safeguard.sh/scan.
Quick check
Should I wait for a patch before telling customers?
Share what you know and any mitigation as soon as you have confirmed scope. Do not wait for the fix if customers can act now.
Can I skip approval for an emergency update?
Use a faster path, but keep a second reviewer and the stop rules.
Last reviewed: 19 October 2026.
