Quick reference
| Time | Step | What happens |
|---|---|---|
| T+0 | CVE published | The advisory names a package and a version range. |
| T+1 | Alert fires | Dependabot or a nightly SCA job opens a ticket. |
| T+2 | Triaged | Is the package reachable from production code? |
| T+4 | Patch available | An upstream release, or a pinned override. |
| T+6 | Deployed | The lockfile changes and the image rebuilds. |
| T+7 | Verified | Scan clean, exploit test fails, ticket closes. |
Explained
The clock
T+0 is publication. The advisory names a package, a version range and a severity, and the clock starts whether or not your team has read it.
T+1 is the alert. Dependabot, a nightly SCA job or a registry webhook opens a ticket. The alert is not triage; it is a notification that a version in your lockfile now has a name.
T+2 is triage. Someone answers whether the package is reachable from production code, which service imports it and whether the vulnerable function is on a live path. This is where most of the seven days is spent, not on the patch.
T+4 is the patch. An upstream release is the clean route; a pinned override or a temporary fork is the route when the maintainer is silent.
T+6 is the deploy. The lockfile changes, the image rebuilds, the admission check passes the new digest and the rollout completes.
T+7 is verification. The scan is clean, the exploit test fails to land against the new build, and the ticket closes with evidence.
The target
The honest caveat: the seven days are a policy target, not a guarantee. Reachability triage can take longer than the patch, and some packages never get an upstream fix.
The lesson: publish a clock, then measure every event against it.
In one line
Seven days is a policy, not luck. The clock starts at publication, not at your first alert.
Check the clock
npm audit --audit-level=highMore notes: Vulnerability management & attack surface
Open in the notes app: search, filters, copy This note on GitHub