The New Cybersecurity Bottleneck Is No Longer Finding Bugs

On October 6, 2026, Anthropic reported that Project Glasswing partners had found at least 129,000 verified software vulnerabilities between April and July, plus 5,500 more from Anthropic's own open-source scanning through October [1]. More than 33,000 have been rated critical or high so far, a figure Anthropic describes as likely undercounted because it relies on survey data from a subset of partners [1]. Anthropic also expects the true impact to be at least five times higher, which is the company's estimate rather than an independently verified number [1].

These numbers are often read as a story about attackers. I think the more useful reading is operational. Finding vulnerabilities is no longer the scarce step. Everything after discovery is.

What Anthropic's Own Data Shows

Anthropic publishes a coordinated disclosure dashboard for the open-source findings it reports to maintainers. As of October 2, 2026, it showed the following pipeline [2]:

Two cautions before drawing conclusions. First, the stages have different definitions and denominators. Disclosed is larger than confirmed because some reports went directly to maintainers who asked for them. Second, 516 of 6,157 is roughly 8.4%, but that ratio applies only to this dashboard. It is not the patch rate for all Glasswing findings, and Anthropic notes that fewer than half of its partners disclosed patch counts at all [1].

Even with those caveats, the shape is clear. The model surfaces candidates by the tens of thousands. Human triage processes about a fifth of them. Patches arrive for a small fraction of what has been disclosed.

Anthropic made the same point in its May update: the work is now "limited by how quickly we can verify, disclose, and patch" these vulnerabilities, and several maintainers described themselves as "severely capacity constrained" [3]. Some asked Anthropic to slow its disclosure rate so they could design fixes [3].

Discovery, Exploitation and Remediation Are Different Problems

It is easy to collapse these into one story, and that leads to bad decisions. They are separate stages with separate owners:

• Discovery: a flaw is identified, by a person, a scanner or a model.
• Exploit development: someone builds a working path from that flaw to impact.
• Real-world exploitation: an attacker uses it against a real target.
• Remediation: a fix is written, released, tested and deployed.
• Protection: the production workload is verifiably no longer exposed.

Glasswing data tells us about the first stage, and partly about the fourth. It does not show that every finding is being exploited. I covered what AI-assisted discovery means for VCF environments in AI Vulnerability Discovery and VCF 9.1 Security, and the exploitation side in GPT-6 Astra Scores 100% on ExploitBench and An AI Agent Hacked a Cybersecurity Nonprofit Through Zero-Days It Found on Its Own. The new point is this: when discovery gets dramatically faster, every later stage becomes the constraint.

An Upstream Patch Is Not an Installed Fix

The dashboard counts a vulnerability as patched when the maintainer releases a fix [2]. For an enterprise, that is where the work starts.

The fix has to travel through package registries, vendor products that embed the library, container base images, appliance firmware and internal builds. Much of this exposure sits in transitive dependencies that no one chose directly. If you cannot answer "where do we run this component, and which version," you cannot know whether a published patch applies to you, let alone whether it has been installed.

This is why a software bill of materials (SBOM) matters in practice, not as a compliance artifact [4]. Dependency visibility is the precondition for every step that follows.

Prioritize by Exposure, Not Severity Alone

A queue sorted by CVSS score will not survive a discovery rate measured in thousands per month. CVSS measures the technical severity of a vulnerability, and FIRST is explicit that it is not a measure of risk [5].

Risk depends on context the score does not see: whether the vulnerable code is reachable, what privileges are required, which versions you actually run, what mitigations already exist, and what the affected asset is worth. Signals that help narrow the queue already exist:

• Known exploitation: CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation [6].
• Exploitation likelihood: FIRST's EPSS estimates the probability that a vulnerability will be exploited in the next 30 days [7].
• Decision models: CISA's SSVC turns exploitation status, exposure and mission impact into a decision such as act, attend or track [8].

None of these replaces knowing your own environment. They make the queue shorter so humans can spend their time where exposure is real.

When You Cannot Patch Yet

Some fixes cannot be deployed immediately: the vendor has not shipped one, the change needs compatibility testing, or the system is too critical for an unscheduled change. Anthropic's May data put the average time for a maintainer to patch a high or critical bug at about two weeks [3], before any downstream organization begins testing.

That gap needs compensating controls that reduce reachability and blast radius while the fix moves through the pipeline:

• Virtual patching at the network or host layer to block known exploit patterns.
• Segmentation so a vulnerable service can only be reached by the systems that need it.
• Runtime least privilege so a successful exploit gains as little as possible.

I described how these layers fit together on a private cloud platform in AI Changed the Threat Landscape. VMware's Answer Is a Security Architecture That Fights Back at Machine Speed and, at the hypervisor layer, in VMware HyperArmor: Proactive Host-Layer Defense for the AI Threat Era. The principle is vendor-neutral: buy time without pretending the vulnerability is gone.

An Alert Is Not a Verified Outcome

Security tooling reports many things that sound like protection but are not the same thing:

Only the last one answers the question that matters. A scanner listing findings, a firewall logging a block, or a patch being available upstream does not prove that the exposure in production has been removed. Verification means re-testing the actual workload after the fix or control is in place.

The Human Capacity Problem

The dashboard makes one more point visible. Of 29,439 candidates, 6,123 had been reviewed by human-led triage firms [2]. AI-assisted discovery pipelines produce work faster than people can validate it, and unvalidated findings are noise.

Anthropic's October update expanded its Cyber Verification Program into Defense, Red Team and Specialized access tiers, giving vetted defenders broader access to its most capable models [1]. In its CyScenarioBench evaluation of Claude Opus 5.5, the Defense tier was blocked at some point in 46 of 50 trials, while the Red Team tier completed 34 of 50 tasks with no blocks [1]. These are controlled benchmark results, not real-world attack rates, but they show the intent: putting the same capability in defenders' hands. It still runs into the same limit. Someone has to review the output, decide, and act.

What I Would Change in the Operating Model

1. Build the inventory first. A current, queryable map of components and versions, including transitive dependencies, so a new advisory can be matched to real assets in minutes.
2. Replace severity queues with exposure queues. Combine known exploitation, exploitation likelihood and reachability before a ticket reaches an engineer.
3. Shorten the validation and deployment cycle. Pre-approved change windows, staged rollouts and automated compatibility tests for common patch types.
4. Treat compensating controls as a standard step. For every critical finding without a deployable fix, document which control reduces exposure and how long it stays in place.
5. Measure verified outcomes. Track time from disclosure to verified protection in production, not time to ticket closure.

The Question That Matters

AI has changed the economics of finding vulnerabilities. The open question for every enterprise is whether it can reduce real exposure as fast as AI increases the rate of discovery. That is no longer a research problem. It is an infrastructure and operations problem, and it is solved by inventory, prioritization, compensating controls and verification, not by more findings.

References

[1] Expanding the Cyber Verification Program↗ - Anthropic, October 6, 2026

[2] Coordinated Vulnerability Disclosure Dashboard↗ - Anthropic, snapshot October 2, 2026

[3] Project Glasswing: An Initial Update↗ - Anthropic, May 22, 2026

[4] Software Bill of Materials (SBOM)↗ - CISA

[5] Common Vulnerability Scoring System↗ - FIRST

[6] Known Exploited Vulnerabilities Catalog↗ - CISA

[7] Exploit Prediction Scoring System (EPSS)↗ - FIRST

[8] Stakeholder-Specific Vulnerability Categorization (SSVC)↗ - CISA

Disclosure: The author is an employee of Broadcom. This article represents the author's technical analysis and does not represent Broadcom's official position.