Linus Torvalds, the creator of the Linux operating system, is famously credited with a law that says: “with many eyes, all bugs are shallow.” The idea is that the more people who can find and fix software flaws, the fewer that will exist in a codebase. While large language models like Claude and ChatGPT may not have eyes in the traditional sense, they certainly can find shallow bugs. And it’s causing a lot of the practices and assumptions we’ve relied on in cybersecurity for decades to come under threat. Many in cybersecurity wrote obituaries for vulnerability coordination, but I think that’s premature.
In October 2026, almost simultaneously, news broke about major vulnerabilities (in PHP and GitLab code, as well as eMudhra certificate signing keys, most notably) that affect nearly every server, browser, and IoT device around the world. Government agencies and news sites took their own systems offline as a precaution, and virtually every cybersecurity worker jumped into action to fix things (or yell about it on social media).
In reading others pontificating on the death of vulnerability coordination, I think they’re missing a key idea: Coordination isn’t dead, but the conditions have changed. Coordination between one reporter and one receiver still works as well as it did 30 years ago when our practices were novel. The heavy use of LLMs for vulnerability discovery has exposed several assumptions that we only really believe to the degree they allow processes like CVD to work. Like economists’ homo economicus or physicists’ spherical cows. While these were never fully true, outliers were edge cases or other factors dampened their impact on disclosure processes.
Four assumptions that broke
- Assumption 1: Highly impactful vulnerabilities in major software are relatively rare. There is a longstanding debate (see Dan Geer, etc.) about whether security vulnerabilities are dense or sparse. As we are starting to see with an increase of AI scrutiny of codebases and binaries, impactful vulnerabilities in major software seem more common than was assumed. In the case of the GitLab disclosure, one researcher found four Remote Code Execution bugs within a month of focused attention on one of its dependencies. And LLMs make this kind of focus nearly free.
- Assumption 2: Supply chains are reasonably short. The disclosure path for first-party commercial software is fairly straightforward: the finder reports to the code owner/maintainer, and the fixes are pushed to deployers. While that path was common 20–30 years ago when vulnerability disclosure norms were first worked out, modern development environments favor heavy dependency on common open source components, which often have deep supply chains and don’t track who uses their software. Even when open source supply chains are short, they’re often nebulous: who is using what, and how would anyone tell them? While multiparty disclosure processes are well understood, they’re hard and rarely end up with all stakeholders informed. A regex engine three layers down affected GitLab, and PHP is a key component for a large proportion of Internet servers.
- Assumption 3: Concurrent discovery is unlikely. RAND and Harvard Belfer papers from a decade ago argue over whether different researchers will find the same bug again (rediscovery). What we’ve seen in past is that this is a function of how much attention researchers spend on a piece of software or class of bug. In the PHP case, no fewer than four independent parties found the issues in the last few months.
- Assumption 4: Issuance of a patch is the end of the process. It’s the start of the larger process, addressing the issue across all affected deployments. A patch is a disclosure, and one that is far more useful to rediscovery than most CVE writeups. Which is partly why Chainguard’s disregard for the PHP patch embargo angered so many and led to the sense that coordinated disclosure is dead.
What it looks like from the inside
I saw that first hand in the summer of 2026 when one of Stratigos’ researchers found a few issues in a protocol-specific open source library. While the first few bugs came by traditional analysis, LLMs produced dozens across multiple libraries. It’s a classic multi-party disclosure with a couple of wrinkles: multiple libraries and some middleware products in the mix, as well.
We handled disclosure, per standard procedures. We reported to the libraries, some rushed out a fix, some promised a fix when they could. But they couldn’t notify downstream parties because they didn’t have a list. So we started looking at disclosing directly to affected parties, using connections, intuition, and a little research to identify them. We stopped counting at 100 and turned to other groups for help, like CISA and the Health-ISAC, showing full exploit chains in demonstration equipment to ensure the impact was understood. Unfortunately the job was too much for those groups as well, with a muted response from both groups and no follow up.
Buying time: short, medium, and long term
The massively multiparty relationships between finders, supply chain, end product suppliers, and deployers call for new models of coordinated vulnerability disclosure. Those take time to develop, and in the meantime we can buy ourselves that time by adjusting a few levers in the short, medium, and long-term:
- Short-term: Reduce the burden for coordination. Set up ad-hoc rapid response groups clustered around specific areas that can activate when a large number of new reports come into an open source library or manufacturer, so the issues can be replicated, triaged, prioritized, and coordinated across as many affected parties as possible. This is more like a call tree than a standing body. The FDA proposed a CyberMed Safety (Expert) Analysis Board (CYMSAB) for a similar purpose in 2018. Other groups may also act as key conveners, such as the Medical Imaging and Technology Alliance (MITA) who develop the DICOM standard and have technical contacts for many manufacturers who use this protocol.
- Medium-term: Dry up the pool of impactful bugs. These groups can pool resources (money, people, contacts, equipment) to focus on identifying and mitigating common supply chain weaknesses to reduce the volume and severity of latent flaws. Opening the group membership can help accelerate and reduce the individual burden, such as inviting cybersecurity researchers to donate time, soliciting government grants, and reaching out to well resourced but lightly affected third parties for help (and yes, LLM vendors can give tokens to find/fix). Less bugs, less disclosure.
- Long-term: Incentivize ongoing maintenance and coordination. Many people have recognized that an overwhelming majority of commercial software depends on open source, which often puts an extraordinary burden on individual volunteer developers and maintainers. Most of the proposals I’ve heard to address this issue seek to provide financial resources to those open source projects (which introduces a different type of burden and rarely works). Instead, take resources and incentives already in the system and align them with the goal of resilient supply chains. Software makers benefit from open source and many (such as medical device makers) are already required to look for vulnerabilities in the software; some of them silently fix or compensate for them without contributing back to the open source projects. Instead, public policies can nudge them toward activities that find, fix, and push changes that make supply chains across the industry more resilient and reduce the burden on the maintainers. This makes the “less bugs, less disclosure” approach sustainable. In addition, work to maintain relationships with others who use the same code so that when an issue is identified, it can be quickly addressed across all of the deployed products. Industry bodies are well positioned for this, but only a few have actually done this effectively or at scale.
More to come
I’m certainly not the only one looking and thinking about this, including Marcus Hutchins, Ian Coldwater, Jake Williams, and many others. As Casey Ellis says in his Amended Linus’ Law, “with many eyes and the right incentive, all bugs are shallow.” The returns for vulnerability discovery are the same as they were a few years ago, but the costs have gone way down. So you’ll hear a lot more about these things in the coming months. I’m planning to touch on a couple more of the major threats or disruptions on the horizon in upcoming posts, including:
- Obscurity was a subsidy for security, now it isn’t. When the limiting factor in vulnerability research was the attention of experienced researchers, reports and disclosure were sparse. When that resource can be acquired by the token, it reduces the barrier to entry for other motivations.
- “Just patch” or “patch faster” is not enough. There’s a “speed of light” for patching and it differs across industries and org structures. The time from discovery to exploitation has been decreasing over time; with LLMs it’s gotten very fast. Choices early in the process can remove and mitigate issues, buy time to fix them, and allow for faster fixing.