Project Glasswing & Your Open Source Stack

Go straight to an AI summary of this blog post instead

AI is about to outpace how software vulnerabilities are found – but not how they’re fixed.

In April 2026, Anthropic announced Project Glasswing alongside eleven major partners including AWS, Apple, Cisco, Google, JPMorgan Chase, the Linux Foundation, Microsoft, and Palo Alto Networks.

The initiative is built around Claude Mythos Preview, a frontier model that has already found thousands of high-severity vulnerabilities, including bugs in every major operating system and web browser. Some of those flaws had survived decades of human audits – changing the math for anyone shipping software with open-source components.

While access is currently limited, the direction is clear: vulnerability discovery is becoming faster, cheaper, and increasingly automated – and it will not remain restricted to a small group of defenders.

Open source supply chain security has always come down to one question: who is responsible for fixing what – and how quickly it gets done. After Glasswing, AI vulnerability discovery is moving at machine speed while patching is still moving at calendar speed.

This pressure lands across two separate phases of open-source risk: what you install, and what happens after. One is about trust in the package itself. The other is about whether vulnerabilities ever get fixed. Both are about to be stressed in different ways.

And regulators have been clear: if you ship the binary, you own the bug.

Project Glasswing and the CVE Flood Coming to Your Dependencies

Mythos Preview is not a faster scanner. It reasons across complex codebases and produces working exploits, not theoretical findings. Anthropic restricted access to Glasswing partners precisely because the same capability will end up in adversary hands. The window for defenders is narrow, and most teams have not yet adjusted their assumptions.

Two specific consequences matter for organizations that depend on open-source packages.

First, CVE volume is going to climb. Mythos has already surfaced thousands of bugs in well-audited code. The production-grade open-source libraries that have never received that level of scrutiny will see the same treatment as comparable models reach the wider market. Most security teams are already behind on the existing CVE backlog.

Second, the time between disclosure and exploitation collapses. A 30-day patching SLA was built around the lag between a CVE going public and a working exploit existing for it. Mythos closes that lag in one session.

If your patching strategy assumes a steady, manageable flow of CVEs in actively maintained packages, both halves of that assumption are about to break.

To put it in a nutshell:

Vulnerability discovery is accelerating
Exploit creation is accelerating
Patching speed is not

That gap is where risk compounds.

You Own Every Dependency You Ship

The regulatory shift has been quieter than the AI announcement, but it is just as consequential.

Under the EU Cyber Resilience Act, manufacturers are responsible for the security of products with digital elements throughout their entire support period, including all integrated open-source components. Penalties reach €15 million or 2.5% of global annual turnover. The manufacturer is the entity placing the product on the market. It does not matter who wrote the dependency, whether the maintainer is paid, or whether the upstream project has been abandoned. If you ship it, you carry it.

FedRAMP guidance has moved in the same direction. Cloud service providers are expected to maintain the security of every component in their authorization boundary, with documented patching processes and EOL software flagged as a known authorization issue. Under FedRAMP 20x, SBOMs that match what’s actually running are becoming a baseline requirement.

Customer contracts have caught up too. Procurement teams now ask for SBOMs, VEX documents, and patch SLAs as standard line items. “We use a third-party library” is not an answer when an exploit hits production.

The legal model is simple to summarize. Liability moves with the binary, not with the source code license. The “many eyes” defense never worked legally, and after Glasswing it does not work technically either.

Open Source Carries Two Distinct Risks

Open source ships into your stack with two separate risks attached. The first is supply chain integrity: what’s actually inside the package the day you install it. The second is patching: how fast a known vulnerability gets fixed, and what happens when no fix is coming.

These are different problems with different threat models. Supply chain attacks are a credential and trust issue. Glasswing has nothing to do with them, and they have been escalating on their own track for years. Patching is where Glasswing changes the math, both during active maintenance and after EOL. The combination is what’s new. The same security team that was already absorbing a steady supply chain attack rate is now absorbing a faster, larger CVE flood across the entire dependency tree.

Liability doesn’t care which problem hit you. Now let’s walk through each in turn.

The Day-One Threat: Compromised Packages

<br />

The first risk in any dependency is what’s inside it the day you install it. Tampered artifacts, hijacked maintainer accounts, and typosquatted lookalikes have been arriving in production through trusted-looking registry installs for years.

The March 2026 Axios compromise is the most prominent recent example: credentials stolen from the project’s primary maintainer, a malicious postinstall hook delivered to roughly 100 million weekly downloaders for three hours.

Other recent cases include the Shai-Hulud worm and the Bitwarden CLI incident that targeted AI coding tool credentials.

This category runs on its own track. Glasswing doesn’t make npm supply chain attacks easier or harder, and Mythos can’t help an attacker compromise a maintainer’s account. But the threat has been escalating for years on attacker incentives alone, and under the CRA it lands in the same liability bucket as anythng else you ship. Detection happens in hours after the fact.

Prevention requires a package source that’s verified, signed, and rebuilt from auditable source rather than pulled directly from a public registry.

The Patching Gap Threat: Active and EOL

Supply chain attacks are about who controls the artifact. The patching gap is about something different: how fast a known bug in an honest, untampered package gets fixed in code you run.

It shows up in two forms – slow patches on maintained libraries, and no patches at all on end-of-life (EOL) ones. Glasswing makes both worse.

When Patches Arrive After Exploits

Time-to-patch varies widely across the ecosystem. Top-tier projects with coordinated disclosure ship the patch when the CVE goes public. The long tail moves slower: hours for trivial fixes, weeks or longer when the maintainer has to backport, preserve API compatibility, or fit it around a day job.

Deployment in your environment then adds time on top of whatever the upstream window was.

That window used to be tolerable. Exploit development was slow enough that defenders had a real head start on attackers.

Mythos closes that head start. Discovery and exploitation now happen in a single session, and the capability won’t stay restricted to defenders. Once comparable models reach adversary hands, the patching window becomes an exposure window. By the time the patch lands, the exploit has been in the wild for days.

The package is alive and the maintainer is responsive. None of that helps a system compromised on day three of a fourteen-day patch cycle.

EOL Libraries After Glasswing

The period after the EOL date is the patching gap with no patch coming, ever.

Log4Shell (CVE-2021-44228) is still among the top 10 most-targeted vulnerabilities more than four years after disclosure because Log4j stays embedded in legacy applications nobody wants to migrate. The same pattern plays out across the long tail of unmaintained libraries: known bugs, public exploits, and an installed base too disruptive to upgrade. Datadog’s State of DevSecOps 2026 found that services running on EOL language versions have an exploitable-vulnerability rate of 50%, compared to 31% for supported ones, with the median dependency lagging 278 days behind its latest version.

Now apply Glasswing-class discovery to that population.

A maintained library’s patch eventually ships, even if slowly. When Mythos finds a zero-day in something like Python 3.7, an EOL Spring Framework version, or any of the thousands of npm packages whose maintainer last commented two years ago, the bug is publicly known and forever unpatched. Forced upgrades are the answer everyone reaches for first. In practice, they require breaking-change migrations across application code that has not been touched in years, with regression risk and engineering cost that compliance teams cannot front.

This is where EOL stops being a maintenance issue and becomes a permanent security condition.

In a post-Glasswing world, unmaintained software is not just risky – it is predictably, repeatedly exploitable, with no patch ever coming.

How SecureChain for Open Source Software Closes the Gap

SecureChain for Open Source Software replaces your public package registries with a controlled, continuously secured source. Your developers keep working the way they already do.

Three things change behind a single registry URL:

Every package is rebuilt from verified source

Every package is reconstructed in a hardened, isolated environment from auditable source code. No inherited binaries, no opaque upstream artifacts.

Malware is blocked before it reaches your stack

Every package is analyzed at the source level for malicious code, suspicious install hooks, and known threat signatures before it reaches the registry.

Patches are delivered continuously – even after end of life

SecureChain delivers patches under SLA as new CVEs emerge, including ones our team contributes when upstream falls short. Coverage continues after maintenance ends, on the version you’re already running, with no forced upgrades and code rewrites.

Audit-Ready From Day One

The compliance side of this problem has its own deliverables. Every package SecureChain ships carries SLSA Level 3 build provenance, a signed SBOM that matches the binary you receive, and VEX documents that mark each CVE flagged against the package as either patched in the version you’re running or not applicable to it.

Those three artifacts are what audit and procurement teams actually ask for. SLSA Level 3 provenance proves the package was built from the source you can inspect, in a hardened build environment, and has not been tampered with in transit. The SBOM tells your auditor exactly what is in production. The VEX document tells your scanner what’s been patched and what doesn’t apply to this version, so your team isn’t triaging CVEs that are already fixed.

Add an SLA-backed remediation commitment, and CVE volume going up does not translate into audit findings going up. The paper trail your compliance team needs is generated as a side effect of the patches themselves.

What Your Teams Get Back

Open source remains the right way to build software. The assumption under pressure is that adopting a package is a one-time decision with no ongoing security cost.

SecureChain gives you the speed and flexibility of open source without the risk.

Your team focuses on building products instead of chasing security issues. Your developers keep installing the packages they already use. Your build pipeline points at SecureChain instead of the public registry. Patches keep flowing for the components that matter, including the ones the open-source community has moved on from. Provenance and SBOMs are produced automatically. When the next Glasswing-class disclosure hits, the response is a version bump, not a six-week incident.

You don’t need to replace your stack to reduce this risk – but you do need to change how it’s supported.

The responsibility for what you ship does not move. The work of carrying it does.

Summary