Security & data handling

Security writing is easy to inflate, so this page is deliberately concrete: it describes the specific controls BugBrain actually has, control by control, in plain language. We'd rather tell you exactly what protects your data than wave at a logo. Up front, and importantly: BugBrain is not SOC 2 certified, and we make no certification claims. What follows are real, implemented technical controls.

Secrets are encrypted at rest#

To test signed-in areas of your app and to push results to your tools, BugBrain has to store some sensitive material — your app's login credentials and your integration secrets (API tokens for Jira, Slack, and the like).

These are encrypted at rest using AES-256-GCM, a strong, authenticated encryption standard. "At rest" means the values are encrypted before they're written to the database, so what's stored is ciphertext, not the original secret. "Authenticated" means the encryption also detects tampering. The secrets are decrypted only at the moment a run or an integration genuinely needs them, and the encryption supports key rotation so keys can be rolled over time.

Strict multi-tenant isolation#

BugBrain is multi-tenant: many organizations share the same system. The most important guarantee is that your organization's data is yours alone, and isolation is enforced at the data layer rather than left to individual queries to remember.

Every tenant-scoped query is automatically constrained to the organization making it — reads are filtered to your organization, and writes are stamped with it — by the data access layer itself. A query that forgets to scope itself doesn't quietly leak across organizations; it's rejected. This "secure by default" design means a developer can't accidentally expose one customer's data to another, because the isolation isn't something each query opts into — it's something the platform enforces underneath every query.

Operator access for support follows the same principle: when an authorized operator needs to help, they act within your organization's normal scoping (impersonation), not by bypassing it, and such access is individually attributable.

SSRF guards on outbound requests#

BugBrain makes outbound network requests on your behalf — delivering webhooks and calling integration endpoints. Any feature that fetches a URL you provide is a potential target for SSRF (server-side request forgery), where an attacker tries to point the server at internal or private systems it shouldn't touch.

Every outbound request passes through SSRF guards that block attempts to reach private, internal, or otherwise unsafe network addresses. For webhooks the check happens twice — once when you register the URL and again, authoritatively, at delivery time by resolving the address — which defeats DNS-rebinding tricks where a hostname looks safe at registration but points somewhere dangerous later.

Sensitive fields redacted from logs#

Logs are invaluable for operating a service and a classic place for secrets to leak by accident. BugBrain's logging redacts sensitive fields before anything is written. Authorization headers and cookies, passwords, tokens and API keys, encryption material (ciphertext, initialization vectors, authentication tags), one-time codes, and the secrets behind integrations and webhooks are all stripped from log output. So even a verbose debug log doesn't carry your credentials in the clear.

Related#