We take the security of rhizome seriously and appreciate responsible reports from the community.
Only the latest minor release receives security fixes. Older minor lines are best-effort.
| Version | Supported |
|---|---|
| 0.3.x | ✅ active support |
| < 0.3 | ❌ no support |
Please do not open a public GitHub issue for security reports.
Email maxbarsukov@bk.ru with the subject prefix
[rhizome:security]. Include, at a minimum:
- A description of the issue and its impact.
- The version (release tag or commit SHA) you reproduced it on.
- Steps or a proof-of-concept that demonstrates the problem.
- Any mitigations or workarounds you've already identified.
If you would like the report encrypted, ask in your first message and we'll exchange a key out-of-band.
| Step | Target time |
|---|---|
| Acknowledgement of report | within 7 days |
| First substantive response | within 14 days |
| Fix or mitigation available | within 30 days |
| Coordinated public disclosure | 90 days by default, sooner if mutually agreed |
We will keep you informed throughout the process, credit you in the release notes if you wish, and coordinate the disclosure timeline with you.
These are not considered vulnerabilities for the purposes of this policy:
- Findings produced exclusively by automated scanners without an underlying exploit primitive.
- Theoretical timing or side-channel attacks on operations whose inputs are entirely controlled by the same trust boundary.
- Denial of service through resource exhaustion when the operator
has not configured the rate-limiting / quota controls documented in
docs/deployment.md. - Issues in third-party dependencies that already have an upstream fix; please report those upstream and we will bump the dependency.
For production deployments, please follow the operational guidance in
docs/deployment.md (mandatory mTLS between every internal hop,
per-tenant ABAC policies, PKI rotation cadence, and the audit-log
retention window).