# all·markdown

SECURITY.md template for a repository

Fill it in and copy it Open in the editor Opens as SECURITY.md, ready to edit. Nothing is uploaded.

The shape of it — edit here, or open the full template

Result

Runs entirely in this tab. Open the full editor to work on a real document.

Fill it in and take it

The whole file is below. Type into the boxes to replace the placeholders, then copy it or save it — nothing here is sent anywhere, and there is nothing to sign up for. 

   
  
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".