If a security tool trial finds almost nothing, do not celebrate yet. A quiet result means either your code is in good shape or the tool is not seeing it. Run five checks: coverage, a known issue test, a second source, scan configuration and a look at what was skipped.
Two explanations, one result
A clean report looks the same whether the cause is good hygiene or a blind spot. The cost of guessing wrong is asymmetric. If you buy a tool that was blind, you pay for false comfort.
Check 1: coverage
Confirm what the tool actually scanned.
- Did it find all your repositories, or only the ones you pointed at?
- Did it parse every manifest and lockfile? Look for a count of packages or files analysed.
- Were any languages, build tools or directories skipped?
If the tool cannot tell you what it covered, treat that as a finding.
Check 2: plant a known issue
Take a branch and add a dependency with a publicly known vulnerability, or reintroduce an old pattern that a scanner should flag. If the tool says nothing, you have learned something important. Do this on a throwaway branch, never in production code. A short list of two or three planted items is enough.
Check 3: compare with a second source
Run another free or already owned check on the same repository and compare results. You are not looking for identical output. You are looking for obvious misses. If a second source reports ten known issues and the trial tool reports none, ask why.
Check 4: configuration
Many tools ship with conservative defaults. Check that:
- Severity filters are not hiding medium and low findings.
- Ignore rules from a previous tool were not imported blindly.
- Test, example and vendored folders were handled on purpose. See the note on exclusions in your tool's documentation.
- The vulnerability data source is current. Ask when it last updated.
Check 5: ask what was skipped
Ask the vendor for a list of items scanned but not analysed, and why. Reasons might include unsupported file types, private registries, or timeouts. Skipped items are where risk hides.
Decision table
| Result of checks | What it likely means | Next step |
|---|---|---|
| Planted issues found, coverage full, second source agrees | Your code may really be clean | Move on to usability tests |
| Planted issues missed | Tool has a blind spot | Treat as a serious accuracy gap |
| Coverage partial | Setup problem | Fix and re-run before judging |
| Second source finds more | Possible data gap | Ask the vendor to explain each difference |
Do not skip the other criteria
Even in a truly quiet trial, you can still judge speed, developer experience, integration quality and support. Those criteria matter regardless of how many findings you saw. Also check how the tool behaves when something does appear: add a known vulnerable package and see how fast it is flagged, whether the message is clear and whether a fix is suggested. For more on timing, see measuring time to first useful finding.
Safeguard's reachability analysis is designed to separate vulnerable code that is actually called from code that is only present, which is one reason a good scan often reports fewer, more relevant items than a raw list. You can see how that looks in a free scan.
Quick check
Is a clean trial a good sign?
It can be, but only after you confirm coverage and prove the tool catches a planted known issue.
Should I plant a vulnerability in production code?
No. Use a throwaway branch or a test repository, and delete it when the trial ends.
Last reviewed: 19 October 2026.
