Ninety days after adopting a library, compare what you assumed with what happened: upstream releases and advisories, your own incidents and update effort, license or ownership changes, and whether the exit plan still holds. Keep, wrap, or schedule replacement. It takes thirty minutes.
Why review at all
Adoption decisions are made with a snapshot of information. Three months of real use tells you more than the original spike did. A short, scheduled look catches drift early, while changing course is still cheap.
Put it on the calendar at adoption
Create the reminder in the pull request that adds the library. If you do not schedule it then, it will not happen. Assign one owner, ideally the person who adopted it.
The review questions
| Area | Question | Where to look |
|---|---|---|
| Upstream activity | Were there releases? Did maintainers answer issues? | Release list, issue tracker |
| Security | Any new advisories? Fixed quickly? | OSV, repository advisories |
| License | Did the license or notice change in any release? | License file history |
| Ownership | Did maintainers or publishers change? | Contributor and owner lists |
| Footprint | Did new transitive packages appear? | Lockfile diff, dependency graph |
| Our experience | Bugs, workarounds, performance problems? | Team notes, issue tracker |
| Update effort | How hard were upgrades? | Pull request history |
| Exit | Is the exit plan still accurate? | The plan itself |
Pay attention to ownership and license changes
A new owner or publisher on a package deserves a look. Maintainer handoffs have been part of real supply chain incidents; our write-up of maintainer handoff governance covers the idea. Also check that the license text did not change between versions. Reading release notes is not enough, so compare the license file across the versions you used.
Outcomes
- Keep as is. Note the date of the next review, maybe six or twelve months out.
- Keep with mitigation. Add a wrapper, more tests or a stricter update rule.
- Replace. Start the removal plan while you still have time.
Make later reviews automatic
A scheduled human review should sit on top of automation, not replace it. Advisory alerts, dependency update pull requests and policy gates give you continuous signals. The review catches things tools do not, such as an unhappy team or a slowing project.
A sample agenda
Spend five minutes on upstream activity, five on advisories, five on ownership and license, ten on your own experience and five on the exit plan. Write the outcome in the original pull request thread or decision record, with the next review date. Keeping the notes in one place means the second review starts where the first ended.
Try it yourself
Click through it at your own pace, or open it full screen. See how new findings surface after the initial decision, which is the automated half of this review.
Where Safeguard fits
Safeguard's continuous monitoring, SBOM and dependency scanning, and policies cover the automated half, flagging new advisories and enforcing rules in pull requests. Try the free scan at gold.safeguard.sh/scan.
Quick check
Do we need this for every dependency?
No. Do it for libraries on sensitive paths or hard to replace. Small helpers can ride on automated alerts.
Who runs the review?
The engineer who adopted the library, or the team that owns the service using it. Name the owner when you add it.
Last reviewed: 19 October 2026.
