Skip to content

Create SECURITY.md for security policy #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
DavidLanz239 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Create SECURITY.md for security policy #2

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Security Policy

## Supported Versions

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: |

## 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.
Comment on lines +17 to +21
Copy link

@sourcery-ai sourcery-ai bot Dec 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚨 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.

Loading