The Return of the Open Source Debate

I was reading a recent Obsidian blog post about securing third party plugins when I was reminded of something that often gets overlooked. Obsidian itself is closed source.

Instead of the core application being open to inspection, the most exposed and dynamic part of the ecosystem becomes the plugin layer. And that is where things get interesting from a security perspective.

Because even if the core product is not publicly auditable, the plugin ecosystem often is. Many plugins are open source, often maintained by one contributor, and integrated deeply into user workflows. This creates a classic supply chain risk pattern. The trust boundary moves away from the core application and into a much broader and less controlled ecosystem of extensions.

Security Evergreen

For decades, the open source versus closed source security debate followed a familiar playbook.

Open source advocates argued that transparency improves security because anyone can inspect the code and identify flaws. Supporters of closed source software countered that attackers cannot exploit what they cannot see (or at least not so easily).

The rise of powerful LLMs is challenging these assumptions and re-opens the disuccsion with another aspect.

Today, models such as Claude, GPT, and specialized security-focused AI systems can review thousands of lines of code in minutes. They can identify insecure patterns, trace execution paths, explain complex business logic, and even suggest ways seemingly harmless issues could be chained together into a viable attack.

In other words, every security researcher just got a very fast pentester and code reviewer that never sleeps.

Source Code Is AI’s Favorite Input

The real stuff is not that AI can magically discover vulnerabilities. Skilled researchers have been doing that for decades.

The difference is efficiency.

An attacker probing a live system sees only the outside of the house. An attacker with source code gets the floor plans, electrical diagrams, and a list of which windows nobody remembered to lock. LLMs thrive on context, and source code provides plenty of it.

A model can quickly answer questions such as:

• Where does user input reach sensitive functions?
• Which authorization checks can potentially be bypassed?
• What assumptions are developers making?
• Can multiple low-severity findings be combined into something more serious?

Many of these tasks previously required days or weeks of manual analysis. Now they can often be completed in hours and many tokens.

The New Problem for Open Source

Open source has traditionally benefited from the idea that “many eyes make all bugs shallow.” That principle still holds true. The problem is that attackers now have many more eyes as well.

A vulnerability researcher can point an LLM at a repository and rapidly explore areas that would have taken significant effort to understand manually. The same transparency that helps defenders can now be leveraged more efficiently by attackers.

This does not mean open source is becoming insecure. It means the cost of analyzing open source software is dropping for everyone.

Closed Source Doesn’t Get a Free Pass

Some organizations may see this trend as a win for closed source software. LLMs are also becoming increasingly useful for reverse engineering, API analysis, traffic inspection, and understanding application behavior. Attackers do not always need source code to gain valuable insights. Security through obscurity was never a complete defense, and AI is making obscurity even less reliable.

What Organizations Should Do

Perhaps the most important change is not capability but scale. The result is simple: vulnerability discovery becomes cheaper. And whenever something becomes cheaper, you should expect more of it. The answer is not abandoning open source or hiding more code.

Instead, organizations should assume that AI-assisted security research is now the norm.

That means:

• Faster patching cycles
• Better threat modeling
• Stronger code review processes
• More automated security testing
• Using AI defensively for code audits and security analysis

The best response to attackers using AI is often defenders using it first.

The Bottom Line

For years, the argument was whether attackers could see the source code. The assumption was that visibility itself created risk. Security through obscurity, while rarely advocated as a primary defense, was often viewed as providing at least some friction.

Large language models challenge that assumption. The old open source versus closed source debate is no longer just about philosophy. It is now about how quickly AI can transform access to code into actionable security knowledge.

This shift weakens one of the historical advantages often attributed to closed source software: the assumption that limited visibility creates meaningful barriers for attackers. While source access still matters, the gap between “having the code” and “understanding the code” is shrinking. The future debate is therefore unlikely to be about whether source code should be visible. Instead, it will focus on how organizations build secure systems under the assumption that their software can be understood, analyzed, and reasoned about at unprecedented speed. In an era of AI-assisted analysis, resilience matters more than obscurity.

The winners will not be the projects that hide their implementation details most effectively. They will be the projects that remain secure even when those details are fully understood.