The engineer adding a dependency should own the first check, and a code reviewer should confirm it in the pull request. Security or legal join only when a rule is tripped, such as a risky license or a sensitive domain. That keeps approval fast while leaving a record.
The problem with heavy approval
Central approval boards for every package slow teams until they work around them. The opposite, no process, leaves nobody able to say what is in the product. A lightweight policy sits between: automatic checks for most additions, human review where risk is higher.
Define three lanes
| Lane | When it applies | Who approves |
|---|---|---|
| Green | Passes automatic checks, permitted license, no sensitive domain | Author plus normal code reviewer |
| Amber | Missing signals, unusual license, large footprint, or pre-1.0 | Reviewer plus a named security or architecture contact |
| Red | Forbidden license, archived repository, or sensitive domain such as crypto or auth | Security and legal decide; may need an exception |
Publish the lists of allowed and forbidden licenses so the lane is obvious before anyone asks. The related decision of allow list versus deny list is covered in allow list or deny list: which license gate fits.
What the author does
- Complete the library checklist and paste it in the pull request.
- State why a library is needed rather than writing the code, using the build or adopt guide.
- Pin the version through the lockfile and commit it.
What the reviewer checks
- The filled checklist exists and the evidence is plausible.
- The change adds only the intended packages. Review the lockfile diff.
- Automatic checks ran: dependency scan, license check and any policy gate.
- There is a one-line exit note for amber items.
Automate what you can
Gates in pull requests can enforce rules without a meeting: block forbidden licenses, flag packages with known high severity advisories, and require a lockfile change to be explained. Human review then focuses on judgment calls.
Try it yourself
Click through it at your own pace, or open it full screen. Look at where a failing check stops a merge and what information the author sees.
Keep it honest over time
- Review exceptions quarterly and remove those no longer needed.
- Track how many additions land in each lane. If amber is most of them, your green criteria are too tight.
- Make the intake record searchable, so a new team can see prior decisions.
Handling urgent additions
Sometimes a team needs a package today to fix an outage. Allow an emergency path: the engineer adds it, flags it in the pull request, and a follow-up review happens within a few working days. Record the exception, and remove the package if the review fails. An honest fast lane is better than people skipping the process quietly.
Where Safeguard fits
Safeguard offers policies, gates and guardrails for pull requests, with SBOM and dependency scanning behind them, so green lane additions can pass automatically while risky ones get a review. Try the free scan at gold.safeguard.sh/scan.
Quick check
Should every package go to security?
No. Route only amber and red items to security. Everything else follows normal review with automatic checks.
What about packages added by an AI coding assistant?
Apply the same lanes. The author remains responsible for the dependency, whoever suggested it.
Last reviewed: 19 October 2026.
