To verify an SCA finding by hand, confirm the exact installed version, trace how it got there, compare it to the advisory's affected range, check whether your code uses the vulnerable function, and test the proposed fix. Five checks take about fifteen minutes and prevent both wasted upgrades and missed exposure.
Step 1: confirm the installed version
A report can show a version from a manifest range, not the one actually installed. Check the real one.
npm ls package-name
pip show package-name
mvn dependency:tree
The npm documentation says npm ls prints installed package versions in a tree, including dependencies when the all option is used. The pip documentation says pip show displays information about installed packages. The Maven dependency plugin's tree goal displays the project's dependency tree.
Step 2: trace the path
Use npm explain package-name to print the chain of dependencies that causes a package to be installed. In Maven, the verbose option of the tree goal includes nodes that were omitted from the tree, which helps explain conflict resolution. Knowing the chain tells you what you would change.
Step 3: read the affected range
Open the advisory. In the OSV format, affected ranges are timelines of events with an introduced version and a fixed version. The specification says a version is affected if it lies within any one of the ranges or is listed in the versions list. Check your version against it yourself and note the fixed version.
Also look at the introduced value. The special value "0" means the flaw exists from the earliest version, so old versions are affected too.
Step 4: check whether the function is used
Read the advisory details to find the function or feature involved. Search your code for it, or for the library entry points that lead to it. If you cannot find a use, record that. If the library parses untrusted input, look more carefully, since the call may be indirect.
Step 5: test the fix
Upgrade in a branch, run the test suite, and re-run the scan. Confirm the finding cleared and no new ones appeared. For npm, a dry run of the fix command shows what would change without modifying anything.
npm audit fix --dry-run
What to record
| Item | Example |
|---|---|
| Finding ID | The vulnerability ID in your report |
| Verified version | The version from the real tree |
| Path | Parent packages |
| Function used | Yes, no, or unknown, with how you checked |
| Outcome | Fixed, mitigated or accepted with review date |
Try it yourself
Click through it at your own pace, or open it full screen. Follow the same questions you would ask by hand.
Where Safeguard fits
Safeguard automates much of this with dependency scanning, reachability analysis and fix pull requests, which are off by default and start on Manual so a person reviews each one.
Quick check
Can a report show the wrong version?
Yes, if it was based on a manifest range or an old lockfile. Check the real installed tree.
Does a dry run change my files?
For npm, a dry run reports what would change without applying it. Check your tool's documentation before relying on that.
Sources
- npm Docs, npm ls
- npm Docs, npm explain
- npm Docs, npm audit
- pip documentation, pip show
- Apache Maven Dependency Plugin, dependency:tree
- OSV schema
Last reviewed: 19 October 2026.
