To make research software citable, add a plain text file named CITATION.cff to the root of your repository. List authors, title, version, release date and ideally a DOI. GitHub then shows a "Cite this repository" link and offers APA and BibTeX formats built from that file.
What a CITATION.cff file is
CFF stands for Citation File Format. It is a small YAML file that is readable by people and by tools. Reference managers, archives and GitHub can all read the same fields, so you write your citation once instead of retyping it in every README and paper.
The minimum is short. GitHub's own example uses a cff-version, a message, a list of authors with optional ORCID identifiers, a title, a version, a DOI and a release date.
cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
- family-names: "Example"
given-names: "Ada"
orcid: "https://orcid.org/0000-0000-0000-0000"
title: "My Research Software"
version: 2.0.4
doi: 10.5281/zenodo.1234
date-released: 2026-10-01
The values above are placeholders. Use your own DOI and ORCID.
Steps to add one
- Create CITATION.cff in the repository root on the default branch.
- Fill in authors in the order you want them cited. Add ORCID identifiers where people have them.
- Add the version and date-released that match your latest tagged release.
- If you have archived the release and received a DOI, add it. See the Zenodo release guide.
- Commit, then open the repository page and check that the "Cite this repository" link appears in the sidebar.
- If you would rather have people cite a paper, GitHub supports a preferred-citation override in the same file.
Why this belongs in a security conversation
A citation file is also provenance. When a reader of your paper finds a vulnerable or broken version, a precise version and DOI tell them exactly which code produced your results. That matters when someone has to decide whether a published analysis is affected by a later security fix.
The risk is drift. A CITATION.cff that still says version 1.0 after three releases points readers at the wrong code. Treat it like any other release artifact.
| Field | Why it helps | Common mistake |
|---|---|---|
| version | Pins which code was cited | Never updated after release |
| date-released | Orders versions in time | Copied from first release |
| doi | Permanent link to the archive | Concept DOI used where a version DOI is needed |
| authors | Credit and contact | Missing contributors who wrote core modules |
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a precise component inventory complements a precise citation: one says which code, the other says which dependencies it ran with.
Quick check
Do I need a DOI to use CITATION.cff?
No. A DOI is optional. The file works with just authors, title and version, and you can add the DOI later once the release is archived.
Does GitHub validate the file for me?
GitHub reads the file and builds the citation prompt from it. Check the rendered link after each change, and keep the version field in step with your tags.
Safeguard's SBOM and dependency scanning can record which dependency versions shipped with a release, and you can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
