AI Changed the Open Source Security Equation. That’s Worth Defending, Not Closing.

Earlier this month, Cal.com — one of the most visible open source TypeScript projects of the last five years — announced it was going closed source. The reasoning the team gave was unusually candid. AI, they argued, has “fundamentally altered the security landscape.” Code that was once read by humans is now scanned, mapped, and probed for exploits at near-zero cost by models that understand almost any codebase they’ve been trained on. In a world like that, transparency starts to feel like exposure.

The decision prompted a sharp response from Theo Browne, whose video on the Cal.com pivot lays out the clearest argument for why the reasoning holds up and why the conclusion is still wrong. The framing that follows — AI has collapsed half of what used to gate serious exploit-finding, so defense now looks less like careful code review and more like outspending the attackers — is Browne’s, building on Drew DeVault’s proof-of-work essay. What this post adds is the WordPress application: what the same argument means for the 43% of the web Browne’s video doesn’t cover.

What actually changed

Finding a serious exploit in a production codebase has always required two kinds of expertise at once: deep security knowledge, and deep knowledge of the specific domain — the stack, the framework, the quirks of that particular system. Very few people have both. As Browne frames it, that scarcity was a moat, even for open source projects whose code sat in public. A security researcher who didn’t read full-stack TypeScript well was not meaningfully helped by Cal.com being open.

AI collapsed the domain half of that equation. A model fluent in TypeScript, PHP, Rust, or decades-old OpenBSD C can do the “understand this codebase” work on behalf of someone who couldn’t do it alone. Anthropic recently demonstrated this by running agentic security sweeps across OpenBSD — arguably the most carefully audited operating system in existence — and surfacing a twenty-seven-year-old vulnerability. That is not a story about sloppy code. It is a story about a tool that removed the domain barrier.

Drew DeVault, in an essay Browne quotes at length, describes the resulting dynamic as security-as-proof-of-work. Attackers throw tokens at a codebase looking for exploits; defenders throw tokens at the same codebase trying to find them first. Whoever spends more, wins. It’s a crude simplification, but a useful one — it explains the shape of the new landscape without pretending the old moats still hold.

Why closing the source is the wrong response

The Cal.com team’s instinct is understandable. If the attack surface is proportional to how readable the code is to a model, hiding the code feels like buying back some asymmetry. Browne’s counter-argument is that the advantage is small and shrinking. AI-assisted reverse engineering of minified or compiled code is already improving quickly. Closing the source buys time, not safety.

What closing the source does give up is the asymmetry that favors defenders in the proof-of-work framing. When ten companies depend on the same open library, their security spend is additive. Ten independent teams each running security sweeps against the same code is a much bigger total budget than any one of them could justify alone. Closed source loses that leverage. It also removes the good-faith researchers who would have disclosed responsibly, and leaves only the attackers — who never needed permission in the first place — still looking.

The correct response to AI-capable attackers is not to hide. It is to spend on the defense side at the same pace. That is where the conversation needs to go, and it is the conversation most relevant to WordPress.

WordPress is the largest open source target on the web

Browne’s video focuses on full-stack TypeScript — the domain where Cal.com, Vercel, and the T3 stack live. The same logic applies with more force to WordPress, and for a specific reason: WordPress is substantially more exposed than any TypeScript SaaS. The codebase is older, the plugin surface is vastly larger, the maintainers are more fragmented, and the update channel is trusted by default on millions of sites that no one is actively watching.

WordPress still powers roughly 43% of all websites in 2026. The number has dipped slightly as SaaS builders grow, but it remains the single largest open source attack surface on the public internet. Roughly 97% of WordPress vulnerabilities originate in plugins and themes, not Core. In a single week of January 2026, researchers disclosed 333 new vulnerabilities across the ecosystem — 253 in plugins, 80 in themes. Collectively, WordPress sites face around 90,000 attempted attacks per minute.

The supply chain pressure is getting worse specifically because the attack pattern fits the proof-of-work framing so well. In 2025, an attacker bought a portfolio of thirty-one plugins on Flippa, sat on them for eight months, then pushed a backdoored update through the legitimate WordPress.org auto-update channel. Gravity Forms — a premium plugin with roughly a million installs — was compromised at the vendor’s own infrastructure, with backdoored installers shipping from the official download page. More than half of plugin authors who receive a vulnerability report do not patch it before public disclosure. The average production site carries dozens of dependencies, nested several layers deep.

This is what the new landscape looks like in practice: an enormous, public, continuously attacked codebase, defended by a fragmented and uneven budget spread across tens of thousands of independent maintainers. Scanners built on signature matching and file-integrity monitoring were designed for a world before models could read a plugin update diff in seconds and reason about it.

What spending on the defense side looks like

There is no single fix for any of this. The shape of the response, though, is increasingly clear: site owners need tooling that does continuous, cheap, automated hardening — the kind of work that used to require a human security auditor no small business could afford to keep on retainer.

A few layers that apply directly to WordPress:

Plugin Guardian — watch what the updater lets in

Plugin Guardian, which ships inside PressBot Shield, snapshots plugin code before an update, compares the new PHP files and the Author / Author URI metadata afterward, and assigns a low / medium / high / critical verdict to each update. Ownership transfers — the exact signal behind the thirty-one-plugin Flippa incident — are flagged explicitly, because most commercial scanners currently ignore them. It is precisely the kind of semantic, diff-aware check that the AI-era threat model rewards: cheap to run, model-assisted, focused on change rather than signatures.

PressBot Pro — audit what is already installed

Controlling what gets in only helps if what is already running is also under watch. PressBot Pro’s admin agent ships a twelve-check security_audit tool that evaluates file permissions, debug mode, SSL configuration, admin username exposure, XML-RPC status, database prefix, and more — callable in plain English from the WordPress dashboard or Telegram. In practice, that looks like:

"Run a security audit and show me which plugins have updates available."

The agent runs security_audit, returns severity-rated findings, then chains into get_plugins for the outdated list — one conversation, two tools. Follow-ups like "Show failed login attempts from the last 24 hours" pull Shield data in real time. "Block 192.168.1.47 for 24 hours" acts on it. The same workflow runs from Telegram, so responding to a flagged event doesn’t require being at a desk.

BYOK — the security data never leaves your stack

PressBot operates on a Bring Your Own Key model. API calls go directly from the site’s server to Anthropic or Google; nothing passes through PressBot infrastructure in transit. Keys are AES-256 encrypted with the site’s own WordPress salts before storage. For security tooling specifically, that architecture matters. Audit findings, login logs, and plugin inventories stay inside the site they describe.

A practical checklist for this week

For any WordPress site running more than a handful of plugins:

1. Audit dependencies. Install PressBot Pro and run "Run a security audit" from the dashboard agent. Triage every finding rated high or critical first.
2. Watch plugin updates, not just plugin signatures. Enable Plugin Guardian inside PressBot Shield so ownership changes and suspicious diffs get flagged the moment an update lands.
3. Update aggressively. Ask the agent "Which plugins need updates?" and work through them with confirmation.
4. Baseline login attacks. Use get_shield_stats to understand normal attack volume, then check weekly from Telegram.

Open source gave the web WordPress. It also gave the web most of the dependencies quietly powering everything built on top of it. The security economics underneath that model have shifted, as Browne argues — and they will keep shifting as models get better. Keeping the source open, and matching attacker spend with defender spend, is still the right posture. The tooling to do that without living inside the dashboard now exists. It’s worth using.