Vulnerability disclosure policy
If you find a security problem in CloudRING, I want to hear about it. This page explains what's in scope, how to report and what to expect.
How to report
The reporting address and what to leave out of a report are the same as in SECURITY.md. This page adds the scope and what to expect.
Email yuri@trukhin.com. Please don’t report a vulnerability in a public issue.
A good report names the affected component, the impact you expect, the steps to reproduce and any safe, synthetic evidence. Don’t include secrets, tenant data, private endpoints, cookies, kubeconfigs or exploit material beyond what’s needed to describe the problem.
What’s in scope
- The code and contracts in opencloudtech/CloudRING, on the main branch and in published releases.
- This website, cloudring.org.
Other cloudring.org hosts are out of scope. If you notice a problem there, tell me, but don’t test or scan them.
Out of scope: denial-of-service testing, social engineering, physical attacks and problems in third-party services the project doesn’t run.
When you test
- Test against your own installation and synthetic data.
- Don’t access, change or delete data that isn’t yours. If you come across personal data or credentials, stop and report it.
- Give the project a reasonable chance to fix a problem before you share the details publicly.
What happens next
I’ll reply to your report. When a fix is released, I’ll publish a GitHub Security Advisory and credit you if you’d like.
There’s no paid bug bounty.