Match five settings before you compare: which dependency groups are scanned, whether transitive dependencies are resolved, which paths are excluded, the severity or confidence filter, and the output format. Defaults differ between tools, and a default difference looks exactly like a quality difference.
Why defaults decide more than you expect
Run two scanners with factory settings and you often get different results for boring reasons. One tool skips test directories. Another resolves the whole dependency tree and a third reads only what is written in the manifest. None of that says anything about detection quality, but it will change every count in your spreadsheet.
The fix is to decide each setting yourself and apply it to all candidates. Where a tool cannot match a setting, write that down as a limitation rather than hiding it.
The five settings
| Setting | Question | Why it matters |
|---|---|---|
| Dependency groups | Are dev and test dependencies included? | Can double the package count |
| Transitive resolution | Does it follow dependencies of dependencies? | Largest source of count gaps |
| Paths | Which folders are ignored? | Vendored and fixture code swings results |
| Filters | Minimum severity or confidence shown | Hides or reveals low findings |
| Output | Same format, same fields | Makes joining possible |
Transitive resolution
Many real vulnerabilities sit several levels down. Some tools resolve the full tree, and some give you a switch. OSV-Scanner, for example, documents a flag that disables transitive dependency resolution, which tells you the behavior is configurable and worth checking in every tool you test. See the OSV-Scanner usage page. Whichever way you set it, set it the same way for everyone, then run a second pass with the opposite setting to see how much each tool depends on it.
Dependency groups
Decide whether your question is "what ships to production" or "everything in the repository." Both are valid. For a first comparison, include everything, then filter to production in the analysis so you can see both views.
Paths and vendored code
Folders such as test fixtures, examples and vendored libraries produce findings that your team may never act on. Exclude the same folders for every tool, or exclude none. If one tool has no exclude option, filter its results afterward by path.
Filters
Some tools hide low severity or low confidence findings by default. Turn all of that off for the comparison so you can see the raw view, then apply one common threshold afterward in your analysis, not inside each tool.
Output
Choose a machine readable format, usually JSON or an SBOM, for every tool. The match findings with purl and aliases post explains the join. OSV-Scanner also documents a flag that lists all packages, not only vulnerable ones, which is useful because it lets you compare inventories before comparing vulnerabilities.
Write the config down
Save each tool's command line or config file next to the results. Treat it as part of the evidence. If someone reruns the test in January, they should get the same behavior. Commit the config to the test folder, not to your production repositories.
What not to tune
Resist tuning one tool more than the others. A tool whose vendor helped you with settings has had more attention than one you configured yourself. If you do accept vendor help, offer the same time to every candidate, and say so in the write up. For the broader design, see run your own independent scanner bake off.
Safeguard's dependency scanning is configurable through policies, and the free scan at gold.safeguard.sh/scan is a way to see default behavior before you set anything.
Try it yourself
Click through it at your own pace, or open it full screen. See how dev and transitive packages appear in the inventory.
Quick check
Should I compare at default settings instead?
Defaults are worth one extra pass, because they are what most developers will live with. Do the matched pass first so differences are explainable.
What if a tool cannot match a setting?
Record it as a limitation, and filter its output afterward where you can. Do not drop the tool silently.
Sources
- OSV-Scanner usage: two step process, flag to disable transitive resolution, flag to list all packages.
Last reviewed: 19 October 2026.
