An outdated dependency has a newer version available. A vulnerable dependency matches a published security advisory for the version you use. Many vulnerable packages are also outdated, but plenty of outdated ones are not vulnerable, and a package can be on its latest release and still be flagged. Track both, with separate commands.
Definitions
Outdated. A newer version exists in the registry than the one you resolved.
Vulnerable. Your resolved version falls in an advisory's affected range.
Deprecated. The maintainer has marked the package as no longer recommended.
Commands that answer each question
| Question | npm | pip | .NET |
|---|---|---|---|
| Which packages are outdated? | npm outdated | pip list with the outdated option | dotnet package list with the outdated option |
| Which are vulnerable? | npm audit | pip-audit | dotnet package list with the vulnerable option |
| Which are deprecated? | See registry notes | Not shown by pip list | dotnet package list with the deprecated option |
The .NET docs say the vulnerable option cannot be combined with the deprecated or outdated options, so run them one at a time. The command also needs the transitive option to include indirect packages.
npm outdated reports Current, Wanted and Latest. Wanted is the newest version that fits your declared range. Latest is the version tagged latest in the registry, which is not always the highest. The docs mark in red any package where a newer version fits your range, and in yellow where the newer version is outside it, usually a new major.
How the two lists relate
| Package state | Outdated | Vulnerable | Action |
|---|---|---|---|
| Behind, advisory matches | Yes | Yes | Upgrade to the fixed version |
| Behind, no advisory | Yes | No | Routine update |
| Latest, advisory matches | No | Yes | Check for a patch or a workaround |
| Latest, no advisory | No | No | Nothing now |
Steps
- Run the vulnerable check first and fix those items by priority.
- Run the outdated check and sort by how far behind each package is.
- Update the vulnerable and far behind ones together when it is safe.
- Keep routine updates small and frequent so later security upgrades are small jumps.
- Review deprecated packages on a schedule and plan replacements.
Why the gap matters
A long gap makes a security fix a large jump. The fix may land in a new major version, and you have to absorb years of changes at once. OWASP lists not fixing or upgrading dependencies in a risk based, timely fashion among the signs you are likely vulnerable.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare which findings have a fix available now and what version jump each one needs.
Quick check
Is every outdated package a risk?
No. Many are just behind. The risk is when the version you use matches an advisory, or when the package is no longer maintained.
Can a package on its latest version be vulnerable?
Yes. A new advisory can match the latest release before a fix ships.
Safeguard dependency scanning reports vulnerable packages and can open fix pull requests when you enable autonomous remediation, which is off by default. Try a free scan.
Sources
- npm docs, npm outdated
- pip documentation, pip list
- Microsoft Learn, dotnet package list
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
Last reviewed: 19 October 2026.
