Add a SECURITY.md to your repositories in ten minutes

A SECURITY.md file in a repository tells people where to send a vulnerability report instead of posting it publicly. GitHub's security policy feature is available on all plans for public and private repositories. Write a contact, an expectation for response time and a short scope, then keep it current.

Why it matters

If a researcher finds a flaw and cannot find how to tell you, three things can happen: they give up, they open a public issue, or they email a random employee. A clear file gives them a better path.

What GitHub provides

GitHub's feature overview says security policy is available on all GitHub plans, for public and private repositories, as a way for users to confidentially report vulnerabilities they find. Security advisories, for privately discussing and fixing a vulnerability and then publishing, are also on all plans but described for public repositories.

What to put in the file

1. How to report: a monitored security email address, or the private reporting channel on the platform.
2. What you commit to: acknowledgement within a number of days you can really meet.
3. Which versions or products are supported.
4. What is in scope and out of scope, in plain language.
5. A safe harbour statement if your lawyer agrees, saying you will not pursue good faith research.
6. Whether you offer rewards. If you do not, say so, to avoid disappointment.

Keep it under a page.

Traps to avoid

A contact address nobody reads is worse than none. Use an alias that reaches two people, and test it quarterly with a message from a personal account.

Do not promise timelines you cannot keep. Do not demand silence forever. A coordinated disclosure window is normal, and you can state a default.

Link it to your website

Also publish a security page and a security.txt file on your domain. See our post on the security.txt format and expiry check. For a template that covers scope and timelines, see the one page VDP template.

Common pitfalls

A few more practical points. Make sure the reporting address is monitored when people are on holiday, so name a backup. Decide how you will track reports: a private issue board or a simple spreadsheet is enough. When you fix something, thank the reporter and, with their permission, credit them. If a report is out of scope, say so politely and explain why. Reporters who feel respected tend to report again, and to give you time to fix problems before sharing details.

Also think about what happens when a report arrives about a dependency rather than your own code. Decide whether you forward it upstream, patch around it, or both. Keep a record of the date you told the maintainer, since that date matters if a disclosure timeline later becomes a point of discussion.

Quick check

Sources

1. GitHub security features (GitHub Docs)

Last reviewed: 19 October 2026.