Create SECURITY.md for security policy - #26
Conversation
Add a security policy document outlining supported versions and vulnerability reporting.
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
There was a problem hiding this comment.
Summary
This PR adds a SECURITY.md file to establish a security policy for the project, which is important for a post-quantum cryptography project. However, the file currently contains template placeholder content that must be replaced before merge.
Critical Issues Requiring Changes
- Incorrect version information - The supported versions table lists placeholder versions (5.1.x, 5.0.x, 4.0.x) that don't match the actual project version (0.1.0 from package.json)
- Missing vulnerability reporting mechanism - Template text remains instead of actual contact information and reporting procedures
- Template instructional text - Guidance text meant for template users is still visible
These issues prevent the security policy from being functional and could mislead security researchers. Please address all comments before merging.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
| | 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.
🛑 Incorrect Version Information: Replace placeholder versions with actual project version. The package.json shows the project is at version 0.1.0, but this table lists versions 5.1.x, 5.0.x, 4.0.x, and < 4.0 which don't exist in this project. This misleads security researchers about which versions to report vulnerabilities against.
| | 5.1.x | :white_check_mark: | | |
| | 5.0.x | :x: | | |
| | 4.0.x | :white_check_mark: | | |
| | < 4.0 | :x: | | |
| | 0.1.x | :white_check_mark: | |
| 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.
Remove template instructional text. This guidance should not be visible in the final security policy document.
| Use this section to tell people about which versions of your project are | |
| currently being supported with security updates. | |
| The following versions of Post-Quantum Studio are currently supported with security updates: |
| 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.
🛑 Missing Vulnerability Reporting Mechanism: Remove template text and provide actual vulnerability reporting instructions. Security researchers need specific contact information (security email address, GitHub Security Advisories link, or other reporting mechanism) and expected response timelines. Without this, the security policy is non-functional.
| 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. | |
| To report a security vulnerability, please use GitHub's Security Advisory feature: | |
| 1. Navigate to the Security tab of this repository | |
| 2. Click "Report a vulnerability" | |
| 3. Provide detailed information about the vulnerability | |
| We aim to respond to vulnerability reports within 48 hours and provide regular updates on the status of your report. |
There was a problem hiding this comment.
🟡 Changes recommended
The new SECURITY.md still contains template placeholder text and placeholder version/support data rather than a concrete, repo-specific security policy.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds a repository security policy document (SECURITY.md) intended to communicate which versions receive security updates and how to privately report vulnerabilities.
Changes:
- Introduces
SECURITY.mdwith sections for supported versions and vulnerability reporting. - Adds a supported-versions table and a reporting workflow section (currently based on the GitHub template text).
File summaries
| File | Description |
|---|---|
| SECURITY.md | Adds a security policy document, but still contains template placeholders that need to be replaced with repo-specific policy details. |
Review details
Suppressed comments (2)
SECURITY.md:13
- The supported-version entries (e.g., 5.1.x/5.0.x/4.0.x) appear to be placeholder values from the GitHub template. Update the table to match this repository’s actual versioning/release lines (or replace with supported branches like
main/stable) so users don’t rely on incorrect support information.
| ------- | ------------------ |
| 5.1.x | :white_check_mark: |
| 5.0.x | :x: |
| 4.0.x | :white_check_mark: |
| < 4.0 | :x: |
SECURITY.md:21
- The “Reporting a Vulnerability” section is still template guidance and doesn’t provide a real reporting channel. Add a concrete private contact method (e.g., GitHub Security Advisories “Report a vulnerability” flow or a security email), plus expected response timelines and what information reporters should include.
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.
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| 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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b6351eca96
ℹ️ 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.
Provide a usable vulnerability-reporting channel
This remains the unfilled GitHub template rather than a reporting policy: it gives researchers no email address, private issue flow, or other destination for a vulnerability report. As a result, a reporter cannot responsibly disclose a flaw through the policy this file adds, and may resort to a public issue or abandon the report.
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.
Align supported versions with the released project
The repository's only declared application version is 0.1.0 in package.json and it has no version tags, so this table incorrectly labels unrelated 4.x and 5.x versions as supported while omitting the version users can actually run. That makes it impossible for a reporter to determine the security-support status of the current project; replace the template entries with the actual supported version policy.
Useful? React with 👍 / 👎.
Add a security policy document outlining supported versions and vulnerability reporting.