A critical CVE drops at 2pm on a Friday. Twitter is on fire. Your CISO sends an email asking if you're affected. Your engineering team is already in weekend mode. The decision you make in the next two hours — full IR mobilisation, routine patch cadence, or something in between — determines whether the response is proportionate or expensive. Reachability is the data that makes the decision defensible. With it, you know whether the CVE is reachable in your specific deployment, and you respond accordingly. Without it, you guess, and the guess is biased toward over-response.
The four scenarios at announcement time
When a critical CVE is announced, there are four possible states for any given organisation:
- Component not in our SBOM. Not affected. No action.
- Component in SBOM, not reachable. Affected by inheritance, not exploitable. Track for routine patch.
- Component in SBOM, reachable, not actively exploited. Plan a patch within SLA, not emergency.
- Component in SBOM, reachable, KEV-listed or active exploitation observed. Emergency response.
Each state has a different appropriate response. The data needed to classify quickly is reachability evidence on the SBOM.
The 30-minute decision tree
The playbook compresses the decision into 30 minutes:
- 0-5 min. Confirm the CVE ID, affected versions, severity, KEV status, EPSS.
- 5-15 min. Query the SBOM for the affected component. Is it present? In what versions?
- 15-25 min. Pull the reachability classification for the affected functions in those versions. Reachable? Sanitizer present?
- 25-30 min. Classify into one of the four states. Mobilise accordingly.
With the right tooling, the 30 minutes is achievable. Without, the same decision takes hours and the team errs toward over-response.
What "appropriate response" looks like per state
State 1 (not present): document the negative finding, move on.
State 2 (present, not reachable): file a routine patch ticket. Schedule for the next regular update window. Document the not-reachable classification with timestamp.
State 3 (reachable, no active exploitation): file an SLA-tracked ticket. Assign within the team. Patch within the SLA. Possibly accelerate if EPSS rises.
State 4 (reachable, active exploitation): mobilise IR. Notify customers if applicable. Patch within hours, not days. Consider compensating controls (WAF rules, traffic blocks) if the patch will take longer.
The compensating control conversation
When the patch won't be quick, reachability also helps with compensating controls. If the vulnerability is reachable from a specific input path, a WAF rule on that input path is targeted compensation. Without reachability, compensating controls are blanket and disruptive.
What auditors learn from the playbook
A documented IR playbook with reachability-driven classification is exactly what regulators (SOC 2, ISO 27001, EU CRA) increasingly expect. "We mobilised based on reachability evidence" is a defensible story. "We mobilised because Twitter was on fire" is not.
How Safeguard Helps
Safeguard's incident response integrations include rapid SBOM querying, reachability classification per CVE, and KEV/EPSS integration to drive the four-state decision. Griffin AI generates the IR brief in the format the team needs. Documented IR runs are stored as audit evidence. For organisations whose IR mobilisation has historically been guess-driven, the data layer makes the response proportionate and the audit narrative defensible.