A dependency looks abandoned when its repository is archived, nobody has committed in a long time, and maintainers stop answering issues or fixing reported vulnerabilities. No single signal proves it. Check several, decide whether the package still matters to you, and record a plan for any that do.
What the OpenSSF check measures
The OpenSSF Scorecard project has a Maintained check. Per its documentation, an archived project gets the lowest score, and a project with at least one commit per week over the previous 90 days gets the highest. Activity on issues from collaborators, members or owners earns a partial score. The check applies to GitHub projects older than 90 days.
The same documentation adds a caution that matters: lack of active maintenance is not always a problem. Small utility functions may not need changes. A low score means investigate further, not replace immediately.
A practical check
- List your direct dependencies from the lock file and the SBOM.
- For each, look at the source repository: archived flag, date of the latest commit, date of the latest release.
- Open the issue tracker. Are security reports answered?
- Check whether the package has known advisories that stayed unfixed.
- Search for a successor or fork the community has moved to.
- Record the result next to the component.
You can run Scorecard against a repository from the command line to get the Maintained score without clicking around.
Classifying what you find
| Situation | Suggested handling |
|---|---|
| Archived, with advisories | Plan replacement, give a date |
| Quiet, small and stable, no advisories | Accept, note review date |
| Quiet, handles input, auth or crypto | Treat as high priority |
| Maintained by one person | Note concentration risk |
| Fork you maintain internally | Treat as your own code and own its patches |
Why buyers care
An unmaintained package that parses untrusted input will eventually have a vulnerability nobody fixes. A buyer inherits that. Showing you have already listed these packages, decided on each and scheduled the replacements is strong evidence of control.
How to present it
One table, ten rows or fewer: package, what it does in your product, signal observed, decision, owner, date. If you have dozens, show the ones that touch customer data or network input and summarise the rest by count.
Mistakes to avoid
Treating a repository with few commits as dead without reading why. Replacing a stable library with a trendier one that adds more risk. Hiding an archived dependency in a long list. Forgetting that the maintainer of a package can change without a repository change, so look at ownership of the registry entry too.
Try it yourself
Click through it at your own pace, or open it full screen.
See how monitoring flags changes after the initial scan, which is how a newly unfixed advisory on a quiet package gets noticed.
Safeguard's dependency scanning and continuous monitoring flag new advisories on components you already use. A free scan shows the current state of one repository.
Quick check
Is an archived repository always a problem?
No, but it means no further fixes. Decide whether you can live with that, or plan a replacement.
Does a high Scorecard score mean a safe dependency?
No. It measures practices, not the absence of vulnerabilities.
Sources
Last reviewed: 19 October 2026.
