Use both, for different jobs. Native audit commands are free, close to the developer, and understand their own ecosystem. A shared scanner or report gives one comparable view across all languages. The danger is treating the output of different tools as if it meant the same thing, because each answers a slightly different question.
How native tools differ
The audit tools shipped with ecosystems are not interchangeable. The official docs show three different behaviors:
| Tool | What it does | What it does not do |
|---|---|---|
| npm audit | Sends a description of your dependency tree to the registry and gets advisories back | Does not tell you whether your code calls the vulnerable function |
| govulncheck | Checks whether your code directly or indirectly calls vulnerable functions | Separates called from imported only |
| NuGet audit | Reports known vulnerabilities at restore, with direct versus all packages as a setting | Depends on audit source and settings |
The npm docs say that audit needs a package lock by default and that results may vary between runs when you bypass it. The govulncheck tutorial shows two groups of findings: vulnerabilities with call stacks in your code, and vulnerabilities in imported packages with no call stack, listed as informational. NuGet's pruning feature, per its docs, exists partly to reduce false positives from component scanners.
Why counts do not compare
Suppose npm audit reports 40 findings and govulncheck reports 2. That is not evidence that the Go service is twenty times safer. One counts every advisory matched to a version. The other filters by whether code calls the function. Comparing the two numbers is comparing different units.
A fair way to combine them
- Run native tools where developers work. They give fast feedback in pull requests.
- Collect an SBOM from every build. One format, one place.
- Match components against advisories in one system. Now every finding uses the same rules.
- Add exploitability context consistently. If some languages get call analysis and others do not, label which is which.
- Rank by exposure and impact, not by raw count per language.
What native tools do better
They know quirks nobody else tracks, like how a package manager resolves ranges or what a lock file records. They also fit existing workflows, so developers use them without new training. Do not replace them. Layer on top.
What a shared view does better
It answers cross-cutting questions: which services use a given library, which owner has the oldest open finding, how many repos lack a lock. Native tools answer those one repo at a time.
Try it yourself
Open the demo and compare the full list of findings with the list after reachability is applied. Look at how many items drop out and why.
Click through it at your own pace, or open it full screen.
Safeguard can help here: it scans dependencies and generates SBOMs, applies reachability analysis so you can sort findings by what your code can actually call, and enforces policies and gates on pull requests. You can try a free scan on a repository to see what it finds.
Quick check
Is a lower count from one language's tool proof it is safer?
No. Tools count different things. A tool that filters by call reachability will report fewer items than one that matches versions only.
Do I still need native audit commands if I have a scanner?
They are useful for fast developer feedback. Keep them, and use the shared view for portfolio questions.
Sources
Last reviewed: 19 October 2026.
