A security support policy states which SDK versions receive security fixes, for how long, how customers report vulnerabilities, and how you announce fixes. Publish it in a SECURITY.md file in the repository and on your docs site so customers know when they must upgrade.
Why a policy beats silence
Without a stated policy, customers guess. Some assume every old version is patched, others assume none are. Buyers reviewing your SDK also ask which versions are supported, and a written answer shortens that review. GitHub's documentation says to add information about supported versions of your project and how to report a vulnerability to a SECURITY.md file. The Go project publishes a similar page that explains how to report security bugs and what to expect in return.
CISA's Secure by Design guidance frames this as taking ownership of customer security outcomes and being transparent. A support policy is a small, concrete act of that.
What to include
| Section | What to say |
|---|---|
| Supported versions | A table of major versions and their support status |
| Support duration | How long after the next major release a version gets fixes |
| Fix scope | Security fixes only, or also critical bugs |
| Reporting | Contact address, expected response time, preferred format |
| Disclosure | Whether you coordinate a disclosure date and publish advisories |
| Notification | Where fixes are announced: changelog, advisory feed, mailing list |
A template to adapt
# Security policy
## Supported versions
| Version | Status |
| 4.x | Security fixes |
| 3.x | Security fixes until the date below |
| 2.x and older | Not supported |
## Reporting a vulnerability
Email the address in our security contact file. Do not open a public issue.
We aim to acknowledge reports within a stated number of working days.
## Disclosure
We publish an advisory and a changelog entry with each security fix.
Fill the placeholders with commitments you can actually keep. A date you miss is worse than a longer one you meet.
Steps to set it up
- Decide how many major versions you will patch at once. Two is a common, manageable choice for small teams, but pick the number your staffing supports.
- Tie support to your release calendar. State the end date of each supported major version when you release the next one.
- Define what counts as a security fix, so customers know a patch release may arrive without a feature change. See what semver means for security fixes.
- Create the reporting channel before you need it, and test that the mailbox is read.
- Pair the policy with a machine readable contact file on your website.
- Link the policy from the README, the docs and the package registry page.
- Review it each time you ship a new major version.
Mistakes to avoid
Promising backports you cannot staff is the first. Hiding the policy in a wiki that customers cannot reach is the second. A third is forgetting the end of life message: when a version leaves support, say so in the changelog and, if your registry allows, mark it deprecated with a pointer to the supported line.
Quick check
Where should the policy live?
In SECURITY.md at the root of the repository, which GitHub surfaces, plus a page on your documentation site and a link from your package listing.
How many versions should we support?
As many as you can patch reliably. State the number and the dates, and update them when you release a new major version.
Safeguard's SBOM and dependency scanning helps customers see which version of your SDK each build contains, and its compliance and evidence automation can keep the policy and its evidence together. The free scan shows what it finds in a repository.
Sources
Last reviewed: 19 October 2026.
