Cybersecurity briefing
/
feb 16, 2025
AI Finds Vulnerabilities Faster Than Companies Can Fix Them
Anthropic's Glasswing partners found 129,000+ verified flaws. Discovery is speeding up; the bottleneck is turning findings into tested fixes.
/
AUTHOR
Jeff Dyer
Overview
Anthropic’s latest cybersecurity announcement puts a large number on a problem that security executives are beginning to confront: finding software flaws is getting easier, while fixing them still requires decisions that reach well beyond the security team. The company says its Project Glasswing partners uncovered at least 129,000 verified vulnerabilities between April and July. As access to those capabilities expands, the question for businesses is how much of that discovery they can turn into safer software.
The distinction matters because a successful search creates work. Every credible finding introduces another decision about affected systems, engineering effort, operational risk, and the consequences of leaving a weakness in place. AI can compress the search. It does not automatically compress those decisions.
A discovery count leaves the harder question unanswered
In its October 6 announcement, Anthropic expanded its Cyber Verification Program into three access tiers for qualifying security professionals. Alongside the partner findings, it reported another 5,500 verified vulnerabilities from its own open-source scanning. More than 33,000 findings had been rated critical or high severity.
Those are company-reported results, with partial reporting and differing triage methods. Fewer than half of participating partners disclosed patched totals. The figures therefore demonstrate discovery capacity more clearly than completed risk reduction. They do not establish how many organizations are exposed or how many flaws attackers are exploiting.
The business implications extend beyond buying a more capable model. Security teams can increase the number of findings entering a queue without increasing the number of engineers available to investigate and resolve them. A discovery program that succeeds on its own terms can leave the organization with a larger backlog and a less clear picture of where to concentrate effort.
The same flaw can carry very different consequences
Verification establishes that a defect exists under the conditions tested. Its importance to a particular organization depends on how the affected software is built, configured, deployed, and used.
Consider a vulnerable library distributed across several applications. One application may invoke the affected function in a service exposed to untrusted input. Another may contain the same library without ever using that function. Both can appear in a scanner’s results, but they do not necessarily present the same immediate exposure. A third application may depend on the library through another package, making the corrective change more complicated than a version upgrade suggests.
That distinction does not make unused vulnerable code harmless in perpetuity. Deployment conditions change, dependencies evolve, and assumptions can be wrong. It does mean that a severity score alone provides an incomplete basis for deciding which engineering team should stop its current work.
For a hospital, financial institution, or manufacturer, the decision also includes service continuity. An urgent update can affect an integration, interrupt a critical process, or introduce a regression. Those operational costs help explain why a verified flaw can remain unresolved even when everyone agrees it should eventually be fixed.
AI can investigate the queue it helps create
The next application of AI is consequently taking shape downstream of discovery, in the investigation required to separate a credible finding from a material exposure. That involves examining source code, dependency usage, runtime conditions, and network access rather than repeatedly sorting the same list by severity.
Seemplicity, an exposure-management vendor, is applying AI to that work. In its description of its AI Analysts, the company distinguishes code reachability, dependency usage, and host exploitability investigations. Its Code Analyst examines connected repositories, its SCA Analyst evaluates whether affected dependencies are used and reachable, and its Host Analyst examines runtime configuration and network conditions. The findings carry a reasoning trail into remediation workflows.
As the supply of verified defects grows, the pressure shifts to establishing which ones matter in an organization’s own environment. Automating portions of that investigation can reduce the repetitive analysis between receiving a finding and assigning useful work. It also gives engineers evidence to evaluate, rather than another unexplained priority score.
This is a different task from discovering a new flaw or automatically repairing an entire codebase. The quality of the investigation depends on the source and runtime information available. Engineering review and testing remain part of determining whether the proposed change resolves the weakness without creating another problem.
One corrective change may resolve many findings
The unit of work creates another bottleneck. Security tools often describe vulnerabilities separately, while engineering teams make changes to packages, images, services, and releases. Several findings may disappear after one dependency upgrade. Conversely, one vulnerability may require different changes across applications with different owners and build processes.
Seemplicity’s exposure platform groups related findings, incorporates ownership and business context, and routes work into existing operational systems. That matters when discovery volume rises because the number of findings need not equal the number of independent remediation tasks. Grouping work around the corrective change can spare engineers repeated tickets while preserving the underlying evidence.
A closed ticket, however, is only part of the result. The corrected version has to reach the affected environment, required follow-up actions have to complete, and the exposure needs to be reassessed. Otherwise, a dashboard can show progress while an older deployment remains vulnerable.
Capacity becomes a security measure
For executives, this changes what deserves attention. Finding counts remain useful, but they tell little about whether the organization is keeping pace. More revealing measures include time spent establishing relevance, the age of confirmed exposures, delays in assigning ownership, and the interval between an approved fix and verified deployment.
The practical starting point is understanding those delays in the existing process. Some organizations will find that investigation consumes most of the time. Others will discover that ownership is unclear or that approved changes wait weeks for a release. The appropriate response follows the bottleneck, rather than the appeal of adding another AI tool.
Faster discovery gives defenders an opportunity to remove weaknesses before they are exploited. Realizing that opportunity requires the rest of the organization to absorb the work. The meaningful measure of progress is how quickly credible evidence becomes a tested change in the systems that matter.
/
BLOG
