Claude Mythos Preview identified more than 26,000 vulnerability findings across software projects in just a few months, yet only about 10% entered disclosure and fewer than 1% were ultimately patched. The figures come from Project Glasswing and an independent analysis of its public disclosure ledger. The gap shows that discovery now outpaces validation, prioritization and remediation. For business, this matters because faster detection alone does not make software safer.
Why discovery stopped being the limit
Anthropic noted in an early Project Glasswing update that progress was constrained less by finding flaws than by verifying reports, coordinating disclosure and supporting fixes. Some maintainers even asked for slower disclosure rates because they could not process the volume. Discovery has become a pattern-recognition task where models scan large codebases, trace execution paths and flag unusual behavior. Remediation stayed manual, requiring reproduction, impact assessment, regression testing and coordinated release timelines.
Fixing demands context, authority and accountability that automated detection cannot supply. Someone must confirm legitimacy, weigh impact, choose a fix, ensure no regressions appear, communicate with stakeholders and accept responsibility for the outcome. In many open source projects that person is a volunteer balancing maintenance with a full-time job and family obligations. AI can propose a candidate flaw, but it cannot answer for a broken update or a mistimed disclosure.
Pressure lands on an ecosystem that was already stretched before AI-assisted scanning. Open source components are present in 98% of commercial codebases, so most corporate systems depend on small maintainer groups. Those teams long faced limited resources, rising security expectations and growing maintenance burdens. When a model suddenly produces hundreds or thousands of findings against such projects, maintainer capacity becomes the binding constraint on supply-chain security.
What this means for companies using open source
Enterprises that consume open source need remediation capacity that scales with detection, not another scanner. That means funded ownership for triage, testing and coordinated updates, with clear service levels for critical dependencies. Larger firms can staff product security teams and finance extended maintenance for end-of-life components. Smaller firms feel the same backlog more sharply and gain more from consolidating vendors, reducing dependency sprawl and buying maintained builds.
Investment decisions should separate discovery output from risk reduction and verify throughput before buying. Useful questions include validation rate, time from report to tested patch, regression coverage and disclosure coordination. High finding counts without fixes do not lower exposure and can overload internal teams. Support for upstream maintainers, commercial maintenance and deliberate modernization plans matter more than raw scan volume, since rushed migrations often follow neglected lifecycles.
The marker to watch is the Glasswing ledger conversion rate from findings to disclosures to patched releases over the next quarters. If disclosure share rises well above 10% and patched share moves materially above 1%, remediation capacity is catching up. If volumes keep growing while conversion stays flat, security budgets will have to shift from detection toward maintenance and sustained response.
