Many Eyes, If Someone Looks.

Open source got its most quoted security argument from Eric Raymond's essay The Cathedral and the Bazaar. He wrote that "given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone," and then shortened it to "Given enough eyeballs, all bugs are shallow." He named it Linus's Law.

It's a good line. It's also a conditional, and people tend to drop the condition. The law says nothing about code nobody reads. It assumes the eyeballs show up.

Heartbleed is what happens when they don't. The bug went into OpenSSL in December 2011 and shipped with version 1.0.1 on March 14, 2012. OpenSSL's advisory of 7 April 2014 described it in one sentence: "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory." In practice, that memory could hold private keys, usernames, passwords and other traffic, and reading it left no trace in the logs. For more than two years the flawed code sat in a public repository that anyone in the world could have read. Very few people were being paid to.

A few days after disclosure, Steve Marquess of the OpenSSL Software Foundation wrote that the foundation "typically receives about US$2000 a year in outright donations" and that a single team member worked on OpenSSL without a conventional full-time job elsewhere. He asked for "at least a half dozen full time OpenSSL team members, not just one." Code that servers everywhere depended on had, in theory, any number of potential reviewers. In practice it had a handful of people working on it in their spare time.

The response came fast. The Linux Foundation said Heartbleed "was the galvanizing force" behind its Core Infrastructure Initiative, and by the end of May 2014 the initiative had committed to fund two full-time OpenSSL core developers and a security audit of the OpenSSL code base by the Open Crypto Audit Project. Look at what changed. The code had been open all along. What it got after the crisis was money and people whose job was to look at it.

So the open-source security argument is misstated rather than wrong. Being open doesn't make code safe. What openness buys is verifiability: the ability for anyone, not only the author, to check. Cryptographers settled this a long time ago. Auguste Kerckhoffs wrote in 1883 that a cipher system "must not require secrecy and can be stolen by the enemy without causing trouble." NIST applies the same idea to ordinary servers: its guide to general server security lists "Open Design" as a principle, stating that "System security should not depend on the secrecy of the implementation or its components." Closed software has bugs too. Fewer people are allowed to look for them, and everyone else has to take the vendor's word for what was found.

The looking is also getting cheaper, which makes the case stronger. Google's OSS-Fuzz says that as of May 2025 it had helped identify and fix over 13,000 vulnerabilities and 50,000 bugs across 1,000 projects. OpenSSF Scorecard runs automated checks on open projects for things like branch protection, code review, pinned dependencies and signed releases, and publishes a weekly scan of the 1 million most critical open source projects as a public dataset. Tools like these find only certain kinds of problems, and they never get tired. You can't point either of them at code you aren't allowed to see.

OSS-Fuzz, as of May 2025

vulnerabilities found and fixed

13,000+

vulnerabilities found and fixed

bugs found and fixed

50,000

bugs found and fixed

open-source projects covered

1,000

open-source projects covered

Then there is a gap people forget about: the code someone audited and the binary you actually run may not match. Reproducible builds close it. A build is reproducible if, given the same source code, build environment and build instructions, "any party can recreate bit-by-bit identical copies of all specified artifacts." That lets anyone confirm that what is running came from what was reviewed. A closed vendor can't offer this, because the source is the part you don't get.

Machines aside, people still have to read the code, and when they do, the results can be shared. An audit of Git organized by the Open Source Technology Improvement Fund, carried out by X41 and GitLab researchers with funding from Google's open-source security team, turned up 35 issues, including two critical and one high-severity finding, and the full report was published in January 2023. For protocols the same goes for academic scrutiny. A team of academic cryptographers published a formal security analysis of the Signal messaging protocol, proving the security of its key exchange core in their model and finding no major design flaws. Both pieces of work depended on open code and open designs, and both left something on the public record that anyone can check later.

This is where the argument matters for people outside the security industry. A city running open-source software for its permits or its data portal can commission an independent audit of that code and publish the report. Every other city running the same software benefits from that one invoice, and so does any resident who wants to read it. A newsroom protecting its sources, or an NGO holding data about vulnerable people, can do the same for the tools it depends on. With closed software the most any of them can get is the vendor's assurance, sometimes a summary under NDA. They can't choose who does the review, and they can't share what the reviewer found.

None of this happens on its own. Open code nobody reviews is exactly as unexamined as closed code, and attackers can read it too. Heartbleed was that case, out in public, for two years. The permission to look is worth something only when somebody uses it, and someone has to pay for that time.