Match the approval to the risk. A well-known library already used elsewhere in the company can be approved by the pull request reviewer. A new package with install scripts, network access or a single maintainer should get a named second reviewer, ideally from security or platform. Write the tiers down so new hires do not guess.
Why a tiered rule beats "ask someone"
Without a rule, new developers either add anything to avoid friction or ask everyone and slow down. A simple tier table gives a fast path for low risk and a slower path for high risk, and it makes the decision auditable later.
A sample tier table
| Tier | Example | Who approves |
|---|---|---|
| 1: Already approved | A package already in the shared allow list | Normal code reviewer |
| 2: New but ordinary | New utility library, active maintainers, no install scripts | Reviewer plus a short note in the pull request |
| 3: Elevated | Install scripts, native code, network or file access, one maintainer, recent ownership change | Named security or platform reviewer |
| 4: Sensitive area | Auth, crypto, build tooling, CI actions | Security reviewer and the code owner |
Adjust the lines for your company. The point is that the tier is decided by what the dependency does, not by who is adding it.
What the approver should see
Ask the author to put these in the pull request:
- The problem the package solves and why writing it in-house is worse.
- Alternatives considered, including the standard library.
- Maintainer and repository link, with recent activity.
- What it pulls in. A package that adds forty transitive packages is a larger decision than its name suggests. See direct versus transitive dependencies.
- Known advisories at the time of adding.
- Whether it runs code at install time.
- License category, handed to whoever owns license policy. This post is not legal advice.
Automate the boring half
Some checks do not need a human: a dependency review step on the pull request, an advisory lookup, a diff of the lockfile. GitHub describes dependency review as a way to catch insecure dependencies before you introduce them, showing what was added, removed or updated and any known vulnerabilities. Let tooling surface the facts so the reviewer spends time on judgment.
Keep a record
Log approvals somewhere searchable. When an advisory lands six months later, you want to know who approved the package and why. A short entry per decision is enough.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive packages appear in one inventory, which is what an approver needs to see.
Quick check
Do dev dependencies need approval too?
Yes, with the same tiers. Test and build tooling runs on developer machines and in CI, where credentials often live.
Who owns the allow list?
Name one team, usually platform or security, and give them a short turnaround target so the list does not become a bottleneck.
Sources
Last reviewed: 19 October 2026.
