A dependency advisory is a vulnerability when it describes a flaw that someone could exploit, and an incident when it describes malicious code, a compromised release or active abuse. Vulnerabilities go through patch SLAs. Incidents go through a response playbook with a lead, a log and a deadline.
Why the line matters
Treating a malicious release as a routine patch wastes the first hours. Treating every CVE as an incident burns out the team. The distinction decides who is woken, which clock starts and how much evidence you collect.
Quick decision table
| Signal in the advisory | Treat as |
|---|---|
| Flaw in code, fix available, no known abuse | Vulnerability, normal SLA |
| Flaw with confirmed exploitation in the wild | Vulnerability, expedited |
| Release published by an attacker or with malicious code | Incident |
| Maintainer account or build system compromised | Incident |
| Install script or import time behavior added unexpectedly | Incident |
| Registry removed the package as malware | Incident |
Questions to ask
- Was the code changed by someone other than the maintainers?
- Can it run without my code calling it, for example at install time? npm runs lifecycle scripts of dependencies by default unless disabled.
- Does it touch secrets or send data out?
- Did the registry remove it? npm Security removes confirmed malware and publishes a placeholder and advisory.
If any answer is yes, run the incident playbook. If the advisory is about a flaw, use your vulnerability process and prioritise with exploitability and reachability.
Hybrid cases
Some events begin as a vulnerability and turn into an incident when exploitation is found against your systems. Define the trigger up front: for example, evidence of exploitation in your environment, or a deployed artifact that was built from a compromised release. See declaring an incident early.
Make the call visible
Put the table in your triage guide and name who may declare an incident, including after hours. When someone classifies an advisory, record the signal they used. Over time this record shows whether your threshold is too high, with incidents recognised late, or too low, with too many false alarms. Adjust the criteria at the quarterly review and share the changes with engineering so they know when to escalate.
Try it yourself
Click through it at your own pace, or open it full screen.
Open an advisory in the demo and apply the table above to decide which process it belongs in.
Quick check
Is a critical CVE an incident?
Not by itself. It is a high priority vulnerability unless exploitation or compromise is shown.
Who declares an incident?
The on call security lead or whoever your plan names, using criteria written in advance.
Safeguard offers zero day discovery and reachability analysis to help prioritise vulnerabilities. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
