Before you call an SCA finding a false positive, ask six questions in order: is the component really there, is the version really affected, does the platform apply, is it shipped, is the vulnerable code reachable, and is the record itself right. Most "false positives" fail at question one or two and are real.
Why order matters
Teams often jump to reachability, the most interesting question, and skip the dull ones. The dull ones are cheaper and settle more cases. Work from the cheapest check to the costliest.
| Step | Question | Cheapest way to check |
|---|---|---|
| 1 | Is the component in the build? | List the resolved tree |
| 2 | Is that version in the affected range? | Read the advisory ranges |
| 3 | Does the platform apply? | Check platform fields if the advisory has them |
| 4 | Is it shipped, or build time only? | Check the dependency type and the artifact |
| 5 | Can the vulnerable code run? | Reachability result or a code search |
| 6 | Is the advisory correct? | Compare with a second source |
1. Is the component in the build?
Look at the resolved tree, not the manifest. A manifest holds ranges. A lockfile or build output holds what was chosen. The npm docs describe the lockfile as the exact tree that was generated, and npm explain prints the chain of dependencies that causes a package to be installed. If the package is not in the resolved tree, the scan may have read the wrong file or branch.
2. Is that version affected?
Read the affected ranges in the advisory. In the OSV schema these are events such as introduced and fixed. A version just below the fix is affected. A version at the fix is not. Backports can complicate this for distribution packages, so see the backport post.
3. Does the platform apply?
Some advisories name the operating system or architecture. The Go database format has goos and goarch fields for this, filled in only when known. If your targets are outside the list, the finding does not apply to that build.
4. Is it shipped?
Build tools and test frameworks are installed on a developer machine, but may never reach production. The npm docs say the omit setting leaves chosen dependency types off disk, while they are still resolved into the lockfile. So a finding in a dev dependency is real in the tree and may be harmless in the shipped artifact. Check the artifact, not just the manifest.
5. Can the vulnerable code run?
Reachability analysis asks whether your code can call the affected function. It cuts noise, but it has limits. The govulncheck docs say calls made through reflection are not visible to static analysis, and that conservative handling of function pointers and interfaces can produce false positives. Treat "not reachable" as a lower priority with a re-check date, not as proof.
6. Is the record right?
If steps one to five say the finding is real but looks wrong, compare with a second source. If the data is wrong, fix it at the source.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list shrinks when reachability is applied, then think about which of your own findings would need questions one to four first.
Quick check
Is an unreachable finding a false positive?
Not exactly. The component and flaw are real. The code path may not be used today, which lowers priority, but a later change can make it live.
Which question settles the most cases?
Usually the first two, whether the component is really in the build and whether the version is really affected.
What should I record when I decide?
The reason, the evidence, who decided, and a re-check date or trigger.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
- package-lock.json, npm Docs
- npm explain
- npm ls
- OSV schema
- Go vulnerability database format
- govulncheck documentation
Last reviewed: 19 October 2026.
