Keep an approved package list current by giving every entry a named owner, an approved version range, a review date and a retirement rule, then reviewing entries on a schedule and removing ones nobody uses. A list that only grows becomes a rubber stamp.
Why lists go stale
Approval is a moment in time. The package was fine when reviewed, then the maintainer changed, the license changed, or advisories piled up. Without a date on the entry, nobody knows how old the decision is.
A second cause is that nobody removes anything. Teams move to a different library, but the old one stays approved forever, and new projects pick it because it is on the list.
What each entry should record
| Field | Purpose |
|---|---|
| Package and ecosystem | Exact identity, ideally as a package URL |
| Approved version range | Stops silent jumps to a major version no one reviewed |
| Internal owner | Person or team who answers for upgrades |
| Approved for | Scope, such as internal tools only or customer facing |
| Review date and next review date | Makes staleness visible |
| Conditions | For example, use only the safe API, or pin to a patched version |
| Status | Approved, deprecated or removed |
A review routine that fits real teams
- Run a monthly report of entries past their review date. Do not review everything at once.
- For each, pull current facts: latest version, open advisories, license text, maintainer activity and whether anyone in the company still uses it.
- Ask the owner one question: do you still need this?
- Renew, downgrade the scope, mark deprecated or remove.
- Record the outcome and the next date.
Use risk to set the interval. Packages that run in customer facing code or with high privilege might be reviewed every six months. Test only libraries can go longer.
Deprecated is a real status
Removing a package from the list can break builds. Add a deprecated state first: existing use is allowed until a date, new use is blocked, and the report shows who still depends on it. This gives teams a path and gives you a clear count to drive down.
Watch for use, not just approval
Compare the list to what is actually pulled through your proxy or listed in your SBOMs. Two gaps matter. Packages in use but not approved show where the process is being bypassed. Packages approved but never used are clutter that can be dropped.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a package that was clean at approval can pick up new findings later.
Quick check
How often should entries be reviewed?
Set it by risk. Six months suits customer facing or privileged packages, and a year may suit low risk ones. Also review on trigger events such as a new advisory or license change.
What if a team needs a package that is not listed?
They submit an intake request. Low risk requests should be approved automatically against policy, so the list does not become a bottleneck.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
