Decide before the grant ends, not after. For each tool, pick one outcome: retire it, archive it read only, hand it to a named maintainer, or fund a minimum of upkeep. Software left running with no owner is the outcome to avoid, because it keeps collecting known vulnerabilities.
The problem in one sentence
Grants fund building software. Security upkeep, meaning updating dependencies and reading advisories, is a continuing cost that rarely has a line in the budget.
This post does not give funding or contract advice. Check your funder's terms and your institution's research office for what you may charge and what you must retain. What follows is the technical side: what to do with the software.
Four outcomes
| Outcome | Fits when | What it needs |
|---|---|---|
| Retire | Few users, result is published | Shut down the service, archive code and data |
| Archive read only | Code is a record, not a product | Pinned dependencies, no running service, clear note on status |
| Hand over | Another lab or group uses it | Named maintainer, security contact, access transfer |
| Fund minimum upkeep | Many users depend on it | Time for updates, a scan schedule, someone on call |
The key question is whether it is a running service. A static archive of code has a small attack surface. A web portal with a login and a database does not stay small.
A pre-end checklist
Do this in the last quarter of funding.
- List every deployed service, domain, server and credential the project owns.
- Scan dependencies now, update what is cheap, and record what is not.
- Write a short status note in the README: maintained, archived or unsupported.
- Add a security contact, even if it is a shared mailbox the department will keep.
- Turn off anything nobody will watch: test servers, old demo sites, spare accounts.
- Move credentials and keys to a custodian, and rotate those the departing team knew.
- Record the dependency list as a software bill of materials so future users can check it.
What to do with a service you cannot retire
If users still need it, reduce what it can do. Put it behind campus login, remove write access, drop optional features, and make it read only where possible. Then give it a review date. A service with a stated end date is easier to defend than one that simply drifts.
Signals that upkeep is not happening
The OpenSSF Scorecard project scores a Maintained check and a Dependency Update Tool check, among others. Even without running it, you can use the idea: no releases, no answered issues and stale dependencies are the signs that nobody is looking after a project.
Talking to your funder and institution
Bring the list of deployed services and the proposed outcome for each to your research office before the end date. They can tell you what must be kept, for how long, and who may keep paying for hosting. Having a concrete plan, such as archive on this date and shut down this service on that date, makes the conversation short. It also shows that upkeep was considered, which is a good habit to carry into the next proposal.
Where Safeguard fits
Safeguard can keep scanning a repository after the team has moved on and show which known vulnerabilities appear, so whoever inherits it sees a current list. That does not replace a named owner. Try the free scan on a project you are about to hand over.
Quick check
Is an archived repository still a security risk?
A static archive is a much smaller risk than a running service. Users who copy and run the code inherit its old dependencies, so label its status clearly.
Who should be the security contact after the team leaves?
A role address that the department keeps, or the named maintainer who took over. Avoid the personal email of someone who has left.
Sources
Last reviewed: 19 October 2026.
