Create SECURITY.md for security policy and reporting#3
Create SECURITY.md for security policy and reporting#3Lawrence Lucas Large (LukeLarge) wants to merge 1 commit intomasterfrom
Conversation
Added a security policy document outlining supported versions and vulnerability reporting. Signed-off-by: Lawrence Lucas Large <162439255+LukeLarge@users.noreply.github.com>
Lawrence Lucas Large (LukeLarge)
left a comment
Lawrence Lucas Large (LukeLarge)
left a comment
There was a problem hiding this comment.
Create SECURITY.md for security policy and reporting
#3
There was a problem hiding this comment.
Pull request overview
Adds a SECURITY.md file to define the project’s security policy, including supported versions and vulnerability reporting guidance.
Changes:
- Introduces a Security Policy document (
SECURITY.md) - Adds a “Supported Versions” section with a version support table
- Adds a “Reporting a Vulnerability” section (currently placeholder text)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| | 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 markdown table has an extra leading pipe (||), which will render as an unintended empty first column. Use a single leading pipe for each row (e.g., | Version | Supported |).
| Use this section to tell people about which versions of your project are | ||
| currently being supported with security updates. | ||
|
|
There was a problem hiding this comment.
This reads as the default template text rather than a project-specific policy. Replace with concrete supported version ranges (or maintenance branches) and a clear reporting process (private contact method, expected response timelines, disclosure expectations).
| 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.
This reads as the default template text rather than a project-specific policy. Replace with concrete supported version ranges (or maintenance branches) and a clear reporting process (private contact method, expected response timelines, disclosure expectations).
| | 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.
Relying only on emoji icons for support status can be less clear for some readers and assistive technologies. Consider using explicit text such as Supported / Not supported (optionally alongside emoji) to make the table more universally readable.
| | Version | Supported | | |
| | ------- | ------------------ | | |
| | 5.1.x | :white_check_mark: | | |
| | 5.0.x | :x: | | |
| | 4.0.x | :white_check_mark: | | |
| | < 4.0 | :x: | | |
| | Version | Supported | | |
| | ------- | ---------------------------- | | |
| | 5.1.x | :white_check_mark: Supported | | |
| | 5.0.x | :x: Not supported | | |
| | 4.0.x | :white_check_mark: Supported | | |
| | < 4.0 | :x: Not supported | |
Added a security policy document outlining supported versions and vulnerability reporting.