Security policy template (Markdown)

This template covers those two points plus what to include in a report, response targets, and how disclosure works. Replace the placeholders, delete the reporting options you do not offer, and commit it to the default branch.

Need it as a document? Paste the filled-in template into the free Markdown to Word or Markdown to PDF converter.

Copyable Markdown SECURITY.md template

# Security policy

## Supported versions

The following versions of [Project name] receive security updates:

| Version | Supported |
|---|---|
| [3.x] | Yes |
| [2.4.x] | Security fixes only, until [YYYY-MM-DD] |
| [< 2.4] | No |

If you use an unsupported version, upgrade to a supported version before reporting.

## Reporting a vulnerability

Do not report security vulnerabilities through public issues, discussions, or pull requests.

Report vulnerabilities privately using one of these options:

- **GitHub private vulnerability reporting:** Open the [Security and quality tab](https://github.com/[owner]/[repository]/security) of this repository and select **Report a vulnerability**. [Delete this option if private vulnerability reporting is not enabled.]
- **Email:** [security@example.com]. [Optional: Encrypt your message with our PGP key: link to key, fingerprint.]

## What to include

To help us assess the report quickly, include as much of the following as you can:

- The type of vulnerability, for example cross-site scripting, SQL injection, or authentication bypass
- The affected version, component, and file paths
- Step-by-step instructions to reproduce the issue
- Proof-of-concept code or a request that demonstrates it, if available
- The impact, including how an attacker might exploit it
- Any special configuration required to reproduce it
- How you would like to be credited, if at all

## What to expect

These are our targets. Actual times may vary.

- **Acknowledgment:** within [number] business days of your report
- **Initial assessment:** within [number] business days, including whether we accept the report
- **Status updates:** at least every [number] days until the issue is resolved
- **Fix and release:** [Describe how fixes are prioritized, for example by severity]

If we decline the report, we will explain why.

## Disclosure policy

We follow coordinated disclosure:

1. We confirm the vulnerability and determine the affected versions.
2. We prepare fixes for all supported versions.
3. We release the fixes and publish a security advisory.
4. We credit the reporter in the advisory, unless they ask to remain anonymous.

Please keep the vulnerability confidential until we publish a fix, or until [number] days after your report, whichever comes first. If you need a different timeline, tell us in your report.

## Scope

**In scope:** [Repositories, packages, services, or domains covered by this policy]

**Out of scope:** [For example: issues in third-party dependencies that should be reported upstream, denial of service through excessive traffic, social engineering, findings from automated scanners without a demonstrated impact]

## Contact

For questions about this policy that are not vulnerability reports, contact [email or link].

What a security policy is for

Most projects use public issue trackers. A vulnerability posted there is visible to everyone, including people who could exploit it, before a fix exists. A security policy gives reporters a private path and tells them what happens next, which makes them more likely to use it.

The policy also helps users. The supported versions table tells them whether the version they run still receives security fixes, and the disclosure section tells them how fixes and advisories are announced.

Supported versions

Keep the table short and current. Use version ranges that match your release process, such as major versions (3.x) or minor lines (2.4.x). If older versions receive fixes for a limited time, give an end date. Update the table in the same release that drops support for a version.

Choose a reporting channel

Offer at least one private channel and test it:

• GitHub private vulnerability reporting creates a private draft advisory that maintainers and the reporter can discuss, and lets the reporter start a temporary private fork. It is available for public repositories once an owner or administrator enables it.
• A security email address works for any project and any reporter. Use an address monitored by more than one person, such as a group alias.

GitHub can also collect specific fields in private reports through a VULNERABILITY_REPORT.yml file in the .github folder of a default community health repository.

Response times are targets, not promises

Write response times you can meet with the people you have. A small volunteer project might acknowledge reports within seven days; a company product might commit to two business days. Missing a stated time damages trust more than stating a longer one. The template uses placeholders so you choose the numbers.

Related: security.txt

SECURITY.md covers a repository. For a website or online service, RFC 9116 defines security.txt, a plain text file served at /.well-known/security.txt. It must contain a Contact field and an Expires field, and it can include a Policy field that links to a page such as your SECURITY.md. RFC 9116 was published in 2022 as an Informational RFC.

Completed SECURITY.md excerpt

## Supported versions

| Version | Supported |
|---|---|
| 4.x     | Yes |
| 3.9.x   | Security fixes only, until 2027-06-30 |
| < 3.9   | No |

## Reporting a vulnerability

Do not open a public issue. Use "Report a vulnerability" on the
Security and quality tab, or email security@example.org.

We acknowledge reports within 3 business days and send updates
at least every 7 days.

The excerpt names exact versions, gives an end date for limited support, and offers two private channels with response targets. The versions, dates, and address are fictional.

What to include in SECURITY.md

SECURITY.md FAQ

Where should SECURITY.md go?

In the repository root, the docs folder, or the .github folder. If more than one copy exists, GitHub uses the one in .github first, then the root, then docs. You can also create it from the Security policy option on the repository's Security and quality tab.

Do I need SECURITY.md if I enable private vulnerability reporting?

It is still useful. Private vulnerability reporting provides the form; the policy tells reporters which versions are supported, what to include, and what to expect. GitHub shows the policy above the report form.

What should a security policy include?

At minimum, the supported versions and how to report a vulnerability privately. Most policies also list what to include in a report, response targets, the disclosure process, and scope.

Can one SECURITY.md apply to all my repositories?

Yes, on GitHub. Add it to a public repository named .github in your organization or personal account. GitHub uses it for any repository that does not have its own SECURITY.md.

What is the difference between SECURITY.md and security.txt?

SECURITY.md is a file in a code repository. security.txt, defined in RFC 9116, is served by a website at /.well-known/security.txt and gives contact details and a policy link for that site. A project with both a repository and a website can use both, with security.txt linking to the policy.

Related templates

• CODE_OF_CONDUCT.md template
• CONTRIBUTING.md template
• GitHub issue template
• Pull request template
• README template
• CHANGELOG.md template
• Bug report template
• All Markdown templates

Sources

• GitHub Docs: Adding a security policy to your repository
• GitHub Docs: Privately reporting a security vulnerability
• GitHub Docs: Creating a default community health file
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure