Create SECURITY.md for security policy#18
Conversation
Added a security policy document outlining supported versions and vulnerability reporting.
There was a problem hiding this comment.
Pull request overview
Adds a SECURITY.md file intended to document this repository’s security support policy and vulnerability reporting process.
Changes:
- Introduces a new
SECURITY.mdsecurity policy document - Adds a supported-versions matrix
- Adds a vulnerability reporting section
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 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: | |
There was a problem hiding this comment.
The "Supported Versions" section is still the GitHub template text and the version matrix (5.1.x/5.0.x/4.0.x) doesn’t appear to match this repo’s actual release history (e.g., CHANGELOG shows 1.0.0). Please replace this placeholder with the project’s real supported version policy and update the table accordingly (or remove the table if you don’t publish versions).
| 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. |
There was a problem hiding this comment.
The "Reporting a Vulnerability" section is still placeholder guidance ("Use this section to tell people...") rather than an actionable process. Please provide a concrete reporting channel (e.g., security email / GitHub Security Advisories link), what details to include, and expected response timelines.
| 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. | |
| Please do **not** report security vulnerabilities through public GitHub issues. | |
| Report suspected vulnerabilities by either: | |
| - emailing **security@example.com**, or | |
| - opening a private report through **GitHub Security Advisories** for this repository. | |
| When submitting a report, please include: | |
| - a clear description of the issue and its potential impact; | |
| - the affected version(s), branch, or commit, if known; | |
| - detailed reproduction steps or a proof of concept; | |
| - any relevant logs, stack traces, screenshots, or configuration details; and | |
| - your contact information for follow-up questions. | |
| We will acknowledge receipt of your report within **3 business days** and will | |
| provide a status update within **7 business days**. After validating the issue, | |
| we will work on a fix and coordinate disclosure with you. If the report is | |
| determined not to be a security vulnerability, we will let you know and explain | |
| the outcome when possible. |
Added a security policy document outlining supported versions and vulnerability reporting.