Improving the default SECURITY.md template along with perhaps requiring it in bigger public projects?

[Dredsen]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Code quality

Discussion Details

Improving the default SECURITY.md template

Hello,

first - sorry if this is the wrong section. It's my first time using Discussions, but this seemed most relevant since the file's purpose is vulnerability reporting.

The current default

Right now the default SECURITY.md for all projects is:

# Security Policy

## Supported Versions

Use this section to tell people about which versions of your project are
currently being supported with security updates.

| Version | Supported          |
| ------- | ------------------ |
| 5.1.x   | :white_check_mark: |
| 5.0.x   | :x:                |
| 4.0.x   | :white_check_mark: |
| < 4.0   | :x:                |

## Reporting a Vulnerability

Use this section to tell people how to report a vulnerability.

Tell them where to go, how often they can expect to get an update on a
reported vulnerability, what to expect if the vulnerability is accepted or
declined, etc.

I think this is a poor default. Most of us would rather not write it from scratch per project, or hunt down a well-formatted one from a popular repo to copy over.

Suggestion 1: A better generic default

Ship a default template that's generic enough to cover most use cases out of the box, while still being easy to extend.

An even better alternative might be copying what LICENSE.md does: let users pick from generic templates suited to different project types. Possibly include an option to disable security reporting altogether, with an explanation - e.g. the project has no online capability and vulnerability reports wouldn't apply.

Suggestion 2: Opt-in / opt-out for larger projects

This one I know is more divisive, but it pairs well with the LICENSE.md style approach: once a project gains enough traction, require maintainers to either opt in to a SECURITY.md or opt out with a written explanation.

I don't know exactly how we'd define "big enough" to warrant this. But looking around, I've seen plenty of 20,000+ star projects that lack a SECURITY.md entirely - they either handle reporting on their website or stuff the vulnerability-reporting info into the README instead of using the dedicated tool.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Dredsen]

An example using the LICENSE.md style which allows users to select from multiple ones would be something like a generic default option that works as a catch-all. ( This could probably be improved quite a bit. )

Other templates could be provided such as ones that would have better formats and areas to support payments depending on the report like other bug bounty programs offer, ones that require some user input to fill in like their email, website, etc.

# Security Policy

## Supported Versions

Security reports are always accepted for the **`main` branch** (latest code).

Other branches - including release branches, forks, and older tags - may or may not receive fixes at the maintainers' discretion. If in doubt, report it anyway; we'll let you know.

## Reporting a Vulnerability

Please **do not** report security vulnerabilities through public GitHub issues, discussions, or pull requests.

Instead, report them privately using [GitHub's Private Vulnerability Reporting](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) via the **Security** tab of this repository.

### A note on AI-assisted reports

If AI tooling (LLMs, automated scanners, agentic assistants, etc.) helped you discover, analyse, or write up this issue, please say so in your report. This isn't a judgement - AI-assisted findings are welcome - but disclosing it up front helps maintainers calibrate how much additional verification a report needs, and tends to make the report itself clearer.

When submitting a report, please use the structure below so it can be triaged quickly.

---

### 1. Summary

A short, one-paragraph description of the vulnerability and its impact (e.g. what an attacker can achieve, who is affected, and under what conditions).

### 2. Steps to Reproduce / Proof of Concept

Provide a minimal, reliable reproduction:

1. Step one
2. Step two
3. Step three

Include any required input, payloads, configuration, or code snippets. Attach a PoC script or screenshots where helpful.

### 3. Expected vs. Actual Behaviour

- **Expected:** what *should* happen
- **Actual:** what *does* happen, and why it's a security issue

### 4. Suggested Fix or Mitigation *(optional)*

If you have an idea for how to address the issue, describe it here. A patch or pull-request link is welcome but not required.

- **Have you tested this fix?** Yes / No
- **If yes,** briefly describe how it was tested and what was verified.

---

## What to Expect

- **Acknowledgement** within a reasonable timeframe after receiving your report
- **Updates** as the issue is investigated and addressed
- **Public credit** in the resulting advisory, along with any **CVE assigned**, unless you'd prefer to stay anonymous

We follow a **90-day coordinated disclosure** window: please allow up to 90 days from the date of your report for the issue to be investigated and patched before publicly disclosing it. The publication date - whether earlier if a fix lands sooner, or later if more time is genuinely needed - will be agreed with you in advance.