The myths and realities of open source software security

Given enough eyeballs, all bugs are shallow. That's Linus's Law, the idea that open source software is inherently more secure because anyone can inspect the code. It's one of the most repeated claims in software, and it contains a critical assumption that rarely gets examined: it assumes the eyeballs show up.

Most of the time, they don't.

The attention problem

The case for open source security starts with transparency. Anyone can read the code. Anyone can find a vulnerability, submit a patch, or flag a concern. For projects like Linux and Kubernetes, backed by institutional funding, staffed by paid maintainers, and scrutinized by thousands of contributors, this model works exceptionally well. These projects have formal security processes, dedicated response teams, and the resources to act fast when something breaks.

But most open source software looks nothing like Linux. Most of it is maintained by one or two people in their spare time, with no budget, no security audit process, and no guarantee that anyone is reviewing pull requests with adversarial thinking. The transparency is there in theory. The attention is not.

This is the gap that Linus's Law doesn't account for. Openness creates the possibility of scrutiny. It doesn't create scrutiny itself. That requires people, time, expertise, and money, all of which are scarce and unevenly distributed across the open source ecosystem.

Two case studies in under-investment

Heartbleed is the clearest example. OpenSSL powers a significant portion of the world's encrypted web traffic. For years, it was maintained by a handful of volunteers operating on a minimal budget. When the Heartbleed vulnerability was disclosed in 2014, it exposed a uncomfortable truth: critical internet infrastructure was running on volunteer labor. The bug wasn't hard to find, it had been sitting in the codebase for over two years. Nobody with the right expertise was looking.

Log4j tells a similar story. Log4Shell, disclosed in late 2021, affected a Java logging library embedded in millions of applications. The vulnerability had existed for years. Log4j was widely used, but "widely used" and "widely reviewed" are not the same thing. Developers pulled it into their dependency trees without thinking about who was maintaining it or whether anyone was auditing it for security flaws.

Both cases are often cited as open source failures. They're better understood as funding failures. The code was open. The investment wasn't there.

Supply chain attacks as a second-order effect

Once you understand that most open source projects are under-watched, the rise of supply chain attacks becomes predictable. Attackers understand the attention economy better than most defenders do.

Instead of targeting well-guarded applications directly, threat actors go after the dependencies, small libraries and packages buried deep in the dependency tree where nobody is looking closely. They insert malicious code into a package that gets pulled into thousands of downstream applications automatically. The openness of the ecosystem, combined with the trust developers place in their dependency chains, creates a wide and largely unmonitored attack surface.

Modern applications routinely depend on hundreds of open source packages, each with their own dependency trees. The surface area is enormous. Tools like Dependabot and Snyk help by flagging known vulnerabilities, but they can't catch a compromised maintainer or a malicious contribution that passes code review in an under-resourced project. The tooling helps at the edges. The core problem is structural.

What actually makes open source secure

When open source security works, it works extremely well, often better than proprietary alternatives. But the variable isn't openness. It's investment.

The projects with strong security track records share common traits: institutional backing, paid maintainers, formal vulnerability disclosure processes, and enough community engagement to sustain genuine code review. Linux has the Linux Foundation. Kubernetes has the CNCF and major corporate sponsors. After Heartbleed, the Core Infrastructure Initiative (now the Open Source Security Foundation) was created specifically to fund critical projects that the market had neglected.

These are the projects where Linus's Law actually holds. Not because the code is open, but because the economics support sustained attention. Transparency is a necessary condition for community-driven security. It is not a sufficient one.

This distinction matters for how organizations evaluate open source dependencies. The question isn't "is this open source or proprietary?" The question is: who maintains this, how is it funded, how quickly do they respond to security disclosures, and is the level of investment proportional to how critical this software is to my stack?

Active communities, frequent commits, responsive maintainers, and institutional support are better security indicators than the license on the repository.

Scaling attention with AI

If the core problem is that human attention can't keep pace with the volume of open source code, AI-assisted security tooling is the most credible attempt at closing that gap. Large language models and machine learning systems can scan codebases continuously, flag anomalous patterns in pull requests, and detect vulnerability classes across thousands of projects simultaneously, without needing funding for a full-time security team on every repo.

This is already happening at scale. Google's OSS-Fuzz project, augmented with AI-driven fuzzing, has identified hundreds of vulnerabilities across critical open source projects that human reviewers missed. GitHub's CodeQL and Copilot Autofix are performing automated vulnerability detection and suggesting remediations directly within pull request workflows. These tools don't replace human judgment, but they provide a layer of continuous scrutiny that most projects could never afford to staff.

For under-resourced maintainers, the ones at the center of the attention problem, AI tooling could be transformative. A solo maintainer who can't afford a security audit can still run AI-assisted static analysis on every commit. That doesn't solve the funding problem, but it meaningfully raises the floor for baseline security across the ecosystem.

The complication is that this dynamic cuts both ways. AI is also accelerating the volume of code entering open source. Developers using code generation tools are contributing more code, faster, and not all of it is being fully reasoned through before it ships. If the existing problem is that maintainers are overwhelmed by the review burden, AI-generated contributions could intensify that pressure, more code entering the pipeline, potentially carrying subtle flaws that look clean on the surface.

Attackers benefit from the same tools. LLMs can help craft more sophisticated malicious contributions, code that passes cursory review, obfuscates its intent, or exploits trust patterns in under-monitored dependency chains. The supply chain attack surface described earlier becomes harder to defend when the quality of adversarial contributions improves.

The honest assessment is that AI doesn't resolve the open source security problem. It reshapes it. Automated tooling raises the ceiling for what well-resourced projects can catch and lowers the barrier for small projects to participate in basic security hygiene. But it also raises the sophistication of threats and increases the volume of code that needs review. The projects that will benefit most are the ones that adopt these tools deliberately, integrating AI-assisted scanning into their workflows rather than treating it as a passive safety net.

The wrong question

The open source security debate is usually framed as a binary: is open source more secure than proprietary software, or less? That framing misses the point entirely. Proprietary software has its own long history of unpatched vulnerabilities, opaque security practices, and slow disclosure timelines. The difference is that when proprietary software fails, you can't see why. When open source fails, the postmortem is public.

The more productive question is whether a given project, open source or otherwise, has the governance, funding, and community to match its level of criticality. A well-funded open source project with active maintainers, a formal security process, and AI-assisted tooling in its pipeline will outperform a proprietary product with a skeleton crew and no external audit. A solo-maintained open source library with no funding will not, though the floor is rising as automated security tools become more accessible.

Open source gives you the transparency to make that judgment. AI tooling is starting to give under-resourced projects the means to act on it. Whether that shifts the economics enough to close the attention gap is the question that will define open source security for the next decade.