Does zero-knowledge encryption protect you against a supply-chain attack?
Partly. Here is the honest answer, stated before the caveats: zero-knowledge encryption protects the server channel. Your keys never leave your device, so a compromised server, a rogue operator, or a subpoena pointed at our infrastructure still only ever sees ciphertext. That guarantee holds even if the attacker owns the backend completely. What zero-knowledge does not protect is the endpoint. If malicious code runs inside the client at the moment of encryption, it can read your files as plaintext before a single byte is encrypted. Encryption happens on your machine; so does the attack. That is the whole problem in one sentence.
So when someone asks "are you safe from a supply chain attack on cloud storage because your clients are open source and end-to-end encrypted?", the precise reply is: the encryption is necessary, and it is not sufficient. The thing that actually defends the client is verifiability. Let me walk through why.
What a supply-chain attack on a storage client actually looks like
A modern application is mostly other people's code. A desktop sync client, a CLI, a web bundle — each pulls in dozens to hundreds of transitive dependencies from npm, crates.io, PyPI, or a distro package mirror. A supply-chain attack doesn't break your front door. It walks in through one of those dependencies.
The patterns are well documented and not hypothetical:
- The 2024 backdoor planted in
xz-utils/liblzma, where a maintainer-trusted contributor slipped obfuscated malicious code into a compression library that thousands of systems link against. It was caught by an engineer noticing a performance anomaly — not by any automated gate. - The 2022
node-ipcsabotage, where a maintainer intentionally shipped destructive behaviour in a widely-depended-on npm package. - The steady drip of malware-laden packages on npm and PyPI — typosquats, dependency-confusion uploads, and hijacked maintainer accounts that publish a poisoned version of an otherwise legitimate library.
The shape is always the same. Code you trusted transitively does something you never authorised. And if that code lands in a storage client, it executes in the one place where your data is briefly in the clear.
Encryption moves the plaintext to exactly one location: your device. A supply-chain attack is the technique for getting code to run on exactly that location.
Why zero-knowledge still matters here
It would be easy to read the above and conclude encryption is theatre. It isn't. Draw the boundary clearly.
beebeeb encrypts every file with AES-256-GCM on your device, and derives and protects keys with Argon2id. The keys are never transmitted to our server. That design eliminates an entire class of attacker in one move: anyone who only has access to the server. A breached database, a malicious insider at the host, a compelled-disclosure order, a backup that leaks from our storage in Falkenstein, Germany — none of them yield plaintext, because the plaintext was never there and neither were the keys. You can read exactly how the key handling works on the security page.
That is a real, hard guarantee, and most of the industry can't make it. But it is a guarantee about where your data is decryptable, and the answer is "only on your endpoint." Which is precisely why the endpoint is the prize.
The part nobody likes to say out loud
No cloud provider can fully eliminate endpoint risk. Not us, not anyone. If attacker-controlled code runs inside the client process during encryption, the model breaks, and it breaks the same way for every E2E product on the market. Anyone who tells you their encryption makes them immune to a poisoned dependency is either confused or selling something.
What a provider can do is shrink the attack surface and — more importantly — make the client verifiable, so that a poisoned build has somewhere to be caught before it reaches you. That is the actual defence. It is less glamorous than "military encryption," and it is the part that does the work.
The real mitigations against client supply-chain risk
1. Open-source clients
If the source of the thing encrypting your files is public, anyone can read what shipped. A maintainer can be compromised; a closed binary cannot be independently inspected at all. Our product clients — the core encryption library, the CLI, the web app, and the mobile and desktop clients — are open source. (Our server is not, and we don't pretend otherwise; the server only ever holds ciphertext, so its source is not what protects your data.) Open source is not a guarantee that code is safe. It is the precondition that makes catching a problem possible. The xz backdoor was found because the code and the build were out in the open.
2. Reproducible, verifiable builds
Public source only helps if the binary you run is actually built from that source. A reproducible build lets an independent party compile the published source and get a byte-for-byte identical artifact — which means a tampered build, injected somewhere between commit and download, shows up as a hash mismatch. This is the difference between "trust us, this is what the code does" and "here, check for yourself." It is the single highest-leverage control against a poisoned client, and it is on our roadmap.
3. Dependency pinning, lockfiles, and auditing
Pin every dependency to an exact version with a committed lockfile, so an upstream maintainer can't silently push a new release into your build. Audit the tree — cargo audit for Rust, advisory scanning for the JS bundle — and watch for sudden maintainer changes or unexplained new transitive deps. None of this is exciting. All of it is the boring, continuous hygiene that catches the dependency-confusion and account-hijack class of attack.
4. A minimal dependency surface
The cheapest dependency to audit is the one you never added. Every crate and every npm package is a maintainer you are trusting and a transitive tree you now own. Keeping the surface small — especially in the core that touches keys and plaintext — is a security decision, not just a tidiness one. You can see what we're shipping and where it's going on the features page.
Where that leaves you
Put the controls in a table, because the boundaries matter more than the marketing.
| Threat | Does zero-knowledge encryption stop it? | What actually stops it |
|---|---|---|
| Server breach / rogue operator / legal compulsion | Yes — server only holds ciphertext, keys never sent | Client-side AES-256-GCM, Argon2id, keys stay on device |
| Network interception in transit | Yes — payload already encrypted before it leaves | Client-side encryption + transport security |
| Poisoned dependency in the client | No — runs at the endpoint, before encryption | Open source + reproducible builds + pinned, audited, minimal deps |
| Malware already on your machine | No | Endpoint hygiene; no provider can fully remove this |
The honest takeaway is uncomfortable for a marketing page and correct anyway: encryption protects the channel, verifiability protects the client, and nothing protects an endpoint that is already owned. We built our clients open source for the second column — not as a branding exercise, but because it is the only thing that lets a poisoned build get caught before it reaches you. We'd rather tell you where the line is than pretend there isn't one.
beebeeb is operated by Initlabs B.V. (KvK 95157565) in the Netherlands, with data stored in Falkenstein, Germany. An independent audit of our clients is planned. When it's done, we'll say so — and not before.