# Security Policy

## Supported Versions

The following versions are currently supported with security updates:

| Version | Supported |
| --- | --- |
| 1.x | Yes |
| < 1.0 | No |

## Reporting a Vulnerability

Please do not report security vulnerabilities in public issues.

Preferred process:

1. Use private vulnerability reporting on the hosting platform (for example, GitHub Security Advisories).
2. If private reporting is not available, contact project maintainers directly through a private channel.
3. Include `[SECURITY]` in the title.

## What to Include in a Report

Please include as much of the following as possible:

- affected component and file path
- affected version or commit hash
- reproduction steps
- proof of concept (minimal, safe)
- impact assessment (confidentiality, integrity, availability)
- any suggested remediation

## Response Timeline Targets

Maintainers will try to follow these targets:

- acknowledgment: within 72 hours
- triage decision: within 7 days
- fix plan or mitigation guidance: as soon as practical after triage

Complex issues may require more time. Status updates will be shared privately during handling.

## Disclosure Policy

- Vulnerability details stay private until a fix or mitigation is available.
- After a fix is released, coordinated public disclosure is encouraged.
- Credit will be given to reporters unless anonymity is requested.

## Out of Scope

The following are typically out of scope unless they create a concrete security impact:

- style or formatting issues
- non-exploitable crashes
- vulnerabilities in unsupported versions

## Researcher Safe Harbor

If you act in good faith, avoid privacy violations, avoid service disruption, and do not exfiltrate data, the project will treat your research as authorized under this policy.
