As a starting rule, look for a release within the past 12 months and meaningful project activity in the same period. That is what the OpenSSF evaluation guide suggests. Scorecard looks at a tighter 90 day window for commits. Use these as prompts for a closer look, not automatic rejections.
The two windows
Two public sources give you numbers:
- The OpenSSF evaluation guide asks for significant recent activity, such as commits, within the past 12 months, and for the last release to be within the past 12 months. It also asks for communication from maintainers, such as recent releases or announcements.
- Scorecard's Maintained check gives its highest score to a project with at least one commit per week during the previous 90 days, a partial score for issue activity from collaborators, members or owners, and the lowest score to an archived project.
The 12 month window answers "is anyone still home". The 90 day window answers "how busy is it right now". Different questions, different thresholds.
Apply them by type of package
| Package type | How to read a quiet year |
|---|---|
| Fast moving framework or SDK | Concerning, expect regular releases |
| Small, finished utility | Often fine, check for open issues |
| Parser or protocol library on untrusted input | Concerning, new attack techniques keep appearing |
| Wrapper around a changing service API | Concerning, the service will have changed |
| Archived repository | Treat as unmaintained |
A finished utility with no open issues and no vulnerabilities may be complete. Quiet does not always mean abandoned.
Steps to decide
- Find the date of the last release and the last commit.
- Check whether the repository is archived or marked deprecated.
- Open the issue tracker. Are recent security reports unanswered?
- Read the last few release notes. Are they substantive, or only dependency bumps?
- If the signals conflict, decide based on exposure: how much untrusted data does this package touch?
- Record the decision and a date to look again.
For a deeper look at a package nobody has touched in a long time, read what to do with an abandoned open source project.
What a long gap should trigger
A gap past 12 months is the point to ask for a plan, not necessarily to rip out the package. Options include replacing it with a maintained alternative, taking over maintenance through a fork, or accepting the risk with an owner and a review date. Whichever you choose, make it explicit.
Also watch the opposite signal. A flurry of new activity after years of silence, from an unfamiliar contributor, is worth reading closely. Handovers of quiet projects are a known route for attackers.
Try it yourself
Open the demo and see how continuous monitoring flags changes to a dependency over time instead of relying on a one time check.
Click through it at your own pace, or open it full screen.
Quick check
Is a package with no release in 13 months abandoned?
Not necessarily. It is a prompt to check activity, open issues and whether the package is finished. Decide by exposure.
Which is stricter, Scorecard or the OpenSSF guide?
Scorecard's top score uses a 90 day window for weekly commits, while the guide uses 12 months. They ask different questions.
Safeguard's SBOM and dependency scanning, with continuous monitoring, tracks the packages you use so a change in their status does not wait for the next audit. Try the free scan.
Sources
Last reviewed: 19 October 2026.
