Run the platform in report only mode on a sample of your repositories for about 30 days while your current scanners keep gating builds. Compare findings by package and version, measure triage effort, then decide with evidence. Change nothing in your pipelines until the trial ends.
Why shadow mode
Switching tools on a hunch is risky, and judging them on a demo is unreliable. Running side by side on your own code answers the real questions: what does each find, what does each miss and how much work is the output.
It also protects you. Your existing gates stay in place, so a trial cannot weaken your controls.
Week 0: Set the rules
- Pick 8 to 15 repositories: small and large, several languages, at least one with a monorepo layout and one with container images.
- Write down the success measures before you start, so nobody moves the goalposts.
- Give the platform read only access and note exactly which scopes you granted.
- Keep every existing scanner and gate untouched.
Weeks 1 and 2: Collect
Let both run on the same repositories. Export findings from each into a common format, with package, version, advisory ID and location. Our post on bringing results together with SARIF helps with the plumbing.
Weeks 3 and 4: Compare and sample
Do not compare raw counts. Instead sort findings into four buckets.
| Bucket | Meaning | Action |
|---|---|---|
| Both found | Agreement | Spot check a few |
| Only the platform found | New signal or noise | Verify a sample by hand |
| Only current tools found | Possible gap in the platform | Investigate every one |
| Neither found | Unknown | Test with a seeded vulnerable dependency |
Verify a sample from each bucket against an independent source such as a public advisory. Record how many were real. Our guide to testing a scanner with seeded vulnerabilities shows how to plant a known case.
Measure effort as well as detection
Track hours spent triaging, the share of findings you could close without further research, and how easily you could answer a sample customer question such as which services use a given package.
Try it yourself
Open the pull request gate demo and look at where a gate sits in the flow. In a shadow run, this stays in report only mode.
Click through it at your own pace, or open it full screen.
Decide and document
At the end, write a short summary: what you measured, what you found, what surprised you. Hold a decision meeting with the owner of the budget and the owner of the risk. If you proceed, migrate repositories in waves, with a rollback plan. Safeguard supports this approach with a free scan at https://gold.safeguard.sh/scan and policies and gates that you can set to report only first.
Quick check
Is 30 days long enough?
For most teams, yes, provided it spans at least one release cycle. Extend it if you ship rarely.
Should developers see the trial results?
Share a summary with the pilot teams, but keep pull request comments off so nobody is interrupted.
Last reviewed: 19 October 2026.
