Create SECURITY.md#8
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f3afbf6dba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 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 |
There was a problem hiding this comment.
Add a real vulnerability disclosure contact
The Reporting a Vulnerability section is unchanged template text and does not provide an actual private reporting channel (email, security form, or similar) or response timeline. Without concrete instructions, external researchers cannot reliably disclose vulnerabilities, which increases the risk of delayed or public-first disclosure instead of coordinated remediation.
Useful? React with 👍 / 👎.
| | 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.
Correct supported-version matrix to real release lines
The supported-version table appears to be boilerplate (5.1.x, 5.0.x, 4.0.x) rather than this project's actual release lines, so it can give users false assurance about which builds receive security fixes. A security policy should map to real shipped versions; otherwise users and downstream maintainers may stay on unpatched builds because the document is inaccurate.
Useful? React with 👍 / 👎.
| | 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.
Include currently shipped major line in supported versions
This table marks only 4.x/5.x as considered in policy and implicitly excludes the currently shipped 3.x line from security support guidance, which can make users believe the active release train is already out of support. The security policy should explicitly list the current major line (or clearly state planned deprecation) to avoid misdirecting users about patch eligibility.
Useful? React with 👍 / 👎.
No description provided.