# Security Policy
## Detection
Before a report reaches us, CI scans dependencies with
[cargo-deny](https://github.com/EmbarkStudios/cargo-deny) against the [RustSec advisory
database](https://rustsec.org/) on every pull request, every push to `main`, and nightly. The
configuration is [`deny.toml`](deny.toml); how to run the gate locally, and how to triage a
newly-published advisory, is in
[docs/testing.md](docs/testing.md#dependency-advisory-gate). The gate audits the committed
`Cargo.lock` (`--locked`) and fetches the RustSec database on every run, so an unreachable
database fails the check rather than passing it quietly. An advisory that cannot be fixed by a compatible
`cargo update` is recorded in `deny.toml` with its ID, a reason and the upstream blocker, so
ignored risk is written down rather than forgotten — the list is currently empty, and an `ignore`
row that stops matching fails the gate (`unused-ignored-advisory = "deny"`).
This covers the dependency graph only. Vulnerabilities in vipune's own code are not detected
automatically — please report them as described below.
## Reporting a Vulnerability
**Do NOT report security vulnerabilities via public GitHub Issues.**
Use GitHub Security Advisories for private reporting:
https://github.com/randomm/vipune/security/advisories/new
This ensures responsible disclosure and gives maintainers time to address the issue before public announcement.
If you cannot access GitHub Advisories, check the repository profile for additional contact information.
## What to Include
When reporting a vulnerability, include:
- **Description**: What is the vulnerability?
- **Steps to Reproduce**: How can it be triggered?
- **Impact**: What could an attacker do? Is it exploitable in practice?
- **Affected Versions**: Which versions of vipune are affected?
- **Suggested Fix** (optional): Do you have a fix in mind?
## Response Timeline
vipune is an open-source project maintained on a best-effort basis.
We will:
- **Acknowledge** your report within 7 days (where possible)
- **Assess** the vulnerability's impact and urgency
- **Work** on a fix in coordination with you
- **Publish** a security advisory once a fix is released
Response time depends on maintainer availability and issue complexity. For critical vulnerabilities (CVSS 9.0+), we aim for expedited handling.
## Public Disclosure
Once a patch is ready:
1. Release a new version with the security fix
2. Allow users **30 days** from release to upgrade before public announcement
3. Publish a public security advisory describing the vulnerability
4. Credit the reporter (unless requested otherwise)
This embargo period gives users time to patch before attackers learn of the issue.
---
Thank you for helping keep vipune secure.