Libraries that handle authentication, cryptography, secrets, logging of sensitive data or untrusted input deserve a stricter tier: two reviewers, tighter dependency limits, faster fix times and a named backup maintainer. Utility libraries can follow lighter rules. Tiering stops you from treating everything the same.
Why tier at all
If every library gets the heaviest process, owners route around it. If every library gets the lightest, the sensitive ones are underprotected. A tier gives you a defensible reason for different rules.
Suggested tiers
| Tier | Typical libraries | Rules |
|---|---|---|
| Critical | Authentication, authorization, crypto helpers, session handling, input parsers | Two approvers, dependency cap, signed releases where supported, quick service level |
| Standard | API clients, shared data models, framework integrations | One owner approval, scanner gate on pull requests |
| Low | Formatting helpers, internal CLIs for convenience | Default repository rules |
Use your own list. The point is that the criteria are written and applied by someone other than the library author.
What stricter means in practice
- Review. Code owner approval on every change, and two approvers for the critical tier. GitHub supports requiring review from code owners through branch protection.
- Dependencies. A tight dependency budget and review of each addition.
- Releases. A two person publish, as in who can publish an internal library release.
- Testing. Security focused tests, including negative cases such as malformed tokens.
- Response. Shorter acknowledgement and fix times in the service level.
- Staffing. Three maintainers, not two.
Logging libraries deserve a mention
A logging helper looks harmless, but it decides what gets written, including whether tokens, personal data or request bodies reach logs. Review its defaults and redaction behaviour, and treat changes to it like changes to a data handling control.
Who assigns the tier
The owner proposes, a security or platform reviewer confirms. Revisit when usage changes: a utility that begins to parse untrusted input has moved up a tier.
Evidence
Keep the tier, the approvers and the release records in the library repository. That makes audits and customer questionnaires easier, and it gives new maintainers the context.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and see how a policy check blocks a risky change before merge.
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
Who decides if a library is critical?
The owner proposes it using written criteria, and a reviewer outside the owning team confirms.
Do consumers of critical libraries need extra rules too?
Yes. Ask them to upgrade within the stricter service level and report any exceptions.
Sources
Last reviewed: 19 October 2026.
