Match the depth of review to what the component does. A small, low risk library gets a quick metadata check. Anything handling authentication, cryptography, payments, or untrusted input gets a full evaluation, including maintenance, security response, and a look at the code or install scripts.
Why tiers help
Reviewing everything deeply is too slow, and reviewing nothing is reckless. Tiers let a team spend effort where a failure would hurt most, and they give a product manager a predictable answer to "how long will approval take".
Three tiers
| Tier | Typical components | Review |
|---|---|---|
| 1, low | Formatting helpers, dev tools not shipped | Metadata check: license, last release, known vulnerabilities |
| 2, medium | Common utilities in production code | Tier 1 plus maintainer count, security policy, dependency impact |
| 3, high | Auth, crypto, parsing of untrusted input, anything with network or file access | Tier 2 plus security response history, sandbox test, install script and code review |
What the checks consist of
The OpenSSF guide to evaluating open source software gives specifics you can adopt:
- Necessity and authenticity. Could an existing component do the job, and is this the official project rather than a fork or lookalike?
- Maintenance. Significant commits and a release within the past 12 months, and more than one maintainer where possible.
- Security practices. Best Practices badge, Scorecard results, security response speed, whether older releases get patches.
- Licensing. Every component has a license that fits your use.
- Practical testing. Try it in an isolated environment and watch for suspicious behavior.
- Code evaluation. For the highest tier, inspect install scripts, look for reads of sensitive locations, and check for encoded or obfuscated code that gets executed.
Who does what
The requesting engineer does the tier 1 and 2 checks and attaches the results. A security reviewer handles tier 3. The product manager owns the timeline and the decision to proceed, and makes sure the review shows up in the plan.
Keep records
Save the result with the adoption note. When a customer or auditor asks how you choose components, you can show the tiers and a sample of evidence.
Recheck on change
Review again when the component's maintainer, license, or ownership changes, or when its usage in your product moves up a tier.
Quick check
Do dev tools need a review?
A light one. Build and test tools can run code on your machines and in your pipeline.
How long should a tier 3 review take?
It depends on the component. Estimate it with the reviewer before it is on the critical path of a release.
Safeguard's SBOM and dependency scanning and policy gates can automate the tier 1 checks, and the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
