| Version | Supported |
|---|---|
| 1.0.x | Yes |
| 0.56.x | Security fixes only during the v1.0 migration window |
| < 0.56 | No |
If you discover a security vulnerability in Wardex, please report it responsibly.
Do NOT open a public GitHub issue for security vulnerabilities.
- Email security@wardex.dev with a description of the vulnerability, or open a private GitHub Security Advisory.
- Include steps to reproduce, affected versions, and potential impact.
- If possible, include a proof-of-concept or suggested fix.
- Acknowledgement within 48 hours of your report.
- Triage and assessment within 5 business days.
- Fix timeline communicated once the severity is assessed.
- Credit in the release notes (unless you prefer to remain anonymous).
We follow the CVSS v3.1 scoring model:
| Severity | CVSS Score | Response Target |
|---|---|---|
| Critical | 9.0–10.0 | Patch within 48 hours |
| High | 7.0–8.9 | Patch within 7 days |
| Medium | 4.0–6.9 | Patch in next release |
| Low | 0.1–3.9 | Scheduled backlog |
The following are in scope:
- Authentication and authorization bypass
- Remote code execution
- SQL injection or data exfiltration
- Cryptographic weaknesses (token generation, backup encryption, key management)
- Path traversal or file access beyond
var/ - Denial of service via resource exhaustion (rate limiter bypass, memory, disk)
- Cross-site scripting (XSS) in the admin console
- Vulnerabilities in third-party dependencies (report upstream; we monitor via
cargo audit) - Issues requiring physical access to the host
- Social engineering attacks
- Denial of service via network flooding (infrastructure-level concern)
See docs/THREAT_MODEL.md and docs/PRODUCTION_HARDENING.md for details on implemented security controls.
Every tagged release ships a SLSA v1.0 build-provenance attestation and a
CycloneDX SBOM. See docs/REPRODUCIBILITY.md for the
exact gh attestation verify and cosign verify commands to run against
binaries, archives, and container images before deploying them.