There is no honest single number, because rollout time depends on how many repositories you connect, how clean their manifests are, and how many teams must agree on policy. Plan in phases with exit criteria for each, and judge progress by coverage and fixed findings, not by calendar weeks.
What drives the schedule
Three things dominate. The first is coverage, meaning how many repositories, images, and build pipelines are in scope. The second is data quality: repositories without lockfiles or with vendored code produce thin inventories. The third is people. A platform that blocks builds touches every team, and each team needs a say in what counts as a blocker.
Technical setup is usually the short part. Agreement on policy is usually the long part.
A phased plan
| Phase | Goal | Exit criteria |
|---|---|---|
| 1. Observe | Connect a pilot set, read only | Inventory matches what teams expect |
| 2. Triage | Tune noise, assign owners | Every critical finding has a named owner |
| 3. Advise | Post results on pull requests, do not block | Developers read and act on comments |
| 4. Enforce | Block on a small, agreed rule set | Blocks are rare and understood |
| 5. Expand | Add remaining repos and registries | Coverage target met |
Do not skip phase 3. A gate that appears with no warning teaches developers to route around it.
Phase notes
Observe. Pick five to ten repositories across your main languages. Compare the generated inventory with what the owning team believes it ships. Gaps here are the most valuable early output.
Triage. Most first scans look alarming. Reachability analysis, which checks whether vulnerable code is actually called, often cuts the list sharply, so use it before you assign work. Assign each remaining critical finding to a person, not a team alias.
Advise. Start with comments only. Track how many comments lead to a change within a week.
Enforce. Begin with one rule that nobody argues about, such as blocking a package that appears in the CISA Known Exploited Vulnerabilities catalog. CISA describes that catalog as an authoritative source of vulnerabilities exploited in the wild and recommends using it as an input to prioritization.
Expand. Add the long tail by script, not by hand. Reuse the policy set from earlier phases.
Signs the rollout is stalling
- Findings are growing faster than they are closed for two months in a row.
- Teams ask for blanket exceptions instead of fixes.
- The owner list is out of date.
- Nobody can say which repositories are not connected.
If you see two or more, pause expansion and fix triage first.
A worked example
Consider a hypothetical company with eighty repositories across five teams. The security lead proposes a five phase rollout and sets exit criteria instead of dates. Here is how it might unfold in practice.
In the observe phase, eight repositories are connected. The inventory misses a Python service because its dependencies are in a requirements file that is not pinned. That is a useful finding about the repository, not the platform, and the team fixes it. The exit criterion is met when each owner agrees the inventory looks right.
In the triage phase, the first scan reports hundreds of findings. After reachability analysis, a much smaller group remains. Each critical one gets a named owner. Two teams push back, saying their ticket queue is full. The security lead agrees to cap new tickets per team per week, which keeps the work visible without overwhelming anyone.
In the advise phase, comments appear on pull requests. The team tracks how often a comment leads to a change within a week and finds one rule that nobody acts on. They tune it.
In the enforce phase, they turn on a single blocking rule. In the expand phase, a script connects the remaining repositories using the same settings.
How to set exit criteria that mean something
An exit criterion should be observable and not depend on opinion. Compare.
| Weak criterion | Better criterion |
|---|---|
| Teams are comfortable | Every pilot owner signed off on the inventory |
| Findings are under control | Every critical finding has an owner and a due date |
| Developers like the comments | More than half of comments lead to a change within a week |
| Gate works | Blocks over two weeks were reviewed and agreed |
Write them down before the phase starts, and hold a short review at the end of each.
Staffing the rollout
Plan for three roles. A sponsor who can resolve disputes, a platform owner who runs the integration, and a champion in each team who reviews findings. If a team has no champion, its repositories wait. Estimate the platform owner's time realistically. Early phases take much of one person's week, and the load drops once automation takes over the routine work.
Communication plan
Send a short note before each phase: what changes, who is affected, how to ask for help. Keep a public page listing the rules and the exception process. After each phase, share what you learned, including mistakes. People adopt tools they trust, and trust comes from honesty about noise and error.
When to slow down
If a phase misses its exit criteria twice, do not add scope. Find the cause. It is nearly always one of three things: poor data in a few repositories, unclear ownership, or a rule that is too broad. Fix that before moving on.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a finding moves from detected to owned to closed.
Safeguard supports this progression with asset discovery, SBOM and dependency scanning, reachability analysis, and policies and gates you can set to advise before they enforce. A free scan at gold.safeguard.sh/scan is a reasonable phase 1 start.
Quick check
Can we enforce on day one?
You can, but it usually backfires. Observe and advise first so the rules reflect what your teams can actually fix.
What is a good first blocking rule?
A narrow, high-confidence one, such as a dependency listed as known exploited with a fix available.
Who should approve moving to the next phase?
The platform owner and the security lead together, using the written exit criteria, with the team champions consulted.
Sources
Last reviewed: 19 October 2026.
