What they're testing
Whether you think about the software supply chain, and separate "in package.json" from "actually executed".
The short answer~30 seconds
The first step is establishing exposure, not patching: which services use it, at which version, and whether the vulnerable code path is even reachable. Many critical CVEs apply only to a feature you don't enable. Then decide: patch now, or mitigate by configuration and patch on schedule. What determines your speed is whether you already had an SBOM and automated dependency scanning.
The long answer
Log4Shell is the instructive example because it showed where the difficulty actually lies: many teams spent days just answering "do we use log4j", because it arrived transitively three levels down. An SBOM generated automatically at build turns that from days into minutes. It's an investment that only pays during a crisis, which is why it's always deferred until the first one.
Beyond CVEs there's a growing separate risk: package takeover. A maintainer's account is compromised, a malicious version is published, and every build running npm install against a loose range pulls it. The pragmatic defences are pinning via the lockfile and using npm ci rather than npm install in CI, plus a deliberate delay before adopting the newest release — most malicious packages are caught within hours to days.
The senior-level point is policy rather than tooling: who may add a dependency, on what criteria (maintainer count, release cadence, how many transitive dependencies it drags in), and how often you review. Every added package is attack surface and maintenance debt; teams that treat npm install as a decision rather than a reflex have far less to do at 2am.
What they'll ask next
?Are automated dependency updates safe?
For security patches, automate and merge quickly. For minor and major upgrades, batch them on a schedule with a human review, because the dominant risk there is breakage rather than security. Separating the two streams is the pragmatic balance.
These lose points
- Patching before establishing exposure. A rushed 2am deploy for a CVE that doesn't apply creates a second incident.
- Not knowing your transitive dependencies. Most CVEs arrive that way rather than through what you installed directly.