Before enforcing a merged dependency policy, run it against both codebases in report only mode and record a baseline: how many repositories fail each rule, how old the findings are, and who owns them. Without a baseline you cannot tell whether the policy is working or just noisy.
Why a baseline matters
Once enforcement begins, every number changes: new findings, fixes, exceptions. If you did not capture the starting point, you cannot separate inherited debt from new problems, and you cannot show leadership progress. A baseline also protects the teams, since it shows what existed before they touched it.
What to capture
Take one snapshot, dated, covering both organizations.
- Inventory. Repositories, services, and the packages each one uses, including transitive ones. Note any repository that could not be scanned and why.
- Findings per rule. For each rule in the merged policy, how many repositories and packages would fail.
- Age. For vulnerability findings, how long since the vulnerable version was published or flagged.
- Reachability. How many of the findings are in code paths your software actually calls. This often reduces the urgent list a lot.
- Ownership. Which team is responsible for each failing repository. Unowned repositories are a finding in themselves.
- Exceptions. Count and age of existing exceptions from both sides.
- Coverage. Which repositories have no scan at all.
| Measure | Why it matters |
|---|---|
| Failing repositories per rule | Shows which rule will hurt most |
| Age of findings | Separates old debt from new risk |
| Reachable findings | Focuses the first fixes |
| Unowned repositories | Reveals gaps in accountability |
| Unscanned repositories | Shows blind spots |
Keep it comparable across the two sides
Use the same tool settings and the same rules when scanning both estates. If the two companies used different scanners before, do not compare their old reports. Run one scan method on everything.
Use the baseline to set the order of work
Read the table from the top. Rules that fail in few repositories can be enforced early. Rules that fail broadly need a schedule. Repositories with reachable, severe findings go first. See one page vulnerability prioritization policy contents.
Report new and inherited separately
After enforcement starts, show two lines: debt that existed at baseline and findings introduced afterward. This protects morale and gives a fair picture. Detail in new versus inherited vulnerabilities, report separately.
Try it yourself
Click through it at your own pace, or open it full screen. See how findings are counted and grouped, which is the shape of a baseline report.
Safeguard can scan dependencies, build SBOMs, and apply reachability analysis, and its free scan at https://gold.safeguard.sh/scan lets you try a single repository first.
Quick check
How often should we re-baseline?
Keep the first baseline fixed for comparison, and take a fresh dated snapshot at each policy review.
What if some repositories cannot be scanned?
Record them as a coverage gap with an owner and a date to fix, rather than leaving them out of the numbers.
Last reviewed: 19 October 2026.
