Can you hide a backdoor in open source?

A client asked me, entirely reasonably, how he could know that the server I had just set up was not sending his files somewhere. It is the right question to ask a supplier, and the honest answer is not "trust me" — it is a description of what he can check and what he cannot.

What I told him is the subject of this article, and it is narrower than the usual claim about open source. "Nobody can hide a backdoor in open code" is not true. What is true is more specific, and more useful.

Two different questions about trust

When you install closed software you are answering one question: do I trust the company that made this? There is no second option, because there is nothing to examine. The entire relationship rests on reputation, contracts and regulatory pressure — which are real things that mostly work, and which are also entirely external to the software itself.

With open code there is a second question available: does anybody who is not the vendor have the ability to check? That question can be answered yes even when nobody has actually looked, and the difference between "nobody looked" and "nobody could look" is the whole of what openness buys.

I want to state that as plainly as I can, because the overstated version of this argument does real damage. Open code is not automatically examined. Most of it is never read by anybody outside the project. What openness changes is the structure of the situation: the number of possible auditors goes from one to unbounded, and the cost of hiding something goes from nothing to permanent risk of discovery.

What the record actually shows

In 2024 somebody spent roughly two years building trust in a small, widely used compression library, became its co-maintainer, and inserted a backdoor that would have given remote access to an enormous number of servers. It was caught days before it reached the systems most people run — by one engineer who noticed that a login was taking a fraction of a second longer than it should and would not let it go.

That story is used as evidence by both sides, which is a sign it is being read carelessly. Take the uncomfortable half first: a determined, patient, well-resourced attacker did get a backdoor into open source, through the human process rather than the technical one, and the community's review did not catch it. Anyone claiming this cannot happen has been contradicted by events.

Now the other half, which is the part that convinced me. It was found. By an outsider, without permission from anybody, because he could read the code and run the experiments. The attack was reconstructed publicly within days, every affected system was identified, and the fix was distributed globally in under a week. Ask what the equivalent sequence would look like in closed software and the answer is uncomfortable: the same backdoor, inserted by an employee, would be found by the vendor's internal review or not at all, and disclosed on the vendor's own schedule.

The honest limits

Three, and they matter to anyone making a decision rather than an argument.

Reading the source tells you about the source, not about the program running on your machine. Unless you compiled it yourself, you are trusting whoever built and packaged it. This gap is real and is being closed by reproducible builds — a way of verifying that a given source produces exactly the binary you were given — but it is not closed everywhere yet.

Attention is not evenly distributed. Widely used projects with corporate users get serious scrutiny. The small library three levels down, maintained by one person in their spare time, gets almost none — and that is precisely where the 2024 attack went, because the attacker understood the distribution better than the community did.

And openness says nothing about competence. Code anybody can read can still be badly written, and has been, spectacularly and at scale. Transparency is a property of the process, not a guarantee about the result.

What I told the client

Not that his server cannot be compromised. That would be a lie and he would have been right to distrust it.

What I told him is that he does not have to take my word for whether it is sending his files anywhere, because he can watch. Point the network at a DNS server he controls and look at what the machine asks for. That check requires no trust in me, no permission from anybody, and no ability to read code. It takes an evening and it answers the actual question he was asking.

That is the version of this argument I am prepared to defend. Not zero backdoors — nobody can promise that. A system where the person who bought the thing can verify the claim independently, and where the supplier knows it. I would rather sell under those conditions than under ones where my customer's only option is to believe me.