A dependency scanning proof of concept (PoC) fits in two weeks if you write the pass marks before day one, test on three to five of your own repositories, spend week one on coverage and accuracy, spend week two on workflow and fixes, and end with a written yes, no or extend decision.
What a PoC is and is not
A proof of concept is a short, controlled test that answers one question: does this scanner work on our code, with our people, well enough to adopt? It is not a free audit and it is not a demo. A vendor demo shows the tool at its best. A PoC shows it on your lockfiles, your private packages and your build system.
Dependency scanning, also called software composition analysis (SCA), reads the packages your code pulls in, direct and transitive, and matches them against known vulnerability records.
Before day one: three decisions
Decide these in a one page note, and share it with the vendor if there is one.
- Scope. Three to five repositories, chosen to cover your main languages, one monorepo or multi module project, and one repo with a private registry.
- Pass marks. A short table, covered in our success criteria post.
- People. One owner, one or two developers, one person who can approve the result.
The ten day plan
| Days | Focus | Output |
|---|---|---|
| 1 to 2 | Connect repos, run first scans | Inventory of packages per repo |
| 3 to 4 | Coverage checks: lockfiles, transitive depth, ecosystems | Coverage table |
| 5 | Accuracy review on a sample of findings | True and false positive counts |
| 6 to 7 | Prioritization: exploit data, reachability, dev vs runtime | Ranked list vs your own ranking |
| 8 | Pull request and CI integration | Scan time, comment quality |
| 9 | Fix paths: upgrade suggestions, build still passes | Fix success count |
| 10 | Readout and decision | One page memo |
Keep a running log. A dated line per day is enough: what you ran, what you saw, what surprised you.
Week one: does it see your dependencies?
A scanner can only report on what it detects. Start with inventory, because every later number depends on it. Compare the scanner's package list with what your build actually installs. For npm, the lockfile describes the exact tree, and npm's own documentation says it is meant to be committed so later installs produce identical trees. A scanner that reads only the manifest will guess at versions.
Then take a sample of 20 findings and check each by hand: is the package really present, is the version in the affected range, does the advisory apply? This gives you a false positive rate you can defend.
Week two: does it fit how you work?
Run the scanner on a pull request. Note how long it takes, whether the comment is readable, and whether a developer can act on it without asking security. Then try the fix path: apply three suggested upgrades and run your tests.
Finish by asking each participant one question: would you keep this turned on? A tool that is accurate but ignored does not reduce risk.
Ending the test
Write the memo on day ten. State each pass mark, the measured result, and one of three outcomes: adopt, extend for a named gap, or stop. Do not extend without a named gap and a date.
Try it yourself
Open the demo and look at how direct and transitive packages are listed, since that is the inventory you will compare against your own build output in week one.
Click through it at your own pace, or open it full screen.
Quick check
Can we run a PoC on public repositories only?
You can for the first scan, but the useful findings come from your private repos, registries and build setup. Use public code only if policy blocks access, and say so in the memo.
Is two weeks enough for a monorepo?
Usually yes for a decision, if you test one representative slice. Do not try to scan everything.
Sources
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.
