| Version | Supported |
|---|---|
| 0.4.x (the current released line) | ✅ Security fixes |
| 1.0.x (incl. release candidates) | ✅ Security fixes, once 1.0 ships |
| < 0.4 | ❌ Superseded; upgrade to the current line |
Security fixes land on the newest released line only — today that is 0.4.x, and it becomes 1.0.x when 1.0 ships. The full support boundary — platforms, architectures, deployment modes and browsers — is in the 1.0.0 support contract; a deployment mode listed there as unsupported is also out of scope for a security fix.
Report privately through GitHub: Security → Report a vulnerability
Please do not open a public issue for a security report.
Include where practical: affected version (cb version), the deployment mode
— native or mono, the two modes that ship, as defined in the
installation overview — and the
install method you used (quick install, Proxmox LXC, Docker Compose, single
Docker container, or from source), reproduction steps, impact, and whether the
issue is reachable without authentication.
Redact secrets from any log or cb doctor output you attach.
| Stage | Target |
|---|---|
| Acknowledgement | 3 business days |
| Initial assessment | 10 business days |
| Fix or mitigation plan for a confirmed high-impact issue | 30 days |
This is a self-hosted project maintained by a small team; the targets above are what we aim for, not a contractual SLA. We will credit reporters in the release notes unless you ask us not to.
In scope: the server (API, workers, web UI), cb-agent, the installers and
packaging, and the published container images.
Out of scope: findings that require an already-compromised host or database; denial of service by resource exhaustion on a self-hosted deployment the reporter controls; missing hardening headers with no demonstrated impact; exposing the deployment directly to the internet, which the support contract already documents as unsupported.
Every release ships SBOMs (CycloneDX and SPDX, generated with syft) and a
SHA256SUMS file that covers every other file attached to the release,
including the SBOMs. From 0.4.7, every release also publishes SHA256SUMS.sig,
an Ed25519 signature over SHA256SUMS that install.sh verifies before it
trusts any hash. The container image is signed keylessly with cosign with its
SBOM attached to the image. GPG detached signatures (.asc) are produced only
when the release workflow has a GPG key available; check for the .asc files on
the release before relying on one. Verification steps, including how to check
SHA256SUMS.sig by hand, are in the
security verification checklist.