Supply Chain Attacks Don't Need Zero-Days, And Your ASM Program Can't Keep Ignoring That

Five supply chain campaigns were active concurrently last week, across different ecosystems. All surfaced in recent threat intel. One of them fits the vulnerability management model security teams already know. The other four don’t, and we keep seeing the same thing happen: teams punt them to detection and response because there’s no CVE to act on. That’s exactly how blind spots turn into breaches.

Five Attack Campaigns, Four of Them Don’t Have CVEs

GlassWorm hit Visual Studio Code extensions on the Open VSX Registry. The clever part? Malware hidden using invisible Unicode characters (variation selectors, Private Use Area codepoints) that literally render as blank space in code reviews and GitHub diffs. 22,000+ downloads across four extensions. Three of them were still available days after discovery, which is wild. C2 traffic ran through Solana blockchain transaction memo fields, so good luck with domain-based blocking. No CVE.

Thirty malicious Chrome extensions posing as AI assistants compromised over 300,000 users. Credentials, emails, 2FA codes, all harvested. One specifically went after Meta Business Suite accounts. And here’s the kicker: they operated entirely within Chrome’s legitimate permissions model. Nothing technically “exploited.” No CVE.

Lazarus Group ran GraphAlgo targeting crypto developers through fake recruiter outreach. Trojanized npm and PyPI packages disguised as coding challenges. They built legit-looking company sites, LinkedIn profiles, GitHub repos, the whole trust-building playbook before dropping payloads. No CVE.

The AgreeTo Outlook add-in got hijacked after the original dev abandoned its Vercel-hosted domain. Attackers just…claimed the orphaned URL and served a credential harvesting page through a still-listed Office Store add-in. 4,000+ Microsoft credentials stolen. Microsoft’s add-in architecture checks manifests once at submission and never re-verifies what’s actually being served from the developer’s URL. That’s a design problem. No CVE.

Notepad++ WinGUp (CVE-2025-15556), the bundled updater didn’t cryptographically verify downloads, so MITM attackers could push arbitrary executables. Now on CISA’s KEV catalog, active exploitation confirmed, affects everything before 8.8.9. This one gets a CVE.

Your vulnerability scanner catches that last one. What about the other four?

The Organizational Gap Between Security Teams

We’ve seen this play out enough times to predict it at this point. Supply chain attack hits the news (GlassWorm, the Chrome extension thing, whatever). Vuln management team takes a look, confirms there’s no CVE, and routes it over to detection and response. “Not a vulnerability. It’s malware. SOC’s problem.”

And the SOC does pick it up. Detection rules get written, IOC hunts happen, and EDR telemetry gets reviewed. That work matters. But it’s reactive by definition. You’re looking for proof that the attack already worked.

What nobody’s asking is the proactive question: how exposed are we to this class of attack in the first place?

That’s an attack surface management question. And most ASM programs can’t answer it because their tooling is built around CVEs. These attacks don’t have any.

No CVE ≠ No Attack Surface

Just because there’s no CVE doesn’t mean there’s nothing to measure or reduce. Think about what an ASM program could tell you about this week’s campaigns with the right visibility:

GlassWorm: How many developer workstations have VS Code or VSCodium? Which ones pull extensions from Open VSX vs. the Microsoft marketplace? Any running with elevated privileges? Has the extension inventory shifted in the last 30 days?

Chrome extensions: How many endpoints run Chrome? What does extension inventory look like across the fleet? Which extensions have absurdly broad permissions (“read and change all your data on all websites”) and got installed outside enterprise policy? Any unapproved AI assistant extensions floating around?

Lazarus GraphAlgo: Where’s Node.js deployed? Python? Which of those machines have package managers that pulled new dependencies recently? Are dev workstations actually segmented from production, or does a compromised laptop have lateral movement paths into prod?

AgreeTo: What third-party Outlook add-ins are installed org-wide? When did their developers last update them? Are any pointing to domains that changed ownership or expired? Does anyone even have an inventory of SaaS add-ins?

Every single one of those is a proactive exposure assessment. The kind of thing attack surface management is supposed to do. None of them needs a CVE. All of them reduce risk before the SOC has to go hunting for IOCs.

This is the problem we built Spektion to solve. Not just finding CVEs in your environment (plenty of tools do that), but also giving you runtime visibility into the software that’s actually executing, what it’s doing, and whether it looks like something that belongs there. We’re giving your attack surface management team the ability to actually identify and manage supply chain attack risk, rather than having their organizations rely primarily on post-disclosure detection and response.

The Cost of Punting Supply Chain Attacks to the SOC

When an org defaults to “no CVE, not our problem” in the vuln management program, it creates a structural gap. Detection and response kicks in after initial access. The whole point of attack surface management (shrinking the blast radius before an attack lands) gets thrown away for an entire category of threats.

And this isn’t a niche category anymore. Supply chain attacks through dev tooling, browser extensions, SaaS add-ins, package registries…they’re accelerating. Five simultaneous campaigns in a single week. That kind of density wasn’t normal two years ago. It’s becoming the baseline.

The CVE-based model works fine for Notepad++ WinGUp. CVE gets published, scanners flag it, CISA adds it to KEV, and federal agencies get a remediation deadline. The system works. But it only covers one out of five attacks that hit this week.

The other four exploited trusted distribution channels: Chrome Web Store, Open VSX Registry, npm, PyPI, and the Microsoft Office Store. The software was legitimate until it wasn’t. Permissions were approved until they were abused. Domains were trusted until they got hijacked. There’s no patch for that.

What Needs to Change

ASM programs need to look beyond CVEs, and they need the tools to enable it. That doesn’t mean ditching vulnerability management. It means recognizing that vuln management is a subset of exposure management. Not a synonym for it.

We talk to security leaders about this constantly, and the gap is almost always the same. They’ve got scanners covering known vulns. They’ve got EDR covering endpoint behavior. But the space in between, the proactive visibility into what software is running, where it came from, and whether it should be trusted… that’s where things fall apart.

Here’s what we think ASM programs should be tracking to address supply chain attack risk:

Software runtime inventory, not just what’s installed, but what’s running, with what privileges, and what it can reach. An app that’s installed but sitting dormant is a totally different risk profile than one actively executing with elevated privileges and network access. This distinction matters more than most teams realize, and it’s core to how we built Spektion.

Extension and add-in inventory: browser extensions, IDE extensions, SaaS add-ins, anything that runs third-party code inside a trusted application. These aren’t nice-to-haves anymore. They’re attack surface, full stop.

Dependency freshness and provenance, meaning where packages come from, when they changed, and whether the update chain has integrity. CVE-2025-15556 exists because Notepad++‘s updater skipped integrity verification. How many other update mechanisms in your environment have the same gap but no CVE to call attention to it?

Permission sprawl, specifically, which apps and extensions have permissions way beyond their stated function. Those Chrome extensions that compromised 300,000 users requested “read and change all your data on all websites.” That’s a measurable, auditable exposure. No CVE required.

Bottom Line

Four of the recent five supply chain campaigns will never get CVEs. They’re not software vulnerabilities. They’re trust exploitation, social engineering, and distribution channel abuse. But they are absolutely attack surface problems.

The question isn’t whether your SOC can detect these attacks after they land. It’s whether your attack surface management program can see the exposure before they do.

If your ASM program only speaks CVE, that answer is no. And that gap, between what your scanner covers and what your adversaries actually exploit, is exactly where supply chain attacks live. Adversaries have seen this seam in security programs with ASM and cyber defense, and they will continue to exploit it until it’s closed.

We built Spektion because we lived in that gap for years as practitioners. Runtime visibility into what’s actually running in your environment, not just what has a CVE, is the only way to close it. If that resonates, we can show you how we empower your ASM program to deal with this attack risk.