Create SECURITY.md for security policy #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add a security policy document outlining supported versions and vulnerability reporting.
Guía del revisorAñade un nuevo archivo SECURITY.md que describe las versiones compatibles y proporciona una sección de marcador de posición para informar vulnerabilidades. Diagrama de flujo para determinar el estado de compatibilidad de versión a partir de SECURITY.mdflowchart TD
A[Start] --> B[Identify_project_version]
B --> C{Version_range?}
C --> D[5.1.x]
C --> E[5.0.x]
C --> F[4.0.x]
C --> G[< 4.0]
D --> H[Supported]
F --> H[Supported]
E --> I[Not_supported]
G --> I[Not_supported]
H --> J[Follow_security_guidance_for_supported_versions]
I --> K[Consider_upgrading_to_supported_version]
Cambios a nivel de archivo
Consejos y comandosInteracción con Sourcery
Personalizar tu experienciaAccede a tu panel para:
Obtener ayuda
Original review guide in EnglishReviewer's GuideAdds a new SECURITY.md file describing supported versions and providing a placeholder section for reporting vulnerabilities. Flow diagram for determining version support status from SECURITY.mdflowchart TD
A[Start] --> B[Identify_project_version]
B --> C{Version_range?}
C --> D[5.1.x]
C --> E[5.0.x]
C --> F[4.0.x]
C --> G[< 4.0]
D --> H[Supported]
F --> H[Supported]
E --> I[Not_supported]
G --> I[Not_supported]
H --> J[Follow_security_guidance_for_supported_versions]
I --> K[Consider_upgrading_to_supported_version]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - he revisado tus cambios; aquí tienes algunos comentarios:
- El archivo
SECURITY.mdtodavía contiene texto de marcador de posición de la plantilla (por ejemplo, “Use this section to tell people…”); reemplázalo con información específica del proyecto sobre las versiones compatibles y la política de actualizaciones de seguridad. - En la sección “Reporting a Vulnerability”, añade detalles concretos sobre cómo informar (método de contacto, tiempos de respuesta esperados y proceso de divulgación) para que los usuarios sepan exactamente cómo proceder y qué esperar.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `SECURITY.md` file still contains template placeholder text (e.g., “Use this section to tell people…”); replace these with project-specific information about supported versions and security update policy.
- Under “Reporting a Vulnerability”, add concrete reporting details (contact method, expected response times, and disclosure process) so users know exactly how to proceed and what to expect.
## Individual Comments
### Comment 1
<location> `SECURITY.md:17-21` </location>
<code_context>
+
+## 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.
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Customize the vulnerability reporting section with concrete instructions.
This still reads like author-facing placeholder text. Please replace it with your actual reporting channel (security email, issue tracker, disclosure program), expected response timelines, and what reporters can expect during triage and resolution so the policy is directly usable.
Suggested implementation:
```
## Reporting a Vulnerability
If you believe you have found a security vulnerability in this project, please report it to us privately so we can investigate and fix the issue before it becomes public.
### How to Report
Please send a detailed report to:
- Email: `security@example.com`
- Subject line: `Security report: <short description>`
Your report should include (when possible):
- A description of the issue and the affected component(s) or endpoint(s)
- Steps to reproduce the issue (proof-of-concept code, requests, or configuration)
- Any relevant logs, screenshots, or impact assessment
- Your operating system, runtime, and version information
- Any known workarounds
If you believe the issue is especially sensitive (e.g., leads to immediate compromise of user data or infrastructure), please indicate this clearly in your report so we can prioritize it appropriately.
### Our Response Process
We aim to:
- Acknowledge receipt of your report within **3 business days**
- Provide an initial assessment or follow-up questions within **7 business days**
- Keep you informed of the triage status at least every **14 days** until resolution
During triage we will:
1. Validate the vulnerability and assess its impact and severity.
2. Determine the affected versions and whether a fix or mitigation is required.
3. Prepare patches, tests, and release notes as needed.
### Disclosure and Credit
Once a fix is available:
- We will coordinate a disclosure timeline with you, when possible.
- We will include a note in the release notes and/or security advisories describing the issue in general terms (impact, affected versions, mitigation).
- If you would like to be credited, we will acknowledge you as the reporter in the advisory and/or changelog (unless you prefer to remain anonymous).
Please do **not** open public issues for security vulnerabilities or share details in public channels until we have completed triage and released a fix.
```
You should replace `security@example.com` with your actual security contact address or reporting channel (for example, a real security mailbox, a private issue tracker link, or a disclosure program URL). If you use a specific SLA or different timelines, adjust the response and update cadence in the “Our Response Process” section accordingly so it reflects your real process.
</issue_to_address>Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Original comment in English
Hey there - I've reviewed your changes - here's some feedback:
- The
SECURITY.mdfile still contains template placeholder text (e.g., “Use this section to tell people…”); replace these with project-specific information about supported versions and security update policy. - Under “Reporting a Vulnerability”, add concrete reporting details (contact method, expected response times, and disclosure process) so users know exactly how to proceed and what to expect.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `SECURITY.md` file still contains template placeholder text (e.g., “Use this section to tell people…”); replace these with project-specific information about supported versions and security update policy.
- Under “Reporting a Vulnerability”, add concrete reporting details (contact method, expected response times, and disclosure process) so users know exactly how to proceed and what to expect.
## Individual Comments
### Comment 1
<location> `SECURITY.md:17-21` </location>
<code_context>
+
+## 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.
</code_context>
<issue_to_address>
**🚨 suggestion (security):** Customize the vulnerability reporting section with concrete instructions.
This still reads like author-facing placeholder text. Please replace it with your actual reporting channel (security email, issue tracker, disclosure program), expected response timelines, and what reporters can expect during triage and resolution so the policy is directly usable.
Suggested implementation:
```
## Reporting a Vulnerability
If you believe you have found a security vulnerability in this project, please report it to us privately so we can investigate and fix the issue before it becomes public.
### How to Report
Please send a detailed report to:
- Email: `security@example.com`
- Subject line: `Security report: <short description>`
Your report should include (when possible):
- A description of the issue and the affected component(s) or endpoint(s)
- Steps to reproduce the issue (proof-of-concept code, requests, or configuration)
- Any relevant logs, screenshots, or impact assessment
- Your operating system, runtime, and version information
- Any known workarounds
If you believe the issue is especially sensitive (e.g., leads to immediate compromise of user data or infrastructure), please indicate this clearly in your report so we can prioritize it appropriately.
### Our Response Process
We aim to:
- Acknowledge receipt of your report within **3 business days**
- Provide an initial assessment or follow-up questions within **7 business days**
- Keep you informed of the triage status at least every **14 days** until resolution
During triage we will:
1. Validate the vulnerability and assess its impact and severity.
2. Determine the affected versions and whether a fix or mitigation is required.
3. Prepare patches, tests, and release notes as needed.
### Disclosure and Credit
Once a fix is available:
- We will coordinate a disclosure timeline with you, when possible.
- We will include a note in the release notes and/or security advisories describing the issue in general terms (impact, affected versions, mitigation).
- If you would like to be credited, we will acknowledge you as the reporter in the advisory and/or changelog (unless you prefer to remain anonymous).
Please do **not** open public issues for security vulnerabilities or share details in public channels until we have completed triage and released a fix.
```
You should replace `security@example.com` with your actual security contact address or reporting channel (for example, a real security mailbox, a private issue tracker link, or a disclosure program URL). If you use a specific SLA or different timelines, adjust the response and update cadence in the “Our Response Process” section accordingly so it reflects your real process.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+17
to
+21
| 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.
🚨 suggestion (security): Customize the vulnerability reporting section with concrete instructions.
This still reads like author-facing placeholder text. Please replace it with your actual reporting channel (security email, issue tracker, disclosure program), expected response timelines, and what reporters can expect during triage and resolution so the policy is directly usable.
Suggested implementation:
## Reporting a Vulnerability
If you believe you have found a security vulnerability in this project, please report it to us privately so we can investigate and fix the issue before it becomes public.
### How to Report
Please send a detailed report to:
- Email: `security@example.com`
- Subject line: `Security report: <short description>`
Your report should include (when possible):
- A description of the issue and the affected component(s) or endpoint(s)
- Steps to reproduce the issue (proof-of-concept code, requests, or configuration)
- Any relevant logs, screenshots, or impact assessment
- Your operating system, runtime, and version information
- Any known workarounds
If you believe the issue is especially sensitive (e.g., leads to immediate compromise of user data or infrastructure), please indicate this clearly in your report so we can prioritize it appropriately.
### Our Response Process
We aim to:
- Acknowledge receipt of your report within **3 business days**
- Provide an initial assessment or follow-up questions within **7 business days**
- Keep you informed of the triage status at least every **14 days** until resolution
During triage we will:
1. Validate the vulnerability and assess its impact and severity.
2. Determine the affected versions and whether a fix or mitigation is required.
3. Prepare patches, tests, and release notes as needed.
### Disclosure and Credit
Once a fix is available:
- We will coordinate a disclosure timeline with you, when possible.
- We will include a note in the release notes and/or security advisories describing the issue in general terms (impact, affected versions, mitigation).
- If you would like to be credited, we will acknowledge you as the reporter in the advisory and/or changelog (unless you prefer to remain anonymous).
Please do **not** open public issues for security vulnerabilities or share details in public channels until we have completed triage and released a fix.
You should replace security@example.com with your actual security contact address or reporting channel (for example, a real security mailbox, a private issue tracker link, or a disclosure program URL). If you use a specific SLA or different timelines, adjust the response and update cadence in the “Our Response Process” section accordingly so it reflects your real process.
Original comment in English
🚨 suggestion (security): Customize the vulnerability reporting section with concrete instructions.
This still reads like author-facing placeholder text. Please replace it with your actual reporting channel (security email, issue tracker, disclosure program), expected response timelines, and what reporters can expect during triage and resolution so the policy is directly usable.
Suggested implementation:
## Reporting a Vulnerability
If you believe you have found a security vulnerability in this project, please report it to us privately so we can investigate and fix the issue before it becomes public.
### How to Report
Please send a detailed report to:
- Email: `security@example.com`
- Subject line: `Security report: <short description>`
Your report should include (when possible):
- A description of the issue and the affected component(s) or endpoint(s)
- Steps to reproduce the issue (proof-of-concept code, requests, or configuration)
- Any relevant logs, screenshots, or impact assessment
- Your operating system, runtime, and version information
- Any known workarounds
If you believe the issue is especially sensitive (e.g., leads to immediate compromise of user data or infrastructure), please indicate this clearly in your report so we can prioritize it appropriately.
### Our Response Process
We aim to:
- Acknowledge receipt of your report within **3 business days**
- Provide an initial assessment or follow-up questions within **7 business days**
- Keep you informed of the triage status at least every **14 days** until resolution
During triage we will:
1. Validate the vulnerability and assess its impact and severity.
2. Determine the affected versions and whether a fix or mitigation is required.
3. Prepare patches, tests, and release notes as needed.
### Disclosure and Credit
Once a fix is available:
- We will coordinate a disclosure timeline with you, when possible.
- We will include a note in the release notes and/or security advisories describing the issue in general terms (impact, affected versions, mitigation).
- If you would like to be credited, we will acknowledge you as the reporter in the advisory and/or changelog (unless you prefer to remain anonymous).
Please do **not** open public issues for security vulnerabilities or share details in public channels until we have completed triage and released a fix.
You should replace security@example.com with your actual security contact address or reporting channel (for example, a real security mailbox, a private issue tracker link, or a disclosure program URL). If you use a specific SLA or different timelines, adjust the response and update cadence in the “Our Response Process” section accordingly so it reflects your real process.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
David Lanz te informa sobre su Política de Privacidad respecto del tratamiento y protección de los datos de carácter personal de los usuarios y clientes que puedan ser recabados por la navegación o contratación de servicios a través del sitio Web https://github.com/DavidLanz239.
En este sentido, el Titular garantiza el cumplimiento de la normativa vigente en materia de protección de datos personales, reflejada en la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y de Garantía de Derechos Digitales (LOPD GDD). Cumple también con el Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016 relativo a la protección de las personas físicas (RGPD).
El uso de sitio Web implica la aceptación de esta Política de Privacidad así como las condiciones incluidas en el Aviso Legal.
Summary by Sourcery
Documentación:
SECURITY.mddescribiendo las versiones compatibles para actualizaciones de seguridad e instrucciones para informar sobre vulnerabilidades.Original summary in English
Summary by Sourcery
Documentation: