After a dependency scanning PoC passes, do not switch everything on at once. Expand in waves, start in report only mode, tune noise, add a pull request check only after developers trust the output, and rerun your original pass marks at day 30 to confirm the result holds.
Week 1: lock in what you learned
Convert the PoC memo into a rollout plan. List the repos in wave one, the owners, and the policy you will start with. Revoke any broad trial access and replace it with the narrowest permissions for production use.
Move your findings from the PoC log into your normal tracker so nothing is lost. Keep the canary branch and the accuracy sample, because you will reuse them.
Weeks 1 to 2: wave one in report only mode
Pick the next five to ten repositories, a mix of the PoC's types and a few new ones. Turn scanning on without blocking anything. Developers see findings in their pull requests or dashboards, but builds do not fail.
Report only mode gives you real world noise data without breaking anyone's day. For how long to stay there, see how long a new scanner should run in report only mode.
Weeks 2 to 3: tune
| Symptom | Likely cause | Action |
|---|---|---|
| Many findings in dev only packages | Dev and runtime not separated | Filter by scope |
| Same issue across many repos | Shared library | Fix once in the library |
| Findings with no fix | Upstream has no patch | Track, add a dated exception |
| Findings nobody reads | Wrong channel | Route to the repo owners |
Keep every exception dated and owned. An exception without an expiry becomes permanent by default.
Weeks 3 to 4: add a gate carefully
Pick one narrow rule for a blocking check, for example known exploited vulnerabilities in reachable code on new dependencies only. Apply it to a few willing repos first. Do not gate on existing findings, because developers cannot fix a backlog by pushing a pull request. Gate on what the change introduces.
Day 30: recheck the pass marks
Rerun the original criteria table on the expanded set. Compare accuracy on a fresh sample of 20 findings, scan times on the larger repos, and developer feedback from people who were not in the PoC. Some marks will slip, which is normal and useful to know. Write it down.
Communication
Tell developers what is on, what is not, who to ask and how to dispute a finding. A two paragraph note in the channel they already use works better than a long wiki page. Say plainly that report only mode will not block merges.
What to measure going forward
Keep the metrics small: number of repos covered, time from a new advisory to your first alert, share of high priority findings fixed within your target, and number of open exceptions past expiry. Four numbers are enough to start.
Pitfalls
- Turning on blocking checks for everything on day one.
- Letting the PoC owner become the permanent triage owner without support.
- Forgetting to update the charter's exit terms and access reviews.
- Declaring victory without the day 30 recheck.
Try it yourself
Click through the demo to see how a pull request check reports a new risky dependency, then decide which rule you would start with.
Click through it at your own pace, or open it full screen.
Quick check
How many repos should wave one include?
Five to ten is enough to learn from without overwhelming the owner. Expand in waves as the noise stays manageable.
Should we gate pull requests right away?
Not before developers trust the findings. Report first, gate narrowly later.
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.
