Approval should depend on risk. Low risk packages pass automatically against policy, medium risk goes to a named reviewer with a response deadline, and high risk goes to a small panel. Putting every package in front of one committee guarantees delays and shadow dependencies.
Why tiers beat a single queue
If every request waits for the same people, the queue grows, and developers add packages without asking. Tiers let you spend scarce review time where a wrong decision costs the most.
A starting set of tiers
| Tier | Typical packages | Decision | Target time |
|---|---|---|---|
| Low | Test and build tools, widely used libraries with an allowed license and no serious open advisories | Automatic, logged | Immediate |
| Medium | Runtime libraries in internal services, parsers, anything handling untrusted input | Named reviewer from security or the platform team | One to two working days |
| High | Packages with high privilege, handling credentials or crypto, shipped to customers, or with an unusual license | Panel of security, legal and engineering | A fixed number of days you commit to |
Choose your own times and write them down. The numbers matter less than keeping them.
What moves a package up a tier
- It runs at install or build time with access to secrets.
- It processes data from outside your network.
- It has a single maintainer or no recent activity.
- It has open high severity advisories without a fix.
- Its license is unusual or has conditions that affect shipped products.
- It pulls in a large number of new transitive dependencies.
Each of these can be checked by a tool, so tier assignment itself can be automatic.
Keeping a fast lane open
- Allow pre approval of families, such as everything from a trusted publisher with an allowed license, within a version range.
- Auto approve patch and minor updates of approved packages if the checks pass.
- Give developers a temporary sandbox path for experiments that never ship, with a rule that anything promoted to a product must go through intake.
- Report the median decision time every month. If it grows, fix the process before blaming the team.
Recording decisions
Store each decision with the tier, reason, approver, conditions and a review date. This feeds the approved list and gives you evidence if an auditor asks how you decide.
Try it yourself
Click through it at your own pace, or open it full screen. Check how knowing whether vulnerable code is actually called changes how urgent a finding is.
Quick check
Can developers approve their own low risk packages?
Yes, if an automatic check against written rules approves them and the decision is logged. Self approval without a rule check is not a control.
What if the reviewer is on leave?
Name a backup for each tier so the response time holds.
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.
