A Web Scanner Pointed at an Internal TLS-Only Service Is a Cost Center
Run a web DAST against a TLS-only network endpoint and you get nothing useful — the DAST is looking for HTTP-shaped vulnerabilities on something that does not speak HTTP. Run a container scanner against a serverless function and you get irrelevant findings — the container scanner expects an image layer that does not exist. Run a static analyzer against a compiled binary and you get nothing — there is no source to walk.
Each of these is a misdirected scan. Each consumes scanner time, queue capacity, and analyst attention that could have gone to the right capability on the right target. And each is the most common cause of the most common complaint about security tools: “It is too noisy.”
The noise is not random. It is the predictable output of a dispatch model that does not know which capability fits which surface. Surface-aware orchestration is the architectural fix.
What Surface-Aware Dispatch Means
A surface-aware platform makes one structural decision differently: instead of asking “which capabilities should I run?”, it asks “which capabilities fit this surface?” and only those run.
That sounds obvious. It is not. The legacy CTEM model — and most current “CTEM platforms” still — operate on a different default. Their dispatch model is spray-and-pray: every capability runs against every discovered asset, with the platform later filtering out the false positives that come back. This works only in the sense that eventually the right findings reach the queue. The cost is enormous: every capability pays a noise tax on every asset that does not fit its scope.
Surface-aware dispatch inverts the model. Each capability is mapped to one or more surfaces — web, API, network, cloud, code, container, identity, mobile, AI/LLM, OT — and only fires against assets tagged for those surfaces. The dispatch table is explicit, auditable, and operator-editable.
The result is not subtler signal. It is more signal at lower cost. The web DAST never wastes a cycle on a non-web target. The container scanner never produces a false positive on a serverless function it should never have touched.
The Ten Surfaces and the Capabilities That Fit Them
The surfaces that matter in 2026 are not theoretical. They are the ones attackers actually use to enter, traverse, and exploit modern enterprise environments. A credible CTEM platform has explicit coverage for all of them:
- Web — Active scanning, DAST, technology fingerprinting, content + parameter discovery
- API — Schema-aware probing, OpenAPI drift detection, auth-flow testing, stateful fuzzing
- Network — Port and service mapping, TLS posture, edge scan, DNS posture
- Cloud — Misconfiguration audit, IAM relationship walks, internet-facing resource detection, cross-account discovery
- Code — Static analysis, secrets detection, IaC posture, dependency posture, SBOM generation
- Container — Image CVE scanning, runtime drift, admission policy, hardening benchmark
- Identity — Over-permission detection, credential leak monitoring, OAuth grant audit, non-human-identity discovery
- Mobile — Binary analysis, runtime posture, package leak detection
- AI / LLM — Prompt-injection probing, RAG context fuzzing, shadow-AI discovery, model exposure scanning
- OT / ICS — Industrial protocol fingerprint, exposure check, vendor advisory mapping
This is not the comprehensive list every vendor wants. It is the realistic surface list a CISO needs to defend in 2026. The first nine cover the majority of enterprise breach paths. OT/ICS is honest about its niche scope.
A platform with explicit dispatch across these surfaces produces an asset-graph-aware scan plan: for each asset, only the capabilities that fit get dispatched. For each capability, only the assets that fit get queued. The capability set and the asset graph become the same operational object.
Why Event-Driven Dispatch Is the Other Half
Surface-aware dispatch fixes which capabilities run. Event-driven dispatch fixes when.
The legacy operating model is scheduled scans — full sweeps run weekly or monthly. The platform discovers everything every cycle, even though most things have not changed. Bandwidth, analyst attention, and validation budget get spent re-confirming what was already known.
Event-driven dispatch is the inversion: scans fire on the events that actually changed risk. A git push to a watched repository triggers code + secrets + dependency validation on the affected service. A CISA KEV entry triggers an affected-version sweep across in-scope assets. A new certificate in a CT log surfaces a new subdomain and queues a first-pass scan within minutes. A cloud-provider event for a new resource triggers a misconfig + IAM check before production traffic touches it.
The scheduled full sweep still runs, but as a baseline — and what the operator sees is the delta against the baseline, not the entire report each time. The signal-to-noise ratio is structural, not the result of a filter on the output side.
The Operational Wins That Show Up Within a Quarter
Three observable changes follow when a security program switches from spray-and-pray to surface-aware orchestration.
Queue depth drops. Findings that should never have been produced — the misdirected scans, the irrelevant findings, the duplicate detections from overlapping capabilities on the wrong surface — never enter the queue. Analyst triage time shifts from filtering noise to evaluating real signal.
Capability cost drops. Capabilities consume compute, network, and operator-time — even when they happen to be free of license cost. Targeted dispatch can cut runtime substantially by avoiding runs that were always going to produce nothing useful.
The “is this finding for me?” question disappears. When findings arrive tagged with the surface they belong to, the routing question answers itself. Web findings go to the web team. API findings go to the API team. Identity findings go to the IAM team. The platform does not have to guess; the dispatch model already encoded the answer.
The Question Worth Asking Your Current Platform
Ask the dispatch question directly: “What is your capability-to-surface mapping?”
The expected answer is a table. Every capability mapped to one or more surfaces. Every surface backed by an explicit stack. The dispatch is observable and editable; you can ask the platform why a capability fired against a particular asset, and the answer is a row in the table, not a black box.
Platforms that cannot produce that table are running spray-and-pray. That is fine, in the sense that it works eventually. It is not what a modern CTEM platform looks like in 2026.
VirtueThreatX is surface-aware end-to-end: explicit capability-to-surface dispatch across 10 surfaces, event-driven triggers, per-tenant isolation, and drain backpressure. See the orchestration deep-dive, read the platform overview, or schedule a 30-minute walkthrough — we will fire a synthetic event during the call and watch the dispatch land, end-to-end.