Yes, but lightly. Your code does not change, yet the advisories about its dependencies do. Store a dependency inventory with the archive and recheck it against current vulnerability data on a schedule, so the project page can say what is known today rather than what was known at release.
Why the answer changes over time
A package version with no known problem at publication can have one a year later. Public vulnerability databases keep growing. OSV, for example, collects records from other databases that follow a common open format, so new entries keep arriving for old versions.
An archive that was clean at release is not necessarily clean now. Anyone who downloads it and runs it inherits whatever is known about its dependencies today.
What to store
- A lock file or fully pinned list of dependencies.
- An SBOM generated at release, with the date.
- The scan result at release, including what you chose not to fix.
- A short status line: maintained, archived or unsupported.
How often to recheck
| Project type | Suggested rhythm |
|---|---|
| Still used in teaching or by others | Monthly |
| Cited and downloaded, no active work | Each quarter |
| Pure record, nobody runs it | Twice a year, or when a major advisory appears |
You do not need to rebuild anything. Rechecking means rerunning the lookup against the stored list.
What to do with new findings
- If the project is a record, add a note to the README listing the known issues and recommending against running it on shared systems.
- If it is still useful, decide whether to publish a patched release.
- If it is a service, treat it as live and apply your normal priority rules, or shut it down.
Why a visible status helps
A reader deciding whether to run your code can see a note that says "Archived on a date. Known issues in dependencies listed below. Run in an isolated container." That is more useful than a clean looking repository with no information. It is also kinder to the next student who forks the project.
Automate the quiet part
A monthly job that reruns an audit against the stored lock file takes minutes to set up. The point is that nobody has to remember. Tools that read lock files, such as OSV-Scanner, accept many formats including requirements.txt, poetry.lock, package-lock.json and renv.lock.
Who does the rechecking
Name a person or a role, not a project. When funding ends, the role should be the department or a research software group. If neither exists, add a line to your handover note: this archive will not be rechecked, and readers should scan it themselves before use.
That honesty is part of the record. It also tells any later user exactly how much trust to place in the old results.
Try it yourself
Open the continuous monitoring demo and watch how a stored inventory picks up a new finding without a rebuild.
Click through it at your own pace, or open it full screen.
Safeguard offers continuous scanning of stored inventories, so an archived project can keep surfacing new advisories. Try the free scan for a first pass.
Quick check
Do I need to update code that is only an archive?
Not necessarily. Label its status and known issues instead, and update only if people still run it.
Is a release time scan enough?
It records the state at release. New advisories need a later recheck.
Sources
Last reviewed: 19 October 2026.
