First confirm the project is really archived or abandoned, then freeze the version you run, check how stale its data has become, and choose one of three paths: fork it, replace it, or move to a managed platform. Do not rip it out in a hurry, because a gap in scanning is worse than an ageing tool.
Confirm the status
An archived repository is read only. The maintainers have stopped accepting changes. A quiet repository is different: it may be stable, or it may be stalled. OpenSSF Scorecard gives archived projects the lowest Maintained score, and its documentation notes that a low score can also describe a stable project, so read the issue tracker and release history before you decide.
Also check whether the database and the engine are separate. Sometimes the engine is frozen while a data feed continues, which changes your options.
Week one: stabilise
- Pin the exact scanner version in CI so nothing changes silently.
- Note the database date. If it no longer updates, the scanner is already blind to new advisories.
- Export current baselines, ignore files and any suppression list into your repository.
- Tell the owner of your security program and write the date down.
- Add a stop gap. Run a second source of advisory data on the same lockfiles, even if it is crude.
Weeks two and three: choose a path
| Path | Fits when | Cost to you |
|---|---|---|
| Fork and maintain | The engine is good, you have engineers who can own it, and the data source is still available | Ongoing staff time for engine fixes and data pipeline |
| Replace with another open source tool | Your needs are simple and the new tool covers your ecosystems | Migration effort, plus a fresh health check of the new tool |
| Move to a managed platform | You do not want to own the pipeline or staffing | Contract, onboarding and a data export plan |
Be honest about the fork option. Taking over a scanner means owning matching logic, ecosystem parsers and a data feed. That is a product, not a weekend task.
Week four: execute and verify
Run old and new tools side by side on the same repositories for at least one release cycle. Compare findings, as described in our guide to deduplicating findings across scanners. Where results differ, understand why before you switch the gate. Keep audit evidence continuous during the change, since an auditor will ask how coverage was maintained.
Keep it from happening again
Add the health check from checking an open source scanner project to your yearly calendar. Record who would act if upstream stopped, and keep your triage decisions in formats you can move.
Safeguard is one managed route. It offers dependency scanning, reachability analysis and compliance evidence, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Should I switch scanners the same day a repository is archived?
Usually not. Pin the version, confirm data freshness, and run a planned side by side comparison.
Can I just keep using an archived scanner?
Only if its data still updates and you accept owning any engine bugs. If the data stops, it stops finding new issues.
Sources
Last reviewed: 19 October 2026.
