SECURITY.md template for a repository
Make your SECURITY.md
Fill these in and the whole file updates. Nothing is sent anywhere, and there is nothing to sign up for.
# Security Policy
<!--
SECURITY.md goes in the repository root, .github/ or docs/. GitHub links it
from the Security tab and shows it to anyone about to open a public issue
about a vulnerability, which is the whole point. Without this file, the
first report you get will be a public issue describing how to exploit you.
-->
## Reporting a vulnerability
Please **do not open a public issue**.
Email **security@example.com** with:
- what the issue is, and what an attacker could do with it
- the smallest steps that reproduce it
- the version or commit you tested
- whether it is already public anywhere
<!--
GitHub's private vulnerability reporting is the better route if the
repository has it enabled: Settings > Code security > Private vulnerability
reporting. It gives the reporter a tracked, private thread and a draft
advisory, with no shared inbox to secure. If you enable it, say so here and
keep the email as a fallback.
-->
You can also report privately through the repository's **Security** tab, under
*Report a vulnerability*.
## What happens next
| When | What |
| :--- | :--- |
| Within 3 working days | We acknowledge the report |
| Within 10 working days | We confirm the issue and give a rough timeline |
| On release | We publish a fix and credit you, unless you prefer otherwise |
If a report goes unacknowledged past that first window, send a follow-up: it
means the mail went astray, not that it was ignored.
## Supported versions
<!-- Be honest here. "Latest only" is a perfectly good answer and far better
than a table implying support you will not provide. -->
| Version | Supported |
| :--- | :--- |
| 2.x | Yes |
| 1.x | Security fixes until 2027-01-01 |
| < 1.0 | No |
## Scope
In scope: the code in this repository, and its published packages.
Out of scope:
- Anything in a dependency: report those upstream, and tell us if we should
pin or patch in the meantime
- Findings from automated scanners with no demonstrated impact
- Missing hardening headers on the project website, absent an actual attack
- Social engineering, physical access, and denial of service by brute volume
## Disclosure
We aim to release a fix before any public detail. If you plan to publish,
please give us **90 days**, or less by agreement if the fix ships sooner. We
will credit you in the advisory and the changelog unless you would rather stay
anonymous.
We do not run a paid bug bounty.
Visual
SECURITY.md exists to change where the first report arrives. Without one, a
person who finds a vulnerability in your project has exactly one obvious
route (the issue tracker) and their first message describes the exploit in
public.
GitHub links this file from the Security tab and surfaces it to anyone opening an issue, so it only has to do two things well.
Give a private route
An email address, or GitHub’s private vulnerability reporting, or both. If the repository can use the built-in reporting (Settings, Code security, Private vulnerability reporting) prefer it: the reporter gets a tracked private thread, you get a draft advisory, and there is no shared inbox to secure.
Keep the email as a fallback. Not everyone finds the button.
Say what happens next
This is the part most policies skip and the part that determines how the report goes:
| Within 3 working days | We acknowledge the report |
| Within 10 working days | We confirm it and give a timeline |
| On release | We publish a fix and credit you |
A reporter who hears nothing cannot tell triage from indifference, and a reporter who thinks they are being ignored publishes. Committing to a first response costs nothing on the many days no report arrives.
Be honest about supported versions
“Latest only” is a good answer. A table implying you will patch a three-year-old major version is worse than no table, because someone will rely on it.
Scope, so the signal survives
Without a scope section you will receive scanner output. Naming what is out of scope (dependency issues, findings with no demonstrated impact, missing hardening headers on a marketing site, denial of service by volume) is not rudeness. It keeps the queue short enough that a real report is noticed.
Disclosure
Ninety days is the usual ask, shorter by agreement when a fix ships sooner. State it, and state whether you pay. Reporters check for a bounty, and a clear “we credit, we do not pay” starts better than silence on the question.
Common questions
- Where does SECURITY.md go?
- The repository root, `.github/` or `docs/`. GitHub finds it in any of the three, links it from the Security tab, and shows it to anyone about to open a public issue, which is the point of having one.
- What actually has to be in it?
- A private way to report, and what happens after. Everything else is optional. A policy that says "email us" with no timeline gives a reporter no way to tell being triaged from being ignored, and that is when things get published early.
- Should I use GitHub's private vulnerability reporting instead?
- If the repository can, yes: it gives the reporter a tracked private thread and you a draft advisory, with no shared inbox to secure. Enable it under Settings, Code security. Keep an email address in the file as a fallback for people who do not find the button.
- Why promise a timeline at all?
- Because silence is indistinguishable from indifference, and a reporter who thinks they are being ignored publishes. Three days to acknowledge and ten to confirm costs nothing when nothing arrives, and buys you the disclosure window when something does.
- Do I need to offer a bug bounty?
- No, and say so plainly if you do not. Reporters check, and an unanswered question about money is a worse start than a clear "we do not pay, we do credit".