|
Getting your Trinity Audio player ready...
|
Anthropic’s Project Glasswing is generating a lot of attention – most of it focused on what Mythos, the company’s newest model, can do and how to leverage it. The more important question for security leaders, however, is what Glasswing means for vulnerabilities, for remediation, and especially for how the board conversation about cyber risk has to change.
On April 7, Anthropic announced that Mythos had autonomously uncovered – among many, many other flaws – a 27-year-old vulnerability in OpenBSD and a 16-year-old flaw in FFmpeg that five million automated test runs had missed. None of these had been previously found by human researchers. Mythos found them on its own, without guidance, in software embedded across the world’s most critical infrastructure.
Project Glasswing is the initiative Anthropic created following these findings – a restricted consortium of twelve major technology companies (Microsoft, Google, Apple, AWS and others) who can use Mythos to scan and secure critical software infrastructure before the model is made available to a wider audience.
For any organization running that infrastructure – which is most medium and large organizations – each of Mythos’ findings is a business risk waiting to happen. In this blog, we’ll cover what the Glasswing consortium will and won’t solve, and why CVEs are still only part of the conversation your board needs to have.
The Old Model Doesn’t Fit Anymore
Most security programs run on a familiar rhythm: scan, score, prioritize, and patch within a pre-defined SLA. That rhythm made sense when vulnerability disclosure moved at a slower pace and the gap between a flaw surfacing and someone weaponizing it was humanly manageable.
It is common knowledge that it’s no longer the case. Vulnerabilities grow exponentially and there are way too many of them to manage. Mythos just highlighted this by autonomously identifying thousands of zero-day vulnerabilities and exploits. But the Mythos model was developed and is used for defensive purposes and operated within a controlled research environment with pre-defined scope. Security leaders must acknowledge that similar AI capabilities are being tuned for offensive purposes outside of these ethical and scope constraints. Even if attackers don’t run AI-based vulnerability research with the same compute resources, in reality they only need to find a single zero-day vulnerability that is exploitable but has yet to be published and addressed.
The Glasswing partners are building for that window. They’re shifting to memory-safe languages, and running AI-assisted code review before anything reaches production. Cleaner code from the world’s largest vendors is genuinely good news, and may even slow down the growth rate of new CVEs. At the same time, Glasswing covers 12 vendors of the overall software supply chain, and trust chain compromises happen outside code quality entirely.
The Breach Isn’t Coming from Where You Think
The conversation around Glasswing centers on CVEs – how many will surface, how fast they’ll be exploited, how hard they’ll be to patch. Those are legitimate concerns, and the work Glasswing is doing to find and fix flaws in critical infrastructure before releasing it is genuinely valuable.
CVEs still matter. But not as much as many programs assume. Only 1% of 2025 CVEs were exploited in the wild, and many recent breaches traced back to exposures that never had CVE numbers and never showed up in vulnerability scans. Phishing and social engineering are still the number 1 initial access vector and the key for every successful attack. Misconfigured environments, compromised credentials, and AI integrations running with high permissions nobody thought to limit – none of these get a CVSS score, and none of them are on any patch list.
New AI exposures are added to this list. Shadow AI integrations, over-privileged authentication tokens, misconfigurations and over-permissions on MCP servers and other AI infrastructure, and AI agents with write/execute permissions (read about new exposures in AWS Bedrock) are all critical growing exposures. If attackers find less vulnerabilities in critical infrastructure from the largest software vendors, we will see even more breaches leveraging identity exposures and misconfigurations.
When a board asks whether the organization is exposed, they’re not asking about CVE counts. They’re asking whether something critical could actually be compromised. Glasswing makes that conversation more urgent – because it proves that exposures can exist undetected for decades. But it also shows that the tools most organizations rely on to find exposures are not keeping up, and it shines a brighter spotlight on tightening your security posture.
The Human Layer Glasswing Can’t Fix
Glasswing is scanning code. Attackers are scanning people.
The most consequential breaches of the past decade were not won through a CVE. SolarWinds was a trusted software update. XZ Utils was a two-year social engineering campaign against a single open-source maintainer who was gradually convinced to hand over commit access. The 3CX supply chain compromise started with a developer’s personal machine.
The MGM breach, one of the most disruptive in recent memory – began with a ten-minute phone call to the IT help desk. None of these had CVSS scores. None showed up in a vulnerability scan. All of them caused material damage.
This is the layer Glasswing wasn’t designed to touch. And it is the layer attackers will increasingly target as code from the world’s largest vendors gets cleaner.
Phishing and social engineering remain the dominant initial access vector, not because defenders are unsophisticated, but because they work. When an attacker can impersonate a trusted vendor, a colleague, or a help desk agent, they don’t need a zero-day. They need a convincing email and thirty seconds of inattention. The Glasswing project, finding and fixing thousands of vulnerabilities in critical infrastructure, does nothing to change that equation.
What it may do, inadvertently, is accelerate the shift. If critical software becomes harder to exploit through code vulnerabilities, the path of least resistance moves further toward identity, trust, and human compromise. Attackers adapt. They already have.
The supply chain dimension compounds this. Glasswing’s twelve “alpha” members represent a fraction of the software dependencies running in any medium or large organization. The thousands of vendors outside that consortium, many of them smaller, moving faster with AI coding tools, without equivalent security gates, remain fully exposed. And for those vendors, the threat isn’t just a coding flaw. It’s a compromised developer, a malicious dependency inserted into a trusted package, or a build pipeline that was accessed through a phished credential.
Security leaders preparing for a board conversation about Glasswing need to be ready to answer a question the project doesn’t address: how are we protecting the humans and the trust chains that sit underneath the code?
What Your Program Actually Needs Now
Security programs were built to manage CVE volume, but they will not help you fix what they do not cover. A program that receives more CVE input and runs it through the same pipeline is still blind to misconfigured identities, over-privileged service accounts, and AI exposures that can combine into a viable attack path. And those combinations – not any single finding – is what attackers act on. Whether or not you trust Glasswind to clean your critical infrastructure from vulnerabilities, you still own the responsibility to discover, prioritize, and drive remediation of misconfigurations and over-privileged access.
Although the Glasswing partners will ship cleaner code, the thousands of vendors outside that consortium – many of them moving faster with AI tools than their security practices can keep up with – may not have access to the same resources. The net CVE trajectory is still up (Gartner projected over one million CVEs by 2030), which means the prioritization problem will continue to grow, no matter what. CVSS scores carry no information about whether a vulnerability is exploitable in YOUR environment, nor whether an attacker can use it to compromise critical assets.
Security leaders know that when the board asks whether the organization is exposed, “we’re working through our CVE backlog” doesn’t cut it. And in any case, finding an exposure is only half the problem. Knowing whether it’s exploitable and reachable in your environment, whether security controls will block it, and whether it compromises critical business assets is the basics of Continuous exposure Management.
No Assumptions. No Noise. No Blindspots.
Summary
When the board asks you about the impact of the Glasswing project on your risk level, the wrong answer is a CVE count. The right answer is a business scenario: which attack paths in your environment lead to your most critical assets, whether they are exploitable today, and what the financial exposure looks like if they are. That means translating your exposure posture into expected loss, not patch percentages.
Three questions worth bringing to your next board conversation:
- If an attacker compromised our three most critical systems today, not through a CVE, but through a stolen credential or a misconfigured AI integration – what would the business impact be, and do we have that modeled?
- Of the AI tools currently operating in our environment, how many have been through a formal security review, and what permissions are they holding?
- Glasswing covers twelve vendors. How many vendors are in our software supply chain, and what is our detection capability if one of them ships a compromised update?
Do you need help to prepare for this discussion? Talk to us.
