Preventing Cross‑Tenant Breaches: How BrunnrDB’s Architecture Contains Attacks Post‑MongoBleed
MongoBleed (CVE-2025-14847) showed how one flaw in a centralized database leaks data across tenants. How per-user sharding and client-side encryption contain the damage.
Vendor Breach Containment: Making Integrations Safe Even When They Get Popped
Vendor breaches are no longer an edge case—they are a primary way attackers bypass your “front door” controls. A single compromised integration can turn into wholesale data access if it relies on long-lived tokens, broad permissions, unmanaged exports, or direct database connectivity. This post turns the “side doors” risk into an actionable containment checklist: minimize what vendors can reach, shorten how long access works, and reduce the value of anything that leaks. You will find practical patterns—an integration gateway, curated exports, kill switches, and tight token scopes—that make stolen vendor access boring and keep blast radius small.
Sharding to Contain the Blast Radius of Data Breaches
Modern SaaS platforms sit on top of massive, multi-tenant data stores. When those stores are breached, the damage is rarely limited to a single record; it is often “wholesale” compromise of large slices of the user base. For a CISO or CTO, this is the critical risk: not that a record can be stolen, but that everything a given system knows becomes available in one incident.
Protecting Data-In-Use in the Cloud: A Pragmatic Philosophy
Once an attacker can read memory, encryption at rest and MFA stop helping. A pragmatic approach to data-in-use: trust the session, not the environment, and assume breach.
Closing the Encryption Gap: Protecting Data While It’s Being Used
Encryption protects data at rest and in transit – but what about when it’s being used?
That’s the missing layer in most security architectures.