Developer Documentation / Project Tools

SECURITY.md Generator

Write a SECURITY.md vulnerability disclosure policy with supported versions, a private reporting channel and response times.

Tell researchers how to report a vulnerability privately and what to expect next - generate a clear SECURITY.md in a minute.

Project name

How should people report a vulnerability?

Email or URL (for email / web form)

Repository URL (optional)

Supported versions - one per line: version yes|no

Acknowledge within

days

Target fix / update

days

PGP key URL (optional)

Include a good-faith research (safe harbor) statement

Offer to credit reporters

What Is the SECURITY.md Generator?

It writes a SECURITY.md file: a short, public security policy that tells people which versions receive security fixes and how to report a vulnerability privately. GitHub shows this file on the repository's Security tab and links to it when someone tries to open a security-related issue.

Why It Matters

Without a policy, a researcher who finds a problem often has no choice but to open a public issue - which discloses the vulnerability to everyone before you can fix it. A clear policy gives them a private channel and sets expectations on both sides.

How to Use It

Choose how reports should reach you: GitHub private vulnerability reporting, an email address, or a web form.
List your supported versions, one per line, ending with yes or no.
Set realistic response times and choose whether to include a good-faith research statement and reporter credit.
Generate, then save the file in the repository root, docs/ or .github/.

Example

The lines 2.x yes and < 1.4 no become a Supported Versions table with a tick and a cross. With email reporting, the policy asks reporters to write to your security address and lists what to include: impact, reproduction steps, affected versions.

Understanding the Output

The generated policy has five parts: supported versions, how to report, what to include, what reporters can expect (acknowledgement and fix timelines, coordinated disclosure) and what is out of scope. Only promise response times your team can actually meet.

Limitations

A policy is a promise, not a process: someone must watch the reporting channel. This template is not a legal safe-harbor agreement or a bug bounty programme. For email-based reporting, publishing a /.well-known/security.txt file (RFC 9116) on your website helps too. Link the policy from your CONTRIBUTING.md.

Frequently Asked Questions

In the repository root, the docs folder or the .github folder. GitHub detects it in any of these places and links to it from the Security tab and from the new issue page.

It is a repository setting that lets anyone submit a vulnerability report privately to the maintainers through the Security tab, creating a draft security advisory. You enable it in the repository settings under Code security.

Only promise what your team can reliably meet. Acknowledging a report within a few business days is common for small projects; fix times depend on severity and complexity, so many policies describe a target rather than a guarantee.

It states your intent not to take action against researchers who act in good faith, but it is not a formal legal agreement. Organisations that need stronger protection should have their legal team review the wording.