Blog

Mythos breaks remediation math. But your remediation model was already due for it.

Rebecca Banks

July 28, 2026

TL;DR

  • Anthropic's Claude Mythos, restricted from public release over cybersecurity concerns, is now publicly available. The offensive capability gap it represents is no longer theoretical.
  • AI-assisted development has already deepened enterprise software estates faster than security programs were built to track; Black Duck's 2026 OSSRA report found mean vulnerabilities per codebase doubled to 581 year over year.
  • Project Glasswing's first month found 23,019 vulnerabilities across 1,000 open-source projects, with less than 1% patched. The bottleneck is remediation, not discovery.
  • Reachability and exploitability are the filters that matter for triage, but applying them at scale across a growing dependency graph requires instrumentation most programs don't have.
  • The fix is structural: open source governance at the package level, with defined ownership and measurable remediation throughput, not better scanning.

Anthropic's April announcement that Claude Mythos was too dangerous for public release turned out to be a preview, not a permanent position. The model is now publicly available.

The security community spent the intervening months debating what Mythos can do. That conversation is largely settled. It can find exploitable vulnerabilities from a simple prompt. It can generate complete, working exploits. It does this faster than almost any human researcher, and it can be operated by someone with no formal security training.

What hasn't been settled is what that means for how security programs are actually structured. Not threat models. Not tooling roadmaps. The underlying operational model: how findings move to resolution, who owns what, and at what volume, was built for a different environment. Mythos makes the gap between that model and the current reality impossible to ignore.

How AI-Assisted Development Changed What You're Defending

A significant and growing share of production code in most organizations was written, extended, or modified after AI coding assistants became standard engineering practice. That shift didn't just increase development velocity; it also changed the composition of what gets shipped.

AI-assisted development pulls in package dependencies faster, at higher volume, with less deliberate review than human-written code. The average developer using an AI coding assistant isn't auditing every package the model reaches for. They're accepting working code. The result is software estates that are deeper, faster-growing, and less fully mapped than they were five years ago, and security programs sized and structured for a different rate of change. Black Duck's 2026 OSSRA report puts numbers to it: mean vulnerabilities per codebase doubled to 581 year over year, with the surge attributed directly to AI coding assistants accelerating dependency growth faster than governance can adapt.

But AI-generated code is only part of the exposure. Mythos identified 271 vulnerabilities in Firefox, a codebase with a large professional security team and decades of scrutiny. Those weren't new flaws introduced by AI tooling, they were latent vulnerabilities that had survived years of human review. What Mythos changed was the speed at which they became findable, and once findable at machine scale, the exposure window opens before most organizations have time to patch. New code arrives with more embedded risk than before. Existing code carries latent risk that can now be surfaced faster than remediation processes were built to handle.

Regulatory pressure is arriving at the same time. EU CRA mandatory reporting requirements take effect in September. SEC disclosure obligations are already reshaping how publicly traded companies document software risk. The board conversation about open source exposure is no longer a background agenda item in regulated industries. Security leaders are being asked to answer for it with more specificity than their programs were built to provide.

Why Vulnerability Management Was Built for a Different Inflow Rate

Vulnerability management was designed around one core assumption: that discovery and remediation operate at roughly comparable speeds. That assumption shaped everything downstream. Triage frameworks, SLA structures, team sizing, escalation paths: all of it calibrated for a world where finding a vulnerability required meaningful time and expertise.

The numbers from Project Glasswing's first month illustrated the problem clearly: Mythos flagged 23,019 vulnerabilities across 1,000 open-source projects, with 90.6% confirmed as real bugs. In that same window, less than 1% had been patched. That describes an inflow rate structurally outpacing the remediation infrastructure built to absorb it.

When discovery becomes cheap and fast, the operational question changes. It's no longer "are we finding things?" It's "what is our realistic capacity to move findings to resolution, across our full package dependency surface, without creating an unmanageable backlog or burning out the engineering relationship in the process?"

Three Shifts That Will Define the Next Five Years

The AI-assisted development trend and the AI-accelerated discovery trend are going to compound each other. More code will ship faster, carrying deeper and less visible dependency graphs. More of that surface will become findable, faster, by models that don't need a security researcher's expertise to operate them. The gap between how fast software estates grow and how well they're governed is the defining security problem of the next five years.

A few specific things follow from that.

Provenance will matter more than it ever has. Mythos has already surfaced vulnerabilities that survived 16 years of human review and five million automated tests. Those vulnerabilities existed before Mythos. Open source packages that enter a software estate without clear origin, maintenance history, or ownership carry a fundamentally different risk profile in a world of AI-speed discovery. That's not an argument for avoiding open source. It's an argument for knowing what you're running and being able to act on it when something in that inventory becomes a liability.

Remediation throughput will become the metric that matters. MTTR is a useful program health indicator, but in a higher-volume environment it understates the problem. Most security teams managing a real backlog already know that raw CVE counts are noise. What cuts through is reachability and exploitability: whether a vulnerable code path is actually callable in your environment, and whether a working exploit exists in the wild. Those two filters separate a finding that needs attention this sprint from one that can wait.

The problem is applying them at scale across a dependency graph that's growing faster than it's being reviewed. Throughput, meaning how many credible, reachable, exploitable findings move from identified to resolved per unit time, is the metric that will define program maturity in this environment. Programs that can answer that question concretely have something to manage. Programs that can't are carrying unknown exposure by default.

The accountability gap between security and engineering will close, voluntarily or otherwise. AI-assisted development is a business decision that most engineering organizations made without security having a vote. The downstream consequences: deeper dependencies, faster shipping, less visibility, land on security's balance sheet. Only 12% of organizations are currently tracking AI-generated code with the same provenance policies as traditional packages, despite the majority being aware of the risks. Security leaders who get ahead of that conversation and build a shared prioritization model with engineering before a high-severity incident forces it will be in a different position than those who don't.

Why Governance at the Package Level Is the Foundation

The programs best positioned for this environment share one characteristic: they treat open source governance as an operational function with defined ownership, rather than a compliance activity.

The practical starting point is less complex than it sounds: map what's running against who owns it, at the package level, including transitive dependencies. That mapping provides a clear foundation everything else builds on. Without it, a finding has no clear route to resolution. Triage decisions get made without full context. Remediation stalls at the ownership question rather than the technical one.

From there, the question is throughput. Given your current team structure and engineering relationship, how many findings can realistically move to resolution in a given sprint cycle? That number, whatever it is, is your actual capacity. Knowing it lets you make real decisions about prioritization, automation, and where the organizational model needs to change.

That's the problem ActiveState was built for. Curated Catalog gives security and engineering teams a continuously maintained, source-built inventory of open source packages, with vulnerability patching handled before CVEs ever land in your queue. The governance function is structural, not supplementary.

Anthropic has acknowledged that securing critical infrastructure at this scale may take years, while frontier AI capabilities are advancing over months. That gap won't close through better tooling alone. It closes through organizations that have built the governance model to match the environment they're actually operating in.

Mythos is a forcing function, but the rebuild it's forcing was already overdue. Organizations that treat this as the reason to start recalibrating, rather than another threat to monitor, will look structurally different in five years.

Rebecca Banks is Senior Product Marketing Manager at ActiveState, where she leads go-to-market strategy for software supply chain security. She is currently a contributor to the Linux Foundation and OpenSSF 2026 AI Security Study on global AI security maturity for enterprises and critical infrastructure organizations.

Frequently Asked Questions

What is Claude Mythos and why does it matter for enterprise security?

Claude Mythos is Anthropic's most capable AI model, initially withheld from public release due to its ability to autonomously find and exploit software vulnerabilities. It can generate working exploits from a simple prompt, without requiring formal security expertise. Its public availability means those capabilities are no longer limited to vetted partners, which changes the threat calculus for any organization with unpatched open source dependencies.

Why is open source vulnerability remediation so slow even when vulnerabilities are known?

Discovery and remediation have never operated at the same speed, but the gap was manageable when humans were doing the finding. AI-speed discovery floods the queue faster than teams can triage, own, and patch findings. The bottleneck isn't tooling. It's organizational: unclear package ownership, undefined SLAs for transitive dependencies, and no instrumented measure of actual remediation throughput.

What is reachability and exploitability, and why do they matter for CVE triage?

Reachability refers to whether a vulnerable code path is actually callable in your specific environment; many CVEs affect code that is never executed in production. Exploitability refers to whether a working exploit exists in the wild. Together, these two filters are the most effective way to separate findings that need immediate attention from those that can wait, without relying on raw CVSS scores alone.

How does AI-assisted development increase open source security risk?

AI coding assistants pull in package dependencies faster and at higher volume than human-written code, often without deliberate review of each package's security history or maintenance status. Black Duck's 2026 OSSRA report found mean vulnerabilities per codebase doubled to 581 year over year, attributing the surge directly to AI-accelerated development outpacing governance.

What does "governance at the package level" mean in practice?

It means mapping every open source package running in your environment, including transitive dependencies, against a defined owner responsible for remediation. It means tracking actual throughput (how many findings move to resolved per sprint) rather than just target MTTR. And it means making sourcing decisions at the point of entry, not after a CVE surfaces.