Google's Chrome team wants two things at once, and they contradict each other.
They want to fix security bugs faster than any human team ever could. And they want to keep disclosing every one of those fixes in public, because openness is a core principle.
The numbers make the first goal look like a triumph. According to Google, Chrome fixed 1,072 security bugs across two June releases—more than the 1,036 it fixed across the previous 23 versions over two years.
Doug Turner, Chrome's director of engineering, described the shift plainly: LLMs have "fundamentally shifted the economics of cybersecurity, transforming vulnerability discovery into an automated, industrial-scale operation."
Here's the part that gets buried under the celebration. Every one of those 1,072 fixes is a signal flare for attackers.
The Chrome team says it themselves: "once a bug fix lands in the public open-source codebase, attackers can reverse-engineer it to launch N-day exploits before the fix reaches end-user devices."
So the faster you patch in the open, the faster you hand adversaries a map. A public diff is a tutorial in the exact vulnerability you just closed, published before the fix reaches most users.
A public diff is a tutorial in the exact vulnerability you just closed, published before the fix reaches most users.
This is the paradox of open-source security in the AI era. Transparency is what made Chromium trustworthy—50 million lines anyone can audit, used by Edge, Brave, Opera, Samsung. And transparency is now the exploit surface.
Chrome's answer is speed as damage control. Depending on severity, patches get merged straight into the active Stable branch, and the team is pushing for more frequent releases specifically to shrink the window between "fix is public" and "fix is installed."
That's a real defense. But it treats a structural problem as a logistics problem. The map still gets published. Chrome is just racing it.
Which raises the more interesting question. If everyone now has AI that generates fixes, what actually separates a team that stays ahead from one that drowns?
It isn't the model. Read Chrome's own description of its pipeline and you'll notice the fixing agent is almost a commodity—it returns multiple candidate fixes, a critic agent picks the best, test-writing agents validate across platforms. It's an assembly line, and anyone can build one.
The scarce ingredient shows up in a quieter line. Chrome is "encouraging developers to add SECURITY.md files, which help models better understand trust boundaries and develop an accurate view of the threat model."
Read that again. The bottleneck isn't the agent's reasoning. It's whether anyone has written down, in a form the agent can read, what "secure" even means for this piece of code.
Chrome built a critic agent with its own separate context whose entire job is to consume those SECURITY.md files. The intelligence is off the shelf. The judgment has to be authored.
Figma learned the same lesson from the opposite direction, and their version is the clearest articulation of it anywhere.
Figma says it runs security agents at three stages—code generation, pull request review, and auditing a decade-old monorepo—all on a single policy. When they started, that policy performed terribly.
Developers stop trusting a tool that floods them with noise, so Figma held back developer-facing comments until precision stayed above 70% over a two-week lookback.
To get there, they hand-labeled eight weeks of false positives themselves and wrote a policy. And they made one deliberate choice that mattered more than the model selection.
They wrote the policy as precedents, not rules. Instead of "don't flag SQL injection in dbops," they wrote "dbops is only run by highly privileged operators who already have direct database access."
The distinction is everything. A rule tells an agent what to do. A precedent tells it why—and preserves the security reasoning it needs to generalize to a case no rule anticipated.
Then came the part they didn't plan.
In their words: "We had written a complete threat model, in roughly the form we'd want a new hire to read on day one." And, separately: "The policy is the threat model."
That sentence should stop every security and design leader cold. The artifact that makes the agent effective is identical to the artifact that would onboard a smart human. Judgment, written down at high resolution.
Figma is explicit that this context already existed—scattered across a decade of documentation, incident learnings, and institutional knowledge. It had simply never been consolidated "at the resolution an agent needs." That consolidation was the real payoff, and because generation and auditing run on the same threat model, they never had to build it twice.
So here is the uncomfortable synthesis. The fixing agent is a commodity everyone gets. The durable asset is the written threat model that teaches an agent judgment.
And that reframes open source's founding virtue as its central liability.
Figma's 68 precedents can act as a private moat. They describe exactly how Figma reasons about trust—which operators are privileged, which boundaries matter, which endpoints check org ownership. Figma can hoard that reasoning indefinitely, and nobody outside the company ever sees it.
Chrome cannot. Chromium publishes its code, publishes its patches, and now—to make its own agents effective—must publish its threat context in SECURITY.md files that live in a public repo.
The high-resolution judgment that Figma treats as a competitive secret is exactly what Chrome has to broadcast to arm its defenders. And whatever arms your defender's agent arms the attacker's agent too.
That's the structural unfairness. A closed shop can accumulate the most valuable security asset—codified judgment—entirely in private. An open codebase has to hand its adversaries the same map it hands its defenders, on top of the patch diffs it was already publishing.
The old bargain of open source was that many eyes make bugs shallow. The new reality is that many eyes now includes an untiring adversary running the same commodity agent you are, reading the same threat model you were forced to write down.
None of this argues against open source. Chrome is still finding the wins. The tooling is genuinely extraordinary.
It argues that the baseline security craft has changed. The new skill is not writing rules or buying the best model. It's writing down your judgment at the resolution an agent needs—as precedents that carry reasoning, not rules that carry only verdicts.
Design-literate teams should recognize this instantly, because it's the exact logic of a design system. A component library is judgment made explicit and reusable: not "here's a button" but "here's why we space things this way, here's when this pattern applies." Codify the reasoning once, and every downstream decision inherits it.
A threat model is a design system for security. The teams that win the arms race will be the ones who write theirs down first, and write it well.
The open ones just have to do it knowing the attacker is reading over their shoulder.