A critical CVE is announced in a widely-used library. Walk me through the first four hours.

Hour 1 — determine exposure

Query the SBOMs across the estate, including transitive dependencies. This is the moment that justifies having them: without, this hour becomes days of searching repositories and running systems, and the answer is never confidently complete.

Establish three things: which services include the library, which versions, and which of those are actually reachable — a vulnerable library present but never invoked on a reachable code path is a different priority from one in the request handler.

Then check whether the vulnerable configuration applies. Many CVEs require a specific feature or setting, and the advisory will say. A large share of "affected" services often are not.

Hour 2 — contain before you fix

Virtual patch at the WAF or gateway if the exploit has a recognisable signature. This buys time and is the WAF's most valuable capability.

Restrict egress from affected services if the exploit requires a callback — this is what made Log4Shell survivable for organisations that had it, because the exploit needed an outbound LDAP connection.

Disable the vulnerable feature if configuration allows it.

Increase monitoring on the affected services for exploitation attempts, and check whether exploitation has already occurred — retrospectively, against logs, over a period matching plausible dwell time.

Hour 3 — patch the highest-exposure services

Internet-facing first, then those handling sensitive data, then internal. Deploy through the normal pipeline if it is fast; this is what a fast pipeline is for, and organisations that cannot deploy quickly discover it at exactly this moment.

Hour 4 — communicate and track

A single tracked list of affected services with status. Stakeholder communication with what is known and what is not. And a decision on customer notification if exploitation is suspected, which has a regulatory clock attached.

What determines whether four hours is enough

Not diligence — architecture. Whether an SBOM exists and is queryable. Whether dependencies are inventoried automatically. Whether services can be rebuilt and deployed quickly. Whether egress is restricted. Whether logs are retained long enough to check for prior exploitation.

Each of those is a design decision made months earlier, and together they are the difference between a four-hour response and a four-week one.

What a strong answer adds

Noting Equifax as the counter-example: the patch existed two months before the breach, and the controlling failure was that the asset inventory was incomplete, so the instruction to patch never reached the system's owners. Mean time to patch is an architectural property — determined by inventory, automation and deployability — not a measure of how hard the team tried.