Before day one, confirm that you can reach the repos, that tokens and network rules are approved, that your build tools run on the machine or runner the scanner will use, that lockfiles are committed, and that you have a clean sample repo with known contents. Most PoC delays are access issues, not scanner issues.
Why a day zero pass pays off
A ten day plan has no slack for waiting on a firewall change. Teams commonly lose the first three or four days to approvals and environment problems, then judge the scanner on a rushed week. Do these checks a few days early and the clock starts when you press go.
The checklist
| Area | Check |
|---|---|
| Repos | Names agreed, owners told, read access confirmed |
| Tokens | Service account created, scoped, expiry set |
| Network | Outbound access to the scanner's service allowed, if hosted |
| Proxy | Proxy and certificate settings known, tested with a simple call |
| Runners | A runner or machine with your build tools installed |
| Build tools | Package manager and language versions match production |
| Lockfiles | Committed for each repo, or noted as missing |
| Private registries | Credentials available to the runner, scoped read only |
| Sample repo | One small repo with known contents for first run |
| Logging | A spreadsheet or file ready for the daily log |
Build tools matter more than they look
Many scanners resolve dependencies by running your package manager or reading its output. If the runner has a different Node, Java or Python version from production, the resolved tree can differ, and so can the findings. npm documents that npm ci installs from the lockfile and errors when the lockfile and package.json disagree. Run that command yourself first. If your own install fails, the scan will not be trustworthy either.
Private registries and proxies
If any repo pulls from a private registry, test access before the trial. A scanner that cannot authenticate will quietly skip packages or fail on resolution. Plan how the runner gets credentials, and make them read only. For corporate proxies, check that the scanner honors your proxy settings and trusts your internal certificate authority, which is a common stumbling block.
Do a dry run on a small repo
Pick the smallest repo with a lockfile. Run the scanner end to end: connect, scan, view results, export. You are not judging it yet. You are checking the plumbing. If the first scan takes more than an hour of fixing, you have just learned something about setup effort and should log it.
Prepare the log
Create the daily log now: date, what you ran, what you saw, surprises, hours spent. It takes two minutes a day and makes the readout far easier. Include a column for setup time, since that is part of the true cost.
Brief the people
Send a short note to repo owners and reviewers: what is happening, when, what they need to do, how long it takes. Book the developer review session now, as one 90 minute block, to avoid late scheduling.
Confirm the exit
Write the revoke date next to each token. See keeping a PoC read only.
Try it yourself
Open the demo as a preview of the first output you will see, then decide which small repo makes the best day zero dry run.
Click through it at your own pace, or open it full screen.
Quick check
How early should day zero checks start?
A week before kickoff is comfortable, because access requests can take days.
What if the build does not work on the runner?
Fix that first or pick another repo. A scan of a broken build gives unreliable results.
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.
