For years there was an unspoken contract holding open source security together. A researcher would find a flaw, report it quietly through a security@ inbox, and the maintainer would ship a patch before attackers could build an exploit. Both sides got something. The maintainer got scarce expert insight and a head start. The researcher got credit and a thank-you. That quiet exchange is a big part of why the software your business runs on every day has not already fallen apart.

Last week Filippo Valsorda, who led the Go security team for years, wrote that the contract is over. Not strained. Over.

Why the report stopped being scarce

His reasoning is short and hard to argue with. It is 2026, and a large language model is now about as good at finding vulnerabilities as almost any security researcher. Anyone can run one. The maintainer can run it. The attacker can run it. So the insight a confidential report used to carry is not scarce anymore. The hard part was never spotting a suspicious code path; it was deciding which of the suspicious code paths is a real, exploitable bug. As Valsorda puts it, picking through an LLM's output and picking through a security inbox now have about the same signal-to-noise ratio.

Confidentiality takes the same hit. Embargoes and coordinated disclosure existed so defenders could patch before the details leaked to attackers. But an attacker does not need to read your disclosure post anymore. They can ask their own model and get to the same place. The head start you were protecting has mostly already been handed out.

If you run a business that depends on software, and that is every business now, this matters more than it looks.

What "secure" used to be a proxy for

The comfortable story most companies tell themselves about security is a process story. We have a reporting channel. We respond to researchers. We have a policy. For a long time that was a reasonable proxy for "we take this seriously," because the process was where the protection actually lived. The scarce thing was being routed to you and only you, with time to act on it.

That proxy is breaking. Having a tidy inbox and a responsive policy says less and less about whether your users are safe, because the inbox is no longer the chokepoint. When the same flaws are visible to everyone with an API key, the thing that separates a safe product from an exposed one is not who told you first. It is how fast you can go from "this is real" to "this is patched and deployed," and how much you prevented before anyone had to report anything.

Valsorda names the new job plainly: triage, rapid remediation, and, as ever, prevention. That is not a disclosure policy. That is an engineering posture, and most of it is unglamorous maintenance work. Can you tell a real finding from noise quickly? Can you ship a fix and get it into production the same day? Are you running analysis continuously instead of waiting for a stranger to do it for you? Those questions decide the outcome now, and none of them are answered by a page on your site that lists a contact address.

The flood runs both directions

It cuts the other way too, and that part is worth sitting with. The same models that let defenders find bugs are drowning the people who fix them. Daniel Stenberg, who maintains curl, suspended the project's vulnerability reporting channels for a stretch in June 2026 because the volume of confident, plausible, and completely bogus AI-generated reports had become unmanageable. So the flood runs both directions. The cost of generating a vulnerability report, real or imaginary, has collapsed, and a lot of what lands in a maintainer's inbox is machine-generated slop that still takes a human an hour to disprove.

That is the actual problem to solve, and it is not really a security problem. It is a signal problem. When generating plausible output is free, the scarce skill becomes telling the real thing from the convincing fake, fast and at scale. We wrote about a version of this when an AI agent could not tell whose instructions it was actually following, and it is the same shape here. The model is cheap. The judgment about what to trust is expensive, and it is the part you cannot skip.

What actually protects you now

For most businesses the honest takeaway is not "buy an AI security tool." It is to stop treating security as a mailbox and start treating it as a loop you can run on your own terms. That means knowing your dependencies, having a way to evaluate a finding without dropping everything for a day, and being able to deploy a fix without a two-week release ceremony. It means deciding, deliberately, where automated analysis earns its place in your pipeline and where it just adds noise, which is the same discipline behind picking the few things AI should actually do in your business rather than the many things it can.

This is the part of the work that does not show up in a demo. It is why we build ongoing maintenance into how we run software instead of treating it as a thing you bolt on after launch, and why our AI development work starts with where a model genuinely sharpens a process, not where it just generates more to wade through. When anyone's AI can find the bug, the company that stays safe is the one that already knows how to separate the real ones from the noise and move fast on what is left.

The special status is gone. The job underneath it never was special. It was always the boring loop. Now it is the only thing left.