Where should the SECURITY.md file live?

GitHub looks for SECURITY.md in the repository root, the docs folder, or the .github folder. When present, a Security policy link appears in the repo's Security tab and on the new-issue page so reporters find it first.

What is a private security advisory?

GitHub lets maintainers and reporters discuss a vulnerability in a private, repository-scoped thread before any fix is public. It can also request a CVE and produce a published advisory once patched, which is the safest channel for coordinated disclosure.

Why include a supported-versions table?

The table tells reporters which release lines you will actually patch, so nobody wastes time reporting against an end-of-life version. Mark only the branches you still backport security fixes to as supported.

Should I publish a security email or just use advisories?

Offering both widens coverage: advisories keep everything in GitHub, while an email works for reporters who cannot or will not use the GitHub UI. Use a dedicated alias rather than a personal address so reports are not missed.

What response times should I commit to?

Acknowledge reports within a few business days and aim to fix or mitigate within roughly 30 days, adjusted for severity. State the windows honestly; an unrealistic promise you cannot meet erodes trust with security researchers.

SECURITY.md Policy Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A security policy reporters can actually follow

A clear SECURITY.md is the difference between a researcher quietly emailing you a fix and dropping a zero-day on social media. This builder produces a complete, GitHub-aware policy: which versions you patch, exactly how to report privately, who to contact, and what timeline to expect — all from a short form.

How it works

The tool assembles standard Markdown sections that GitHub recognises. The Supported Versions table is built by comparing each release line you list against your supported set, marking patched branches with a check and the rest with a cross. The Reporting a Vulnerability section wires in GitHub’s private advisory flow and/or a security email, then states your acknowledgement target (in business days) and your fix-or-mitigation target (in days). Optional scope and PGP sections round out a coordinated-disclosure-ready document. Nothing is sent anywhere — the Markdown is generated entirely in your browser.

Tips and example

Use a dedicated alias such as [email protected], monitored by more than one person, so a report never sits unread.
Keep the supported-versions list short and honest — only branches you genuinely backport fixes to belong there.
Prefer GitHub private advisories as the primary channel; they keep discussion, the CVE request, and the published advisory in one place.
A typical commitment is “acknowledge within 3 business days, fix within 30 days” — adjust for your team’s real capacity rather than copying a number you cannot meet.