A vulnerable dependency contains an accidental flaw that an attacker may exploit. A malicious dependency was written or altered to harm you from the start. Vulnerabilities are found by matching versions to advisories. Malicious code needs behavior and source checks, and the response is removal and credential rotation, not patching.
Definitions
A vulnerable dependency has a known weakness, usually tracked by a CVE. A malicious dependency carries code that does something hostile, such as stealing secrets, whether it was published that way or tampered with later. The xz library case is a malicious one: CISA states malicious code was embedded in versions 5.6.0 and 5.6.1 and tracked it as CVE-2024-3094, so a record can exist after the fact.
Side by side
| Vulnerable | Malicious | |
|---|---|---|
| Intent | Accidental | Deliberate |
| Typical detection | Version matches an advisory | Behavior, source mismatch, reports |
| Exists as a CVE at first | Often after disclosure | Usually not at first |
| Fix | Upgrade to a patched version | Remove, pin to a clean version, investigate |
| Credential rotation | Rarely | Often |
| Reachability analysis helps | Yes | Limited, since the code may run on install or import |
Why one tool rarely does both well
Reachability asks whether your code calls the flawed function. That narrows noise for vulnerabilities. Malicious code often runs when a package is installed or imported, so call paths matter less. The other direction is also true: a malware feed will not tell you that a flawed but legitimate library is exposed through your API.
What to ask a vendor
- How do you detect malicious packages, and from which signals?
- How fast after publication, and can you show a timeline?
- Do you separate malicious findings from vulnerability findings in policy?
- Can a policy block a package on malicious status, not only on severity?
- What do I get for response: affected projects, versions and deployed builds?
Triage rule of thumb
For a vulnerability, rank by exploitability and exposure. For a malicious package, assume execution happened where it was installed, remove it, rotate secrets reachable from that environment, and check build and developer machines too.
Quick check
Does a clean CVE scan mean no malicious packages?
No. Malicious packages often have no CVE when they appear.
Is a malicious package a vulnerability?
It may later receive an identifier, as the xz case did, but the response differs from patching a flaw.
Try it yourself
Open the demo on exploitability and notice how it separates flaws that can be reached from those that cannot. Then think about why that logic does not apply to code that runs on install.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers reachability analysis, SBOM and dependency scanning, policies and zero-day discovery. Run the free scan on a project to see the vulnerability side.
Sources
Last reviewed: 19 October 2026.
