Detection Got Cheap. Remediation Didn't.
Anthropic has used its Claude models to report thousands of vulnerabilities to open-source maintainers, which it tracks on a public page. As of November 2, Anthropic had reported 5,087 vulnerabilities in 680 open-source projects, of which maintainers had "patched" 629 (in Anthropic's parlance, "patched" means that a project's maintainers have made a patched version of the software available, and it doesn't necessarily mean people are using the patched version). The definition underneath that last number matters more than the number.
Anthropic's October tally across Project Glasswing partners and its own scanning comes to at least 134,500 verified vulnerabilities since April, more than 33,000 of them critical or high, and it calls the partner count a likely undercount.
Independent research group Epoch AI found that in June, the number of high and critical severity CVEs published by 21 major tech organizations reached about 3.5 times the previous monthly record.
Of course, some of that uptick could just reflect more people looking for vulnerabilities. But it's still software teams that have to triage and address those vulnerabilities. As Anthropic noted back in May, the limit now is "how quickly we can verify, disclose, and patch the large numbers of vulnerabilities found by AI," and some maintainers have even asked the company to slow down its disclosures. (Anthropic sells the models finding these vulnerabilities, so it has a stake in those totals.)
Those teams were falling behind before any of this arrived. The 2026 Verizon Data Breach Investigations Report shows that organizations' median time to fully patch vulnerabilities increased from 32 days to 43 days, year over year. During that same period, the share of vulnerabilities listed in CISA's catalog of known exploited vulnerabilities that organizations completely remediated decreased from 38 percent to 26 percent.
Finding the hole got cheap this year. Closing it didn't, and a lot of what the industry buys next will make the queue longer without shortening it.
The old holes are still the ones getting used
At TSIA World in October I talked about what I call the architecture tax, which is when a vulnerability affects a device, and either a) there's a patch but it never made its way to the device, b) you didn't even know you had that device/vulnerability or c) there's no patch because the product is EOL (end of life). VulnCheck released its March report on vulnerabilities in network edge devices, which showed 42.5 percent of vulnerabilities exploited in 2025 were on devices that are EOL or likely EOL. So while a model can now point out a 27-year-old vulnerability in OpenBSD, threat actors are taking advantage of devices that vendors aren't going to patch. Can't fix what you don't know you have!
Hugging Face's July disclosure shows what the new pressure looks like. In it, an AI agent autonomously executed an intrusion attack (leaving behind over 17,000 logged events/actions!). LLM-based triage identified the attack and LLM agents helped reconstruct a timeline of events. Remediation still included typical activities such as closing code execution paths, removing the threat actor's beachhead from impacted clusters, rebuilding impacted compute nodes and rotating credentials. Detection sped up. The list of things to do afterward stayed the same length.
A patch in a repo is not a patch on a device
AI-generated patches could help with some of this work. In the August 2025 finals of DARPA's AI Cyber Challenge, finalists' systems found 54 synthetic bugs across 63 challenges and wrote patches for 43 of them in an average of 45 minutes, at an average cost of about $152 per task. I expect those numbers to improve. They measure the cheap half.
Writing the patch happens in a repository. Everything after that happens in somebody's environment. Someone has to identify affected devices, determine if they're still vendor-supported, validate that the fix will work for them, figure out when to deploy it, deploy it, and own it if it doesn't work. Generating diffs does not solve any of that.
End-of-life equipment is even more challenging because there may not be anything to patch. The options are replacement or isolation, and both of those are projects with budgets and owners.
CISA released Binding Operational Directive (BOD) 26-02 in February, requiring federal civilian agencies to inventory all end-of-support edge devices within three months and remove them from agency networks within 18 months. It binds no one else, and its end state is removal. Isolation buys time until you get there.
Dashboards stop one step short
Most organizations have figured out a way to see the threats. A dashboard helps with detection. It doesn't take you all the way to remediated.
Playbooks provide a valuable next step after you've implemented dashboards and alerts, since they offer detailed, step-by-step instructions for dealing with problems or threats. But playbooks need to be run regularly since the queue is always being replenished. And because there are likely to be a lot of alerts, figuring out how to deal with problems and threats efficiently can be a struggle. Playbooks can help, but only if they're highly specific to your organization's assets and tailored to your needs. The difference shows in the questions each one can answer.
| The dashboard tells you | The playbook has to answer |
|---|---|
| How many critical advisories you have | Which ones hit the assets the business depends on, and in what order |
| A device is affected | Which version fixes it, and whether this device can run it |
| A patch is available | Who installs it on this asset, and in which change window |
| It's being exploited and there's no patch | The workaround to apply tonight, and how to back it out |
| End of support is coming | Replace or isolate, by when, and who decides |
| The ticket is closed | Whether the fix is verified on the device |
Alerts are important, but it's critical to think about what you're going to do with them before you set them up. Who should be notified? What sort of response should the alert elicit? What's the appropriate next step? Ideally, when a vulnerability is being actively exploited, alerts will include workarounds or solutions and be narrowly targeted to only the people who manage the affected asset. A broadcast teaches people to ignore the next one.
Automate the work and keep a person at the gate
The mandate has two halves: automated patching and network segmentation.
At this volume, patching has to be automated. After agreeing on the upgrade with the appropriate engineer/manager and getting permission to upgrade, almost everything about upgrading devices could be done by an agent with minimal human interaction:
- Agree on the version to upgrade to and when it should be done
- Take a snapshot/baseline before the upgrade and make sure you can still reach the device if the upgrade fails
- Run pre-upgrade checks
- Upgrade the software and make sure the device came back up OK
- Make sure the device is healthy and running the expected version
An agent that can push software across a network is about as privileged as agents get, so it's important to keep in mind some of the things I've written about before: what capable agents do around infrastructure and making sure you can tie actions taken by agents to the humans who requested/allowed them to happen.
Segmentation is the other half, and the reason is arithmetic. If only a quarter of known-exploited bugs get fully remediated, most of the queue is open on any given day. Network segmentation (breaking up networks logically so that if one device is hacked an attacker can't easily get to all devices) can help limit the damage from vulnerabilities that stay unpatched. For devices that are EOL and won't be getting any more patches, segmentation may be the only defense!
What to do this week
Change the clock. Track vulnerabilities from advisory to fix verified on the device, and stop reporting tickets closed.
CISA's Known Exploited Vulnerabilities catalog is free, so use it: match it to the devices/equipment you own (if you can't do this, you now have a project). Then sort the matches by when the CVEs were published and note how many are 10+ years old and/or sit on devices/equipment that are end of life. For the latter, next to each write down "replace" or "isolate" along with a date and a name.
Take the last critical security advisory and track it to the last device/equipment it applied to. Note where the process broke down. You now know where to start writing your first playbook.
Resist the urge to buy that vulnerability scanner until you know who will be responsible for ingesting, analyzing, and acting on the results. If that person/team doesn't have bandwidth to do so, spend the money downstream instead.
Anthropic's dashboard counts fixes released. I don't know of anyone publishing a count of fixes installed, and that is the number attackers care about. Start keeping yours.
