Take a snapshot of every package your builds already use, mark it as grandfathered with an owner and a review date, and apply intake rules only to new additions and changes. Then work through the backlog in risk order. Trying to approve everything first means the program never starts.
Why the backlog should not block launch
A mature codebase may already depend on thousands of packages, direct and transitive. If you wait to review them all before turning intake on, new packages keep arriving unreviewed in the meantime. The first goal is to stop the number growing without control. The second is to shrink the risk in what exists.
Step by step
- Generate a baseline. Produce an SBOM from the lockfiles of every repository. Store it with a date.
- Mark everything as grandfathered. Each entry gets a status, an owner team and a review date. Make the status visible so nobody mistakes it for an approval.
- Turn on the gates for change. New packages and changed versions go through intake from a set start date.
- Route all installs through the mirror. From then on, only packages that pass intake or sit in the baseline resolve.
- Scan the baseline. Sort by severity, exploitability and exposure.
- Work the backlog in order. Start with malicious or abandoned packages, then critical advisories that are reachable.
- Expire grandfathered status. Give it a horizon, for example a year, after which an unreviewed entry is flagged.
The baseline entry
| Field | Example content |
|---|---|
| Package and version | name at version |
| Where used | list of repositories |
| Owner team | alias, not a person |
| Status | grandfathered |
| Review by | a date |
| Notes | known issues, replacement plan |
Order the backlog by risk
A useful order for the first pass:
- Packages known to be malicious or compromised.
- Packages abandoned by their maintainers.
- Packages with install scripts or native code.
- Packages with serious advisories that your code can reach.
- Everything else, by how widely it is used.
Reachability analysis helps with the fourth group, since it shows which vulnerable code your application can actually call.
Report progress to leadership
Show the backlog as a burn-down. Track the count of grandfathered entries with no owner, the count past their review date, and the count of high-risk entries remaining. Three numbers, updated monthly, are enough to show whether the program is shrinking risk or only collecting data. Pair them with the count of new packages that passed through intake, so the story covers both stopping growth and reducing what exists.
Communicate the change
Tell developers what starts on which date, what the baseline means, and how to request something new. Surprise is the main cause of bypass, and a clear announcement costs very little.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped and prioritised, which mirrors the backlog ordering above.
Where Safeguard fits
Safeguard's SBOM and dependency scanning can build the baseline, and reachability analysis helps rank what to fix first. Start with the free scan.
Quick check
Does grandfathering mean the packages are approved?
No. It means they are known and tracked with an owner, but not yet reviewed under the new rules.
How long should the grandfathered status last?
Set a horizon you can meet, often a year or less, and report overdue entries.
Last reviewed: 19 October 2026.
