Why EASM is still fundamentally broken in 2026.

The category problem

External Attack Surface Management — EASM — was named around 2019 and the major analyst quadrants in the space crystallized within 18 months. The category is younger than most of the products selling into it. The marketing maturity has run ahead of the technical maturity.

I want to be careful here. I'm not going to write the kind of competitor takedown piece that ages badly. Wiz is a credible company. Snyk has shipped real product. Censys has the best DNS infrastructure work in the industry. GitGuardian invented the in-repo secret-scanning category and runs it well. These are not bad products.

What I am going to say is this: the category as defined leaves half the actual external attack surface out of scope, and the incumbents have organizational reasons not to fill that gap.

This article is the field notes from rebuilding the category from scratch.

What incumbents cover well

Network-side discovery: DNS records, certificate transparency logs, port banners, subdomain enumeration, web fingerprinting. Censys is excellent at this. Wiz acquired Gem and integrated cloud-asset graphs alongside. Defender EASM does the Microsoft-shop version. RunZero does the unmanaged-device version. All credible.

In-repo secret scanning: regex patterns against git history, false-positive filtering, pre-commit hooks, PR-time scanning. GitGuardian is the dominant player here and they're good at it. I'm not building to displace them.

Vulnerability inventory: CVE matching against detected software versions, CVSS scoring, EPSS-weighted prioritization. Standard.

These three legs are well-served. If your operating model needs only these three legs, your problem is solved by existing products. You don't need BleedWatch.

What incumbents leave on the floor

This is where the category breaks.

Build-artifact deep scan. What's in your published Docker image? Your NPM package tarball? Your PyPI wheel? Your mobile binary on the public app stores? None of the big incumbents read these artifacts byte-by-byte. They read the repo that built the artifact and they assume the build was clean. The build is almost never clean. Layer 4 of acme/api:prod-2026-05-01 contains an AWS_ACCESS_KEY_ID. Layer 2 of enterprise/web:latest contains a sourcemap that rebuilds an internal API host. The category calls these "supply chain" and gestures vaguely. They are concrete artifacts. We read them. Almost nobody else does.

Sourcemap and asset leak. Published JavaScript bundles ship with .map files that, when the build is misconfigured, expose internal hostnames, feature flags, auth flow logic, and occasionally hardcoded fallback secrets. These files are public. They are not scanned by the EASM category because they fall through the gap between "code" (which is in git) and "infrastructure" (which is DNS-shaped).

AI agent posture. Your team's CLAUDE.md, AGENTS.md, .cursorrules, MCP server configurations, prompt-injection paths — none of this existed three years ago, none of it is part of the incumbents' product roadmap because their product was defined before the category needed to include it. We built AgentGuard for this. We didn't invent the category, we noticed nobody was working in it.

Kill-chain correlation. Every incumbent will give you a list of findings. Almost nobody promotes a list into a chain. The leaked Docker key + the workflow that uses it + the AWS role with iam:* is one finding that says "if this gets popped tonight, here's the blast radius." Treating it as three separate alerts in three separate queues kills your security team faster than the actual breach would.

Why the gap persists

This is the harder question. Why hasn't Wiz built Docker layer scanning? Snyk already has the CI/CD foothold — why don't they ship registry crawls? Censys has the infrastructure — why no AI agent posture?

My read: each incumbent has a product-shaped reason not to. Wiz is a CSPM-first company; cloud configuration is their center of gravity and Docker layer scanning is an inside-out problem, not an outside-in problem, even though the artifact ends up on the outside. Snyk is developer-first; they don't want to expand into operational scanning that doesn't sit in the IDE. Censys is infrastructure-first; their org structure isn't built to scan code-shaped artifacts.

These are real constraints. None of them are stupid. They mean a specific kind of competitor — small, opinionated, willing to scan artifacts other people consider "out of category" — has an open lane. That's where BleedWatch sits.

What "fundamentally broken" actually means

The category isn't broken because the incumbents are bad. The category is broken because the definition of EASM was set when the surface was simpler.

In 2019, "external attack surface" meant network-side. By 2022 it meant network-side plus some cloud configuration. By 2024 it meant network-side, cloud configuration, and some supply chain. By 2026 it needs to mean all of those plus everything your team publishes — packages, layers, sourcemaps, AI configurations, MCP servers — and the correlations between them.

The category definition will catch up. Some incumbent will acquire a Docker-layer-scan company and rebrand the category. Some other incumbent will ship AgentGuard equivalent and call it a 2027 feature. That's fine. The point is that the gap exists now, and the customers who need it filled now can't wait for the analyst quadrants to update.

What this means for your buying decision

If you're a CISO reading EASM RFP responses in 2026, two questions to ask every vendor:

1. "Show me a Docker image you pulled, expanded layer by layer, and found a finding in layer 4. Show me the actual evidence pack." If they can't, they don't scan layers.

2. "Show me a correlation between a leaked credential in a published artifact and a deploy role that uses it. Show me the kill chain card." If they can't, they're selling a list, not a chain.

These two questions are not unfair. They map directly to attacker behavior. An attacker who finds your image will expand it. An attacker who finds a credential will look for what it unlocks. If your scanner doesn't do those two things, your scanner is operating at a layer attackers passed five years ago.

What we're building

BleedWatch isn't trying to displace Censys. It's trying to be the second tool you run, after Censys covers DNS and Snyk covers the IDE, that fills the artifact + correlation gap. If we do that well, the category gets redefined. That's the bet.

If your team is running EASM and you've felt the gap I'm describing, the /scan endpoint takes a domain or a GitHub org and gives you a sample. It's not the full platform. It's enough to show you whether what we surface is different from what you're already getting.