Is open code safer than closed?

"If nobody can see how it works, nobody can break it." I have heard versions of this from people selling security products, and it survives because it sounds like common sense. It is also the single idea that the last twenty years of security research has spent most of its energy demolishing, and the demolition is worth understanding because the reasoning transfers well beyond software.

The principle it violates is older than computers

In the nineteenth century a Dutch cryptographer stated a rule about military ciphers that has held ever since: a system should remain secure even if everything about it except the key is public knowledge.

The reasoning is practical rather than philosophical. Secrets about how a system works are held by many people, written in documentation, embedded in devices that can be captured, and known to former employees. Those secrets leak, eventually, always. A key can be changed in an afternoon; a design cannot. So you build your security on the thing that can be replaced, not on the thing that cannot.

This is why every encryption standard used by banks, governments and your phone is public. The algorithms are published, analysed by hostile experts for years, and standardised only after surviving that. Nobody keeps the design secret, because a design that needs to stay secret to work has already told you what its weakness is.

What the evidence actually says about open code

Here is where I part company with the enthusiastic version of this argument, because the record does not support the stronger claim.

In 2014 a flaw in an open encryption library exposed a substantial fraction of the internet's servers for two years before anybody noticed. The code was public the entire time. "Given enough eyes, all bugs are shallow" turned out to depend rather heavily on the eyes actually being there, and in that case they were not — the component was critical infrastructure maintained by a very small number of people.

So openness does not automatically produce scrutiny. Anybody claiming otherwise is arguing from a slogan rather than from what happened.

But watch what happened next, because that is the part the slogan gets right for the wrong reason. The flaw was found by outside researchers, published in full, analysed publicly within hours, and patched globally within days. Every administrator could determine whether they were affected by reading the code. And the incident produced permanent structural change: funding programmes for critical infrastructure, formal audits of components everybody depends on, the whole apparatus that now exists because that failure was visible enough to embarrass the industry into building it.

The comparison that actually matters

Not "which has fewer bugs" — both have plenty, and the counts are not comparable because one of them publishes and one does not. The useful comparison is what happens between the bug existing and the bug being fixed.

In open code: anybody can find it, anybody can verify the fix, anybody can check whether their own system is affected, and the whole sequence happens in public on a timeline nobody controls.

In closed code: the vendor finds it or an outsider reports it, the vendor decides the severity, the vendor decides when to fix it, the vendor decides what to tell you and when. Those are four decisions made by a party whose interests include not looking bad. Frequently they behave well. The point is that you are relying on it.

There is also an asymmetry people miss. Obscurity does not stop an attacker, it only slows one down — and it slows down the wrong ones. A serious adversary disassembles the product, which is standard practice and entirely feasible. What obscurity actually prevents is examination by researchers, customers and competitors: the people who would tell you. It is a filter that blocks your allies more effectively than your opponents.

Where obscurity does have a use

A qualification, because the absolute version of this position is also wrong.

Not advertising unnecessary detail is sensible. Do not publish your internal network layout, do not list your software versions on a public page, do not make a target easier to describe than it has to be. That is hygiene, and it is worth doing.

The error is treating hygiene as a defence. Moving a service to an unusual port reduces noise in your logs; it protects against nothing, because scanning every port takes seconds. The test is simple and worth applying to any security measure: if an attacker learned this detail, would I still be safe? If yes, it is hygiene and you may keep it. If no, it was never security — it was a secret, and secrets have a shelf life.

Which brings it back to where the argument started. Build on things that survive being known. That is why the encryption is public, why I prefer software whose code my client can read, and why the honest answer to "how do I know this is safe" is never "because you cannot see inside it".