A workable plan has three phases of about thirty days each: map and pilot, baseline and tune, then gate and extend. Each phase ends on deliverables you can show, not on activity. The aim is a gate on new risk by day 90, with old risk tracked openly instead of hidden.
Why phases
Onboarding fails when everything switches on at once. Teams meet a flood of findings, a slow check and no way to object. Phasing spreads change, gives you time to tune and lets you stop if something is wrong.
NIST SP 800-218 describes a core set of secure development practices that organizations can integrate into whichever development model they use. A phased plan is one way to make those practices concrete, one step at a time.
Days 1 to 30: map and pilot
- File census of build systems and lockfile status.
- Vendor and access review of the tool, with a read only integration.
- Choose a pilot of two or three directories with willing owners.
- Run in report only mode and collect developer feedback.
- Draft ownership for the pilot directories.
Exit check: the pilot teams can say what the tool found and who owns each result.
Days 31 to 60: baseline and tune
- Widen to most directories, still non blocking.
- Capture the baseline: every existing finding recorded with a date.
- Review a sample for false positives and tune rules.
- Build the exception process with an expiry on every exception.
- Start a weekly note: new findings, closed findings, coverage.
Exit check: new findings can be told apart from old ones, and the exception route works end to end.
Days 61 to 90: gate and extend
- Turn on blocking for a narrow class, such as new critical findings with a fix available.
- Add a scheduled full scan for new advisories on old code.
- Fill remaining coverage gaps or record them as known gaps with owners.
- Hold a review: what worked, what to widen, what to drop.
Exit check: a pull request introducing a serious new problem is blocked, and the team knows how to ask for an exception.
Roles
| Role | Job |
|---|---|
| Program owner | Runs the plan and the weekly note |
| Platform engineer | CI integration and performance |
| Directory owners | Triage and fix their findings |
| Security reviewer | Exceptions and false positive review |
Measures that mean something
Track coverage (directories scanned of directories found), time to route a finding to an owner, share of findings with an owner and time to close the first twenty. Avoid a single risk score; it hides more than it shows.
What to expect to slip
Ownership and exceptions take longer than the technical work. Plan buffer for them, and escalate early when a directory has no owner.
Where Safeguard fits
Safeguard covers dependency scanning, SBOM generation, reachability analysis, policies and gates, and compliance evidence automation, which maps to the three phases. Start with the free scan at https://gold.safeguard.sh/scan.
Quick check
Can we finish in less than 90 days?
For a small repository, yes. Keep the three phases and shorten each one.
What if a team refuses to join the pilot?
Pick a willing team instead. Early wins and good feedback matter more than representative coverage in month one.
Sources
Last reviewed: 19 October 2026.
