Re-review an adopted dependency when something changes that your original approval relied on: the people who can publish, the way releases are built, the advisory record, the project's activity, or how you use the package. A calendar review is a backstop, not the main trigger.
Why triggers beat a calendar
A yearly review of every package is expensive and mostly finds nothing. Events are cheaper and sharper. Your approval assumed certain facts, so when one of those facts moves, the approval is stale.
The trigger list
| Trigger | What changed | First action |
|---|---|---|
| Registry owner added or removed | Who can publish | Check owners and the diff, see maintainer change checks |
| New advisory | Known weakness | Check whether you run the affected version and path |
| Malware advisory | Package itself is hostile | Remove, rotate anything it could touch |
| Long silence, then a burst of releases | Possible handoff or revival | Read the diff before upgrading |
| Silence for a long period | Possible abandonment | Start the exit plan |
| Workflow or release method changed | Build path | Re-read the workflows and provenance |
| Your usage grew | Blast radius | Move to a deeper review tier |
| Major version bump | Large code change | Treat as a new adoption |
The GitHub Advisory Database notes that malware advisories have no fix version, so the only safe step is to stop using the package. That is why a malware match should start the strongest response.
What "silence" means
OpenSSF Scorecard's Maintained check looks at whether a project is active and at least 90 days old, and rates it high risk. Use that as one data point and check release and commit dates yourself. A mature, finished library may legitimately go quiet. A busy library that stops answering issues is different. Read our note on abandoned open source project risks.
How to automate the triggers
You do not want to track eight signals by hand across hundreds of packages. Aim for:
- A software bill of materials per application, kept current.
- Alerts when any listed component gets a new advisory.
- A pull request check that flags new or changed dependencies for human review.
- A short list of must-review packages, those with install scripts, credentials access or broad permissions, where owner changes get a person's attention.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a change after the initial scan surfaces as a new finding. That is the loop a re-review trigger depends on.
Safeguard can help here. Its SBOM and dependency scanning, reachability analysis and policy gates cover the checks that should repeat after adoption, and the free scan at gold.safeguard.sh/scan shows what a project already depends on.
Quick check
How often should I review on a calendar anyway?
Quarterly for high-blast-radius packages and yearly for the rest is a reasonable starting point. These intervals are our suggestion, not a standard.
Does every new advisory need a full re-review?
No. First check whether you use the affected version and code path. A full re-review is for advisories that point to deeper maintainer or process problems.
Sources
Last reviewed: 19 October 2026.
