The owning team of a shared library should approve any new dependency, because that dependency lands in every consuming service. Contributors can propose it, but the owner checks need, maintenance, licence and size before merge, and records the decision in the pull request.
Why libraries need stricter intake
When an application adds a package, one service takes the risk. When a shared library adds one, every consumer inherits it, often without noticing, through transitive resolution. A single careless addition can pull dozens of packages into services that never asked for them.
A routing rule
Use CODEOWNERS to require owner review on the files that declare dependencies, such as the manifest and lockfile. GitHub supports requiring review from code owners through branch protection, and notes that approval from any one listed owner satisfies the requirement. Make the listed owner the library team, not an individual. See CODEOWNERS to route dependency changes.
The checklist
| Question | What good looks like |
|---|---|
| Do we need it? | The standard library or existing dependencies cannot do the job in reasonable code |
| Is it maintained? | Recent releases, more than one maintainer, a way to report problems |
| What does it bring? | Count of transitive packages added |
| What is the licence? | Compatible with how your company distributes software |
| Is it known to be vulnerable or abandoned? | Check advisories and deprecation status |
| Can we pin it tightly? | Declared range is narrow, lockfile reviewed |
| Who is the backup if it dies? | Alternative or vendoring plan |
Decision outcomes
- Approve. Merge, and add the package to the library's dependency list in the README.
- Approve with conditions. For example, only in a subpackage so consumers can opt out.
- Reject. Suggest an existing alternative or a small local implementation.
Write the reason down. Future maintainers will ask why a package was added or refused.
Make optional things optional
If a feature needs a heavy dependency, move it to a separate package or an optional extra. Consumers who do not need the feature avoid the dependency and its advisories altogether.
Automate the first pass
Run a scanner in the pull request to flag known advisories, deprecated packages and licence issues, then let humans decide on need and fit. A gate that blocks on policy keeps the owner's review time for judgement.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Is one approval from the owner enough?
Yes for most additions. Use two approvals for libraries that handle authentication, cryptography or untrusted input.
Do dev only dependencies need the same review?
They need a lighter one. They do not ship to consumers, but they can still run in CI with secrets, so check provenance.
Sources
Last reviewed: 19 October 2026.
