SECURITY.md generator — a vulnerability reporting policy for your repo

How to use the SECURITY.md generator

1. Enter the Project name and the Security contact email. Use a shared address if more than one person handles reports.
2. Keep Offer GitHub private vulnerability reporting ticked and fill in GitHub repository (owner/name) to add a link to the private report form.
3. In Supported versions, write one line per release line, such as 2.x: yes or 1.x: no. Leave it empty if only the latest release gets fixes.
4. Set Acknowledge within, Assessment within and Coordinated disclosure window, all in days.
5. Optionally add a PGP key URL, then save the Markdown as SECURITY.md.

What it does and when to use it

Without a security policy, someone who finds a flaw in your project may report it in a public issue, where attackers can read it before a fix exists. SECURITY.md gives them a private route and sets expectations on both sides. Any public project with users should have one, and GitHub’s community profile checklist looks for it.

It sits alongside the other community files. The CONTRIBUTING.md generator handles ordinary contributions, the issue template generator can steer bug reports into a form, and the CODEOWNERS generator makes sure security fixes reach the right reviewers.

How it works

Each version line is split at : or |. Yes, true, ✓ and supported mark a version as supported; no, false, ✗ and unsupported do not; a line with neither is marked Unknown. The table is written in that order.

The reporting section lists the GitHub form (when ticked and a repository is given) and the email address with the PGP link. If both are missing, a placeholder asks you to add a private contact method. A fixed checklist asks reporters for the affected version, steps to reproduce and the impact. The “What to expect” section repeats your three time limits and promises credit in the advisory. GitHub explains where the file is shown in adding a security policy.

Worked examples

The defaults give this table and timeline:

| Version | Supported |
| ------- | --------- |
| 2.x | Yes |
| 1.x | No |

followed by “We aim to acknowledge your report within 3 days” and a 90-day disclosure window.

Email only, latest release only. Versions empty, GitHub option off, acknowledge within 1 day, PGP key URL set. The versions section says “Only the latest release receives security fixes.” and the only route is Email **security@example.com** (PGP key: https://example.com/pgp.asc). The timeline reads “within 1 day”.

Limits and tips

• A line without a yes or no word, such as 3.0 beta, is marked Unknown in the table and a warning asks you to add yes or no.
• The tool does not set up the email address or the PGP key; test that both work.
• The file is a promise to reporters, not legal advice. Have someone review it if your organisation runs a formal bug bounty.