Onboard a repository by recording its existing findings as a dated baseline, blocking only new findings, and tightening the threshold in scheduled steps. The team sees a short list of new work instead of hundreds of old alerts, and the baseline still gets burned down on a plan.
Why the first scan hurts
The first scan of an older repository can return a long list. If every item arrives as an urgent alert, the team learns that the tool is noise. The findings may be real, but the delivery teaches people to look away.
GitHub's own behavior reflects this. Its documentation says that when Dependabot alerts are first enabled, GitHub does not send notifications for all vulnerable dependencies already found. Notifications cover new vulnerable dependencies identified afterward. The same idea applies to your own rollout.
The baseline and ratchet steps
- Scan and snapshot. Run the first scan and save the full result with a date. This is the baseline.
- Sort the baseline once. Separate known exploited issues and reachable production issues from the rest. Fix the first group now.
- Label the rest as accepted debt. Give each a reason, an owner team, and a target quarter. Not a permanent dismissal.
- Gate new findings only. Pull requests that introduce new issues above the threshold are blocked. Existing baseline items do not block merges.
- Ratchet. Each month or quarter, lower the threshold or shrink the baseline. Publish the date of the next step.
A simple ratchet schedule
| Stage | Blocks merge | Baseline handling |
|---|---|---|
| Month 0 | New critical findings | Snapshot and sort |
| Month 1 | New high and critical | Fix known exploited and reachable items |
| Month 3 | Any new finding in production code | Reduce baseline by agreed share |
| Month 6 | As above | Review remaining items for expiry |
The stages are an example, not a standard. Choose steps your team can actually meet.
Avoid three mistakes
- Silent permanent dismissal. If baseline items never expire, the debt vanishes from view. Put review dates on them.
- Blocking everything on day one. Developers will route around the gate.
- Treating severity as the sort key. FIRST's CVSS guidance states that the Base score measures severity and should not be used alone to assess risk. Add exploitation and reachability when sorting the baseline.
Where automation helps
Auto-triage rules can remove clear low-impact alerts before they notify anyone, and GitHub notes auto-dismissed alerts can be reopened if metadata changes, such as a dependency moving from development to production scope. That makes them a reasonable fit for the "label as accepted" step, provided you read each rule's criteria.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what a gate blocks and what it lets through.
Safeguard's policies and gates can enforce a new-findings-only rule, and the free scan at gold.safeguard.sh/scan can produce the first snapshot.
Quick check
Is a baseline just hiding problems?
Only if it never expires. A dated baseline with owners and a ratchet is a schedule, not a hiding place.
Should the baseline block releases?
Not by default. Block releases on new issues and on known exploited ones, and burn down the rest by plan.
Sources
- GitHub Docs, About Dependabot alerts
- GitHub Docs, Dependabot auto-triage rules
- FIRST, CVSS v4.0 User Guide
Last reviewed: 19 October 2026.
