Spend day one on inventory, day two on scope, day three on a baseline scan, day four on ownership, and day five on one narrow gate. Each day has an output you can check. Do not try to fix the backlog in week one. The aim is a trusted, repeatable scan.
Day 1: inventory
List every manifest and lockfile, and every workspace definition. See how to find every lockfile in a monorepo.
Output: a list of package directories, each marked as having a lockfile or not.
Day 2: scope
Decide what ships and what does not. Mark fixtures, samples and dead code. See what to exclude from a dependency scan.
Output: an in scope list and an excluded list, each with a reason.
Day 3: baseline
Run a full scan of everything in scope. Check that the number of projects in the report matches your list. If a package is missing, find out why before looking at any finding.
If the run times out on a large tree, scan package directories separately, as described in scanning a large monorepo with the Safeguard CLI.
Output: a baseline report, with a count of findings by root cause. See counting one vulnerability across many packages.
Day 4: ownership
Map each package to an owner and name a fallback. Check CODEOWNERS for gaps. See routing findings to the right team.
Output: every in scope package has an owner, and the unowned count is known.
Day 5: one narrow gate
Add a pull request check that fails only on new findings of the highest severity in shipped packages. Make it narrow on purpose. A wide gate in week one gets turned off in week two.
If you use path filters, remember the pending check trap. See path filters for per package scans.
Output: a gate that has run on at least one real pull request.
A summary table
| Day | Task | Output |
|---|---|---|
| 1 | Inventory | Package list with lockfile status |
| 2 | Scope | In scope and excluded lists |
| 3 | Baseline | Report matching the package list |
| 4 | Ownership | Owner for every package |
| 5 | Gate | One narrow check live |
After week one
Schedule a full scan nightly. Burn down the baseline by root cause, starting with findings that are reachable and have a fix available. Review exclusions quarterly.
Where Safeguard fits
Safeguard provides dependency and SBOM scanning, reachability analysis, and policies and gates for pull requests. Autonomous remediation can open fix pull requests, but it is off by default. You can try one project with the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through the demo to see what a first inventory looks like, which is the day one output.
Click through it at your own pace, or open it full screen.
Quick check
Why not gate broadly on day one?
A wide gate blocks too many pull requests and gets switched off. Start narrow and widen later.
What should I check first in a baseline report?
That the project count matches your inventory, before reading any finding.
Last reviewed: 19 October 2026.
