The Maintained check in OpenSSF Scorecard rewards a project with commits in most weeks of the last 90 days and activity from collaborators on issues. Archived projects score lowest. A low score is a prompt to investigate, not proof of abandonment, and the documentation says no fix is required.
What it measures
The checks documentation describes Maintained as a High risk check. It asks whether the project shows weekly commits over the last 90 days and whether collaborators are active on issues. The summary table adds that the project must be at least 90 days old, so a brand new repository cannot score well yet.
Archived repositories receive the lowest score.
Why a low score can mislead
Activity is a stand-in for care. That works most of the time, but it has blind spots.
- Finished libraries. A small parser or a date helper may be complete. It may see a commit every few months and still be perfectly sound.
- Bursty work. Some maintainers work in sprints. Weekly commits penalise that rhythm.
- Work elsewhere. Fixes may land in a downstream fork, a mirror, or a different branch layout than the check expects.
On the other side, a high score can come from busy but low value commits.
A better way to read it
Treat a low Maintained score as a question list.
- Are there open vulnerability reports with no reply? Silence on a security issue is the real warning sign.
- When was the last release, and what did it contain? A release a year ago with an unpatched known issue is different from a stable release with no open issues.
- How many people can publish? One person with sole publishing rights is a bus factor problem, regardless of commit frequency.
- Is the repository archived or marked deprecated? If so, plan a replacement.
- Does the project have a security policy and a reporting channel? The Security-Policy check looks for a SECURITY.md with contact details.
What to do with an unmaintained dependency
You have a few options, in rough order of effort: pin and monitor it, wrap it so it can be swapped later, contribute a fix upstream, vendor and own it, or replace it. Which fits depends on how deeply the package sits in your code and whether a vulnerability reaches code you actually run.
Our related post on abandoned open source projects covers the replacement decision in more depth: abandoned open source project risks.
Safeguard's SBOM and dependency scanning keep a running inventory so you know which of your applications depend on a quiet package, and reachability analysis shows whether a known flaw in it is reachable.
Quick check
Does archived status always mean unsafe?
No, but it means no further fixes from that repository. Any new vulnerability will stay unpatched there, so plan an exit.
Sources
Last reviewed: 19 October 2026.
