To find vulnerable dependencies, list every package in your project at its exact version, including transitive ones, then check that list against an advisory database. Use your package manager's built in audit command or a dedicated scanner. Run it in CI so new advisories surface on their own.
Definitions
Manifest. The file where you declare what you want, such as package.json or pom.xml.
Lockfile. The file that records the exact versions that were resolved, such as package-lock.json or Cargo.lock.
Advisory database. A collection of published vulnerability records, mapped to package names and affected version ranges.
Steps
- Commit your lockfile. A scan of exact versions is more accurate than a scan of loose ranges. The npm documentation notes that without a lockfile, results can differ between runs because the tree is rebuilt each time.
- Run the audit built into your package manager. Several ecosystems ship one. See the table below.
- Include transitive packages. Some tools need a flag for that. The .NET command for listing vulnerable packages, for example, does not include transitive packages unless you ask.
- Read direct findings first. A direct dependency you control is quicker to fix than a deep one.
- Find the path for transitive findings. Trace which top level package pulls the vulnerable one in, then upgrade the closest parent.
- Re-run after each change and confirm the finding is gone.
Ecosystem starting points
| Ecosystem | Built in or common starting point | Notes |
|---|---|---|
| npm | npm audit | Needs a package-lock.json by default |
| Python | pip-audit | Reads requirements files and environments |
| .NET | dotnet list package with the vulnerable option | Add the transitive option |
| Go | govulncheck | Reports whether vulnerable code is called |
| Java | OWASP Dependency-Check | Maven, Gradle and CLI integrations |
| Any | OSV-Scanner | Matches lockfiles against the OSV database |
Common mistakes
- Scanning once at release and never again. Advisories keep arriving.
- Treating every finding as equal. Severity, fix availability and whether the code is called all matter.
- Scanning just the direct dependencies, which misses most of the tree.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a finding and look for the affected version, the fixed version and the dependency path.
Quick check
Do I need a paid tool to start?
No. Most package managers or open source scanners can give you a first list. A dedicated tool helps when you need history, policy and several repositories.
Why does my scan show findings in packages I never installed?
They are transitive. Another package you installed depends on them.
Safeguard scans manifests and lockfiles for dependency risk and can run reachability analysis on the results. A free scan is available.
Sources
- npm docs, npm audit
- pip-audit on GitHub
- Go tutorial, Find and fix vulnerable dependencies with govulncheck
- Microsoft Learn, Auditing package dependencies
- OWASP Dependency-Check project page
- OSV-Scanner documentation
Last reviewed: 19 October 2026.
