Market Signal
The First 24 Hours After a Critical Vulnerability
A high-severity CVE just dropped in a dependency your application depends on. Your team has 24 hours before active exploitation becomes widespread. Here is a framework for making the right calls under time pressure.
A high-severity CVE just dropped in a dependency your application depends on. The CVSS score is 9.8. Active exploitation has been reported. Patches are available, but your deployment pipeline has a two-hour cycle time and your QA process takes longer.
Your team has roughly 24 hours before this is widespread. Here is how to spend them.
Hour 0 to 2: Assess blast radius
Before you do anything, you need to know what you’re actually protecting. This is not moving too slowly - it is moving precisely.
Confirm the dependency is in your stack. A CVE in a library you don’t use is noise. A CVE in a library three layers deep in your dependency tree that gets called at runtime is a different problem. Run npm audit, pip-audit, or the equivalent for your stack and confirm the vulnerable version is actually reachable.
Identify exposure surface. Is the vulnerable code on a public endpoint? Behind authentication? Reached only by internal services? The exploitability of a vulnerability depends heavily on how it’s reached. A remote code execution vulnerability in a library called only by authenticated admin endpoints is a different risk profile than the same vulnerability on a public API.
Check for mitigating controls. WAF rules, network segmentation, and input validation can reduce exploitability even without patching. These are not solutions - they are time buyers.
Hour 2 to 8: Decide your response tier
Not every critical vulnerability requires the same response. The urgency should be proportional to actual risk, not CVSS score alone.
Tier 1 - Immediate patch. The vulnerable code is on a public, unauthenticated endpoint. Exploitation is straightforward. Patches are available and can be applied with reasonable test coverage. This is your all-hands scenario.
Tier 2 - Patch within 24 hours. The vulnerable code requires authentication or is on an internal service. Exploitation is possible but not trivial. This gives you time to do a proper deployment rather than a hotfix.
Tier 3 - Mitigate and patch in cycle. The vulnerable library is present but not reachable via the attack vector described in the CVE, or effective mitigating controls are already in place. Treat this as a priority in your next deployment cycle, not an emergency.
Hour 8 to 16: Execute
For Tier 1 and Tier 2 responses:
Patch the dependency. Not the application code - the dependency itself. Update to the patched version, run your test suite, and deploy. If the patched version introduces breaking changes, that’s a separate problem - fix the breaking changes on a branch, don’t delay the security patch to do so.
Run targeted tests, not full regression. You don’t have time for a complete QA cycle. Identify the code paths that call the vulnerable library and test those specifically. This is where good test coverage pays dividends.
Deploy incrementally if you can. A canary deployment to 5% of traffic lets you catch regressions before they affect everyone. If your deployment infrastructure supports it, use it.
Communicate proactively. If you have customers who are affected or might be asking, get ahead of it. A brief, factual update - “we identified a vulnerability in a dependency, we have patched it and deployed, no data was accessed” - is better than silence.
Hour 16 to 24: Harden
The patch is deployed. The immediate risk is addressed. Now spend the remaining window on the work that prevents the next one.
Add the CVE to your dependency monitoring. If you weren’t catching this automatically, fix that. Tools like Dependabot, Snyk, or GitHub’s native dependency scanning can alert you when new vulnerabilities are reported in your dependencies.
Review related dependencies. A vulnerability in one library often signals risk in adjacent ones - same maintainer, same codebase, same underlying C library. Spend an hour reviewing the dependency neighborhood.
Document the response. What did you do, when did you do it, and what would you do differently? This is the raw material for a runbook that makes the next incident faster.
What separates good responses from bad ones
The teams that handle these well share a few characteristics. They have enough observability to quickly identify what’s reachable. They have deployment automation that makes patching low-friction. And they’ve had at least one tabletop exercise where they’ve walked through a scenario like this before it was real.
The teams that struggle tend to conflate “critical” in the CVSS sense with “our entire engineering team needs to drop everything right now.” Sometimes that’s right. Usually it’s not. Good incident response is triage, not panic.
The 24-hour window is real. Use it deliberately.