# Security Policy
## Supported Versions
We release security fixes only for the **latest stable version** of this project.
If you are using an older version, please upgrade to the latest release.
| Version | Supported |
| -------- | --------- |
| Latest | Yes |
| < Latest | No |
*Exception:* Critical vulnerabilities may be backported to the last minor release - contact us to discuss.
## Reporting a Vulnerability
**Do not open a public issue / work item** for security vulnerabilities.
Please report them privately to: **vi.is.chapmann@gmail.com**
### What to include
- A clear description of the vulnerability and its potential impact.
- Steps to reproduce (code, commands, environment).
- Suggested fix (if you have one).
- Your preferred credit/acknowledgment (name, GitHub handle, etc.).
### Expected response timeline
- **Initial acknowledgment** within **48 hours** (business days).
- **Preliminary assessment** within **5–7 days** (will the issue be accepted, rejected, or need clarification?).
- **Fix released** within **30 days** for confirmed high/critical severity issues (depending on complexity).
We will keep you updated on the progress.
## Preferred Languages
We prefer to receive reports in **English**, but other languages are acceptable – we will translate.
## Disclosure Policy
Once a fix is ready:
1. We will prepare a patch for the latest version.
2. A new version will be released with a changelog entry that **does not** reveal the vulnerability details (e.g., "Security fix").
3. After the release, we will publish a security advisory and credit the reporter (unless you request anonymity).
4. Full details (CVE, if assigned) will be disclosed **30 days after release** to give users time to upgrade.
## Dependencies
Keep in mind: This project may depend on third‑party libraries. They also can have vulnerabilities.
If you discover a vulnerability in a dependency that affects this project, please report it using the same process above.
## Security Best Practices for Contributors
- Never commit secrets (API keys, passwords, private keys). Use environment variables or secret management.
- Validate all external input.
- Avoid unsafe operations (e.g., `eval()`, `unsafe` blocks without justification, raw pointer arithmetic without bounds checking).
- For native code (C/Rust/assembly): be mindful of buffer overflows, use‑after‑free, and integer overflows.
## Out‑of‑Scope
The following are **not** considered security vulnerabilities for this project:
- DoS attacks that require unrealistic resources or admin privileges.
- Vulnerabilities in outdated versions that are no longer supported.
- Issues that require physical access or already compromised environment.
When in doubt, report it – we prefer false positives over missed issues.
## Contact
**Security contact:** vi.is.chapmann@gmail.com