Security Policy

We take security reports seriously. If you've found a vulnerability in DollarBox, please tell us before telling anyone else.

How to report

Email security@dollarbox.dev with:

• A clear description of the issue.
• The exact steps to reproduce it.
• The impact you believe it has.
• Anything else that would help us fix it quickly (logs, payloads, screenshots).

PGP is not required. If you'd like an encrypted channel, say so in the first email and we'll arrange one.

We aim to acknowledge reports within 3 business days and to land a fix or have a credible mitigation in place within 90 days of acknowledgement. If a report needs longer, we'll say so and explain why.

Please do not file public issues, post on social media, or otherwise disclose the vulnerability during the 90-day window. After a fix ships we're happy for you to write it up.

Scope

In scope:

• dollarbox.dev and app.dollarbox.dev.
• The control panel.
• Tenant isolation between organisations: any way for one organisation to read, modify, or interfere with another.
• Billing integrity: any way to provision capacity without paying for it, or to be charged for capacity you didn't request.
• Persistent volume isolation and deletion semantics: any way to read another tenant's volume data, or for deleted volume bytes to leak to another tenant's freshly-provisioned volume.

Out of scope:

• Content of containers users themselves deploy. That code is their responsibility.
• Volumetric denial of service against shared infrastructure.
• Social engineering of DollarBox staff or users.
• Findings against third-party services we depend on (Stripe, Migadu, Cloudflare, the upstream k3s/Kubernetes projects) — please report those to the relevant vendor.
• Missing best-practice HTTP headers with no demonstrated impact.

No bug bounty (yet)

We don't run a paid bug bounty programme at this stage. We do publicly credit reporters who'd like to be named, below, once their report has been fixed and disclosed.

Hall of fame

Empty for now. Be the first.