Support only as many release lines as you can actually patch, and say so in a short table in SECURITY.md. For most volunteer projects that means the latest release line and perhaps one previous major version. A promise you cannot keep is worse than a narrow one you can.
Why the section exists
GitHub's guidance for a security policy says to add information about supported versions of your project and how to report a vulnerability. Reporters read the first part to see whether their version is covered. Users read it to decide when to upgrade. Without it, everyone guesses.
Pick a rule you can keep
Common patterns:
- Latest only. Simple, honest, and fits a one-person project. Users must upgrade to get fixes.
- Latest plus previous major. Gives users one migration window. Costs you backports.
- Time-based. Each release gets security fixes for a fixed period after publishing, such as a year.
- Long-term support lines. Only if you have funding or people to back it.
Base the choice on how many backports you can realistically make in a bad week, not a good one.
A table that is easy to read
| Version | Supported |
| ------- | ------------------ |
| 3.x | yes |
| 2.x | security fixes only until 2027-06-30 |
| 1.x | no |
Treat the dates above as an example format, not a recommendation. Use your own.
What to write next to the table
- What "supported" means: security fixes only, or bugfixes too.
- How long after a new major version the old one is patched.
- That fixes for unsupported versions are not provided, and users should upgrade.
- Where to find advisories.
Backports cost real effort
Each extra release line multiplies the work of a security fix, because you must patch, test and release each. If a fix is hard to backport, you may need to say so in the advisory and give a workaround. The trade-offs are discussed in retiring or backporting fixes to old API versions.
Keep it current
Update the table at each major release. An out-of-date table that lists a dead branch as supported misleads reporters and users. Add the review of this table to your release checklist. The open source release checklist is a good home for it: open source release security.
Tell users what to do
Give a plain upgrade path. If version 1.x is unsupported, say which version to move to and link the migration notes. Reporters of vulnerabilities in unsupported versions deserve a polite reply that explains the policy.
Pair it with the rest of the policy
The table is one section. The rest covers how to report and what to expect. See writing a SECURITY.md.
Quick check
Do I have to support old versions?
No. Say what you support and stick to it. Narrow and honest beats broad and broken.
Where does SECURITY.md go?
GitHub describes creating it in the repository through the Security tab under Security policy, then committing it. Use a pull request when committing to the default branch.
Sources
Last reviewed: 19 October 2026.
