A dependency scanning PoC usually runs ten working days on three to five repos, with one owner, two or three developer reviewers and a decision maker. Success means the scanner met pre agreed pass marks on your code. Failure is also a useful result, because it saves a bad purchase.
How long should it run?
About two weeks. Shorter than a week rarely covers coverage, accuracy and workflow together. Longer than three weeks adds little new information and tends to drift. See the two week plan.
Who needs to be involved?
| Role | Why |
|---|---|
| Owner | Runs the test and keeps the log |
| Developers | Judge whether results are usable |
| Security reviewer | Judges accuracy and priorities |
| Decision maker | Agrees pass marks and signs the outcome |
| Platform admin | Handles access and CI setup |
What does success look like?
The scanner met the pass marks you wrote before the trial: it found the packages in your repos, its findings were accurate on a hand checked sample, developers could act on them, and scans fit your build time. Do not define success as "found a lot of vulnerabilities". Quantity is not quality. Write the marks down using this criteria table.
What if it fails?
Then you have learned something cheaply. Record which pass marks failed and why. If the failures are fixable, such as a configuration issue, you may extend briefly with a named gap and a date. If they are structural, such as an unsupported language, stop.
Is it free?
Often a vendor offers a trial period, but terms vary, and you should confirm what the trial includes and what happens to your data at the end. This post does not cover commercial terms. Keep them separate from the technical test so that results are judged on evidence. Also count your own team's time, which is a real cost. See effort per person.
Will the scanner change our code?
It should not, in a PoC. Run it read only, on chosen repositories, with automatic fix pull requests off unless you test them deliberately on one repo. See keeping a PoC off production.
What happens to the vulnerabilities it finds?
They are real, and they belong to the repo owners. Agree up front who triages and where actionable findings are tracked. See who owns what a PoC finds.
What does the final decision need?
A one page memo: each pass mark, the measured result, what was not tested, and one of three outcomes. Adopt, extend for a named gap, or stop.
What can it not tell us?
Long run noise, scale across every team, support after purchase and behavior at upgrades. A staged rollout answers those. See what a PoC cannot tell you.
Quick check
Can we skip the PoC if the vendor is well known?
You can, but you lose evidence on your own code. A short PoC is cheap insurance against fit problems.
Should the vendor run the PoC for us?
They can help with setup. The judging should be yours, using your pass marks.
How many tools can we compare at once?
Two or three is workable. More than that stretches reviewers and blurs results.
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
