Legal

Security Policy

Last updated:

Security is a priority. If you discover a vulnerability in KubeBolt or in any of our services, we want to know. This page describes how to report it responsibly, what you can expect from us, and what we do on our side.

1. How to report

Send the details to hello@kubebolt.io with the subject line [security]. Please include:

  • A description of the issue and its potential impact.
  • Steps to reproduce it (URLs, payloads, conditions).
  • Affected version, where it applies to the open source product or the agent.
  • Your name or handle, optional, if you want public credit after the fix.

We'll ask you not to disclose publicly until we've had reasonable time to fix it.

2. Response times

Our commitment:

  • Acknowledgement: within 72 hours.
  • Initial triage and validation: within 7 days.
  • Time to patch: proportional to severity. Critical ≤ 14 days, high ≤ 30 days, medium ≤ 90 days.
  • Coordinated disclosure: we agree a publication date with you after the fix, up to 90 days from the report.

3. Scope

In scope:

  • kubebolt.io (this site) and all its subdomains.
  • app.kubebolt.io, the KubeBolt Cloud application.
  • agent.kubebolt.io, the front door the agent connects to from your cluster.
  • The site's public APIs: release-updates signup, the feedback form and its attachment upload, and the Kobi assistant.
  • The open source repository github.com/clm-cloud-solutions/kubebolt and the official artifacts (Helm, Docker, GHCR, Homebrew, krew).

On customer clusters: they are out of testing scope. Do not attack them, not even to demonstrate a finding. If you believe you have found a path to another organization's cluster, stop there and describe it to us: we will reproduce it ourselves in an environment of our own.

4. Out of scope

We don't consider these vulnerabilities:

  • Denial of service, or anything requiring abnormal traffic volume.
  • Client-side configuration issues outside our control (DNS, ISP, browser).
  • Lax SPF or DMARC on domains we don't send mail from.
  • Version banners in HTTP responses.
  • Reports produced solely by automated scanners without demonstrated impact.
  • Third-party dependency vulnerabilities that already have a public CVE and a pending upstream fix.
  • Social engineering, phishing our team, or physical intrusion.

5. Rules of engagement

When researching vulnerabilities, please:

  • Don't access other users' data. If you find a way, demonstrate it with your own test data and tell us immediately.
  • Don't degrade or disrupt the service. No load testing, no mass deletes, no hammering the rate limits.
  • Don't exfiltrate or disclose private data you accessed accidentally; delete it and notify us.
  • Comply with applicable law.

If you act in good faith following these rules, we won't take legal action against you for the report, nor cooperate with authorities to pursue you (safe harbor).

6. Which versions we patch

Worth stating plainly, because it changes what you can expect depending on how you run KubeBolt:

  • KubeBolt Cloud: we patch it. Nothing for you to do, and no old versions exposed.
  • Open source and self-hosted: security fixes ship in the latest release of the current line. We do not backport to earlier lines today: if you run an old version, the fix path is to upgrade. We say so because a disclosure policy that never states what gets patched is incomplete.
  • The agent follows its own release line and the same rule.

7. What we do on our side

Responsible disclosure is half a bargain. Here is our half, and all of it is verifiable in the public repository:

  • Images and charts signed with cosign on every release, so you can verify the provenance of what you deploy.
  • CycloneDX SBOMs per image, attached to every published release.
  • Trivy image scanning on every pull request, before anything gets tagged.
  • CodeQL static analysis across the product's code.

8. If the breach is ours

If we are the ones who suffer a security incident affecting your data, we will tell you without undue delay and in any case within 72 hours of becoming aware, with what we know at that point: what happened, which data is involved, what we are doing, and what we recommend you do. If we don't know everything at first, we will tell you in stages rather than wait for the full picture. As a processor, we notify the controller within the window the GDPR requires.

9. Credit

After the fix, we can credit you publicly in the release notes, if you want us to. We don't currently offer a paid bug-bounty program; we'll evaluate it as the user base grows.

10. Encrypting your report

If you'd rather encrypt your report with PGP, write to us first requesting our current public key. We're working on publishing a stable key in an upcoming iteration. This section is only about the email you send us: encryption inside the product, in transit and at rest, is on the Trust page.

11. Contact

hello@kubebolt.io · subject [security]

If you're not here to report a bug: the product's technical posture (what leaves your cluster, what never does, isolation and audit) is on Trust; the handling of personal data is in the Privacy Policy; and published advisories are on GitHub.