Stenberg’s post is worth reading in full, but the core is simple. Mythos analyzed 178,000 lines of C code. It surfaced five purported vulnerabilities. After review by the curl security team, four were dismissed as false positives or minor bugs. One was confirmed, rated low severity, and scheduled for disclosure with curl 8.21.0.
One. In a codebase with 188 published CVEs on record, continuous OSS-Fuzz coverage and multiple paid audits accumulated over years. Stenberg’s conclusion is direct: the hype was primarily marketing.
I expected the results to be more modest than the framing. I didn’t expect them to be this modest.
Part of what makes this result so telling is the choice of target. curl isn’t a greenfield codebase or an enterprise application where security has been an afterthought. It’s 178,000 lines of C written by 573 people over decades, maintained by someone who has spent years staring at its attack surface. If the case for Mythos being “dangerously good” at vulnerability discovery holds anywhere, it has to hold against something like this. The results say it doesn’t.
Stenberg also noted that earlier AI tools, AISLE, Zeropath, OpenAI’s Codex Security, produced hundreds of bugfixes against curl. Mythos produced one confirmed finding. That comparison appeared nowhere in the coverage that drove the original panic.
The hardest part of being in that crisis cell was arguing for proportionality when the room had already decided the ceiling was catastrophic. The argument i kept making, and kept struggling to land, was that the threat required a specific set of conditions to materialize and that most of those conditions weren’t present in realistic attack scenarios.
What I didn’t have then was a number. Now there is one. It doesn’t prove the risk is zero. It does suggest the ceiling is significantly lower than the threat narrative assumed, and it validates the instinct that the response was outpacing the evidence.
I also kept saying that burning credibility on a threat model nobody had stress-tested would make the next serious conversation harder. That concern hasn’t gone away.
Stenberg is careful not to dismiss AI vulnerability research entirely, and he’s right not to. He says clearly that modern AI analyzers substantially outperform traditional static analysis tools. The roughly twenty bugs documented in the curl analysis have real value even if none rose to CVE level.
There’s also something instructive in what Mythos didn’t find: zero memory-safety vulnerabilities. Stenberg observes that AI tools seem to excel at catching mismatches between code and documentation rather than the class of deep memory-corruption bugs that drive critical CVEs. That’s a more honest picture of the capability than anything in the launch coverage, and it matters for anyone trying to figure out where to actually deploy these tools.
What i’m still thinking about this afternoon isn’t the curl result itself. It’s what the hype cycle cost.
The next time someone raises a serious concern about AI-assisted exploitation, the reeflex in a lot of rooms will be to recall how Mythos was framed. The people who were loudest about it being “dangerously good” don’t get to walk that back cleanly. That credibility doesn’t restore itself.
The views expressed here are my own and do not represent my employer’s official position.
]]>A Software Bill of Materials is an inventory of the components, libraries, and dependencies that make up a piece of software. The nutrition label analogy gets used a lot. You can’t manage what you can’t see, and for a long time software supply chains have operated with almost no visibility into what’s actually in them. An SBOM is supposed to fix that.
After SolarWinds, after Log4Shell, and after Executive Order 14028 mandated SBOM delivery for federal software procurement, the concept became policy. The security community mostly cheeered, which is understandable. Visibility into software composition is a real need. The problem is what got lost in translation: SBOMs became conflated with security when what they actually provide is a list.
Log4Shell is the clearest reason SBOMs gained momentum as fast as they did. When the vulnerability dropped, the first question organizations needed to answer was whether they used Log4j at all, and if so, where. Most couldn’t answer it in hours. A lot couldn’t answer it in days. That’s a genuine organizational failure, and SBOMs address it directly.
If every software artifact ships with a machine-readable inventory of its components, a security team can query that inventory when a new CVE drops and know their exposure immediately. That’s useful. That’s the real case for SBOMs and it’s a solid one.
What happened instead is that this useful, narrow capability got inflated into a supply chain security strategy. Policy mandates and procurement requirements drove adoption withouut anyone doing the harder work of defining what an SBOM actually needs to look like to be useful when it counts.
The most fundamental problem is that most SBOMs are incomplete, and the organizations relying on them don’t know by how much.
A typical generation tool scans a repository or build artifact and enumerates direct dependencies. Modern software doesn’t look like that. Applications pull in transitive dependencies that the tool may not fully resolve. They load plugins at runtime. They bundle vendored code that doesn’t show up in any manifest. They call external services sitting three dependency layers deep.
A comparative review testing Trivy, Syft, Microsoft SBOM Tool, and GitHub Dependency Graph found that three of the four fail to resolve transitive dependencies at all, and all four have significant gaps parsing common manifest formats. A separate analysis against a known set of 105 dependencies found missed components, malformed package identifiers, and incorrect version strings across tools. These aren’t edge cases. They’re what the current generation of tooling produces by default.
The harder issue is that incompleteness is invisible from the outside. You don’t get a warning that your SBOM missed forty transitive dependencies. You get an SBOM that looks complete because it has entries in it.
Even if you had a complete SBOM, it’s only accurate at the moment it was generated.
Dependencies get updated. Build pipelines introduce components that weren’t in the development environment. Container base images get pulled from registries that have changed since the SBOM was produced. In any environment with real release velocity, an SBOM from last week may not reflect what’s running today.
What actually happens in most organizations is that SBOMs get generated once, delivered as a compliance artifact, and never touched again. It’s the same failure mode as firewall rules that accumulate for years without review. You end up with a document that describes a system that no longer exists, and it carries an authority it hasn’t earned. A stale SBOM doesn’t just fail to help. It actively misleads you about your exposure.
Here’s the problem that gets talked about least: even if your SBOM is complete and current, it doesn’t verify anything about the software you’re actually running.
SBOMs are documents. A supplier can generate one against source code and ship a binary built from different source. Someone with access to a build pipeline can swap a component after the SBOM is signed. A vendor can make an honest mistake and omit a dependency added in the final days of a release cycle. None of that shows up in the document.
Closing this gap requires reproducible builds, signed artifacts, and attestation frameworks with real verification on the consumer side. Most organizations have none of that in place. So what they have is a trusted document about an artifact they haven’t actually verified. That’s a meaningful distinction, and it’s largely absent from the policy conversations driving SBOM adoption.
Say you have a complete, current SBOM tied to a verified artifact. You still have to figure out what to do with it.
The standard workflow feeds the SBOM into a vulnerability scanner, which correlates component identifiers against CVE databases and flags known-vulnerable components. In practice this is messier than it sounds. The same library can appear under different identifiers across different SBOM generators: CPE, PURL, package name, with no clean mapping between them. CVE coverage is uneven; many vulnerabilities in open source components go unregistered or get registered months after active exploitation. A 2025 empirical study found that downstream vulnerability scanners produce a 92% false positive rate when applied to SBOM data, mostly because scanners flag vulnerabilities in code paths that are never actually reachable.
Teams learn to tune these alerts out. When you tune out noise at that volume, you end up tuning out real findings too.
SBOMs are worth having. The visibility problem they address is real, and organizations that can’t answer “do we use this library” within minutes of a critical CVE dropping have a genuine gap. I’m not arguing against SBOMs.
What I’m arguing against is treating them as a supply chain security strategy.
The hard parts of supply chain security aren’t listing your components. They’re verifying that the software you’re running matches what was built, detecting when something in the build process was tampered with, and having incident response procedures that are actually tested against supply chain scenarios rather than just endpoint compromises. An SBOM is one input into that work. It doesn’t replace it.
SolarWinds is instructive here. The attacker’s goal was to make a malicious component indistinguishable from the legitimate one. An SBOM generated from that compromised build pipeline would have documented the compromise faithfully, labeled correctly, with all the right metadata. The document wouldn’t have told you anything was wrong.
Reproducible build infrastructure. Binary transparency logs. Signing and attestation with real consumer-side verification. Threat modeling that treats build pipelines as attack surface. Incident response exercises run against supply chain scenarios specifically, not just endpoint compromises.
None of that is easy to mandate in a procurement requirement. That’s partly why we ended up here. The SBOM requirement was achievable, so it happened. The deeper work is slower and more expensive and doesn’t fit neatly into a checkbox.
The risk is that organizations invest heavily in SBOM generation, satisfy the compliance requirement, and remain fully exposed to the attacks that motivated the mandate. That’s not a hypothetical failure mode. It’s where the current trajectory leads if SBOM adoption stays disconnected from the verification and monitoring work it’s supposed to support. The list is not the work.
The views expressed here are my own and do not represent my employer’s official position.
]]>Mythos is an AI system developed by Anthropic with offensive cybersecurity capabilities. Concretely, it can assist with tasks that fall squarely in the domain of offensive security: identifying vulnerabilities, reasoning about attack surfaces, and executing actions that a skilled attacker might perform. It is not a chatbot with a security plugin. It is a system purpose-built to operate in that space.
Access to Mythos is, by design, restricted. This is not a consumer product. Only a handful of organizations have or would have access to it, under controlled conditions. That context matters enormously when evaluating the risks, though it was largely absent from the loudest conversations.
When word spread about Mythos’s capabilities, the reaction was swift and, in many corners, severe. The concerns raised fell into a few recurring categories.
The first was that the model was simply too dangerous to exist in deployable form. The argument: an AI system capable of offensive security tasks represents a qualitative leap in what attackers can do, and no governance framework is mature enough to contain that risk. Publishing it, or even deploying it in restricted form, would set a precedent that others would follow with fewer safeguards.
The second concern was about access concentration. The fact that only select companies would have access was framed not as a safeguard, but as a fairness and power problem. Who decides which organizations are trusted enough? What happens when those organizations are themselves compromised or act in bad faith?
The third, and most technically grounded concern, was about capability uplift: that Mythos would lower the barrier to entry for sophisticated attacks, enabling actors who previously lacked the expertise to execute complex intrusions.
These are not unreasonable concerns to raise. They deserve to be taken seriously, evaluated against evidence, and answered with specificity. What happened instead was something different.
When Anthropic’s Mythos project triggered an internal crisis response, I had a front-row seat. What followed was one of the most instructive, and at times frustrating, experiences i’ve had working at the intersection of AI and security.
I’ve spent enough time in environments where the value of intelligence depends entirely on who holds it and what they can do with it to recognize when a threat is being inflated beyond what the signal actually supports. This post is my attempt to process it honestly, for the benefit of anyone building, deploying, or governing AI systems with cybersecurity capabilities.
The first thing I noticed was how fast the alarm spread, and how little of it was grounded in a concrete threat model.
People were reacting to the existence of a capability, not to a realistic attack scenario. In security, this is a critical distinction. The relevant question is never “could this be misused in theory?” It’s “under what conditions does misuse actually become feasible, and how likely are those conditions?”
For Mythos, the answer is fairly clear: the system poses meaningful risk only if an adversary has access to the source code. Without that, the attack surface is dramatically reduced. Most threat actors, even sophisticated ones, are operating against black-box systems. They don’t have the internals. The panic, in large part, was disconnected from this reality.
This doesn’t mean the risk is zero. It means the risk was being evaluated without the rigor that security decisions require.
One of the most operationally damaging dynamics I witnessed was the absence of a clear decision owner.
When everyone is responsible, no one is. Every stakeholder had opinions. Legal was cautious. Engineering was defensive. Leadership wanted consensus. The result was a decision-making process that moved at the speed of the most risk-averse voice in the room, which in a crisis is rarely the most informed one.
In incident response and crisis management, designated authority matters more than broad agreement. You need someone who can say “here is our decision, here is why, and here is who is accountable.” Without that, you get endless rounds of escalation, hedging, and delayed action, all while the actual risk window either closes or compounds.
If your organization is deploying AI capabilities with security implications, assign ownership before the crisis, not during it.
This is the structural lesson I keep coming back to.
The crisis cell existed because a risk assessment hadn’t been done with sufficient rigor before the capability shipped. When the alarm went off, people were trying to evaluate the risk in real time, under pressure, with incomplete information, and with organizational incentives that biased toward caution regardless of the actual threat.
A proper pre-deployment security review for a capability like Mythos should include:
None of this is novel. It’s standard practice in mature security organizations. The gap is in applying it consistently to AI systems, where the novelty of the technology tends to bypass existing governance processes.
Let me be direct: I don’t think Mythos is a reckless project. I think it got caught in a governance gap, the kind that opens up when a capability advances faster than the institutional processes designed to evaluate it.
The cybersecurity capabilities in question are only as dangerous as the access an adversary has to the underlying system. In most realistic deployment scenarios, that access doesn’t exist. The risk, while real, is bounded, and bounded risks can be managed with targeted mitigations rather than broad freezes.
What concerns me more than the capability itself is the precedent set by a crisis response that wasn’t anchored to a rigorous threat model. If we overreact to bounded, source-code-dependent risks, we build a culture where the loudest concern wins, not the most defensible one.
That’s a problem for AI security in the long run.
None of this is an argument for complacency. Mythos operates in genuinely uncharted territory. Offensive AI capabilities are new enough that the boundaries of what’s possible, and what’s exploitable, are not fully understood. That uncertainty is real, and it deserves respect.
But uncertainty is not the same as emergency. And novelty is not the same as unmanageable risk.
What the Mythos crisis cell revealed, more than anything, is that the security community still doesn’t have a reliable reflex for sitting down, thinking clearly, and applying proportionate mitigations when a new AI capability surfaces. The reflex we have instead is to escalate, to freeze, and to let the loudest voices set the tempo. That reflex is understandable. It is also costly.
The work of AI security governance is not glamorous. It’s threat modeling at 9am on a Tuesday. It’s a document that nobody reads until something goes wrong. It’s the uncomfortable conversation about what risk level is actually acceptable, made before deployment, not after. That work doesn’t feel urgent until the moment it becomes the only thing that matters.
Mythos may be new. The playbook for handling it doesn’t have to be invented from scratch every time an alarm goes off. Take the time to sit down. Think through the actual threat model. Apply mitigations that match the real risk. Then move forward.
Panic is not a security strategy.
The views expressed here are my own and do not represent my employer official position. Details have been generalized to respect confidentiality.
]]>