Before releasing research software with a paper, confirm the license, commit a lockfile, scan for secrets and vulnerable dependencies, add a citation file, tag a release and archive it for a DOI. Doing it in that order takes about an hour and prevents most embarrassing, permanent mistakes.
Why this checklist exists
A released snapshot is cited for years. Mistakes in it are hard to retract. Archives such as Zenodo, covered in how to get a DOI for a release, preserve whatever the tag contains. A short routine before tagging is cheap insurance.
The checklist
| # | Check | Why |
|---|---|---|
| 1 | LICENSE file at the root | Without one, reuse is not permitted by default |
| 2 | Funder and institution policy checked | Some set license rules |
| 3 | Lockfile or environment file committed | So others can rebuild the environment |
| 4 | Secrets scan of the whole history | Archives keep what is in the tag |
| 5 | Dependency scan | Know what vulnerable code you ship |
| 6 | Data you may not redistribute removed | Licensing and privacy |
| 7 | CITATION.cff written | Precise credit and version |
| 8 | SECURITY.md added | Tells people how to report a flaw |
| 9 | Tag and release created | Fixed point to cite |
| 10 | Archive with DOI, record the identifier | Permanent reference |
Steps in practice
- Run a license check on your dependencies. See do transitive dependency licenses matter.
- Search your history for keys. If you find one, rotate it first. Deleting it from the repository does not make it safe.
- Scan your lockfile for known vulnerabilities and decide which updates are worth the risk to your results. See free vulnerability scanning for a research lab.
- Add a SECURITY.md for research software.
- Write your citation file.
- Tag, release, archive, then paste the DOI into the README and the paper.
After release
Releases age. Decide who watches for new advisories after the grant ends. See grant ends, who patches research software and do archived research repositories need rescans.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are ranked, so you can decide what to fix before the tag and what to note for later.
Quick check
Do I need to fix every vulnerability before release?
No. Fix what is reachable and serious, and document the rest. Pinning versions is needed for reproducibility, so record known issues in your notes.
What if I find a secret after I archived a release?
Rotate the secret immediately, then publish a new release. The archived copy cannot be assumed to be removable, so treat the secret as exposed.
Safeguard's dependency scanning and SBOM generation fit steps 3 and 5, and a free scan works on public repositories.
Last reviewed: 19 October 2026.
