Treat it as a planned migration, not an emergency. An archived repository is read-only, so no fixes, rule updates or releases will arrive. Keep it running in report mode while you pick a replacement, compare results, and cut over before its advisory data goes stale.
What archived means
GitHub's documentation says archiving makes a repository read-only for everyone and signals that it is no longer actively maintained. Issues, pull requests, code, releases, tags and more become read-only. Contributors can only fork or star the project. The owner can unarchive it later, but you should not plan around that.
The OpenSSF Scorecard Maintained check treats archived projects as the lowest score for the same reason: nobody is patching it.
Why a scanner is a special case
For a library you can often keep using old code safely for a while. A scanner is different, because its value is its knowledge of new problems. If detection logic or matching code stops changing, findings degrade quietly. Some tools pull data from separate feeds and may keep working longer, but you cannot count on that without checking.
Step 1: Confirm what stopped
Read the repository notice, the README and the last few releases. Find out whether the tool is archived, replaced by a successor, or merely quiet. Also check whether the data feed it uses is maintained separately.
Step 2: Freeze and fence
- Pin the current version so nothing changes under you.
- Reduce its permissions to read only.
- Note the date in your tracker as the start of an exit window.
- Stop adding new repositories to it.
Step 3: Define what you need to replace
List what the scanner did for you, not just its name. Use a table.
| Capability | Where it is used | Replacement needed |
|---|---|---|
| Dependency findings | CI on pull requests | Yes |
| Container image checks | Release pipeline | Yes |
| License output | Quarterly review | Check |
| SBOM export | Customer requests | Yes |
| Ignore rules | Per repository files | Migrate |
Step 4: Run both in parallel
Run the candidate beside the old tool on the same repositories for two to four weeks. Compare results by package and version, not by raw counts. Differences are expected, so investigate a sample of each kind. Keep the old tool in report only mode while you do this so builds are not blocked by either.
Step 5: Migrate rules and history
Move your ignore decisions, with reasons, into the new tool or into a central exceptions record. Export old reports before access changes, since audit trails and prior findings may be wanted later.
Step 6: Cut over and retire
Switch gates to the new tool, remove the old one from pipelines, revoke its tokens and delete its stored credentials. Record the date and the evidence of parity.
This is also a natural point to decide whether you want to keep assembling open source tools yourself. Safeguard offers SBOM and dependency scanning with policies and gates in one place, and a free scan at https://gold.safeguard.sh/scan lets you compare results on a real repository before you commit.
Quick check
Can I keep using an archived scanner?
It will still run, but it will not receive fixes or new detection logic. Use it only as a short bridge to a replacement.
Could the project come back?
The owner can unarchive it, but do not plan on it. Make the decision on today's facts.
Sources
- GitHub Docs, Archiving repositories
- OpenSSF Scorecard, Checks documentation
Last reviewed: 19 October 2026.
