Discovery Alone Won't Protect You: Confirming "Can It Actually Be Exploited?" with AI Deep Scan
Contents
Vulnerability scanners hand over hundreds of findings a week. Few teams can answer, on the spot, which of those an attacker could actually use.
Finding something and confirming it can be exploited are separate jobs. What follows walks through the second one — AI Deep Scan.
Finding it and confirming it are two different steps
Discovery builds a candidate list from ports, banners, TLS certificates and inferred technologies. A candidate is only a candidate; confirmation of existence is not part of it.
Figure 1: The step that raises candidates, and the step that confirms them
Deep dive: the framework separates them too
CTEM places Validation explicitly among its five stages, because without confirming that a discovered vulnerability can genuinely be exploited, the order of work is not trustworthy. The whole cycle is in What is CTEM?, and attack surface enumeration in our piece on ASM.
Discovery results carry three structural limits
Judging from outside-visible information alone leaves unavoidable error. There are three ways something can look vulnerable while actually being closed.
Figure 2: Three cases the outside view cannot settle
Deep dive: none of these is a false detection
The scanner is not wrong; it simply cannot decide from what is visible outside. So the answer is not to suppress the detection but to add a step that separates the cases.
Skipping validation comes back in three shapes
Handing over an unvalidated list moves the burden onto the people fixing and the people reporting. The heaviest cost is that the alerts themselves stop being believed.
Figure 3: What you skip comes back later
Deep dive: mechanical filtering is not enough on its own
Filtering by EPSS or KEV reduces the count, but it filters on properties of the vulnerability itself. Whether it can actually be exploited on this system only comes from testing against that asset. Reading the individual scores is covered in CVSS, EPSS and KEV.
Remote, non-destructive, and shaped to the target
Taking the target's context into account, an AI writes validation code specific to that vulnerability and runs it remotely. Nothing is modified or deleted, and the result falls into one of three buckets.
Figure 4: Validation resolves into three outcomes
Deep dive: not everything gets actively validated
What qualifies is a vulnerability that can be actively reproduced and whose priority and evidence confidence clear a bar. Being remote and non-destructive, it does not reach past credentials or down destructive paths. The not-verifiable bucket holds cases needing credentials, cases that timed out, and cases that could not be executed at all.
Whether it is enabled is the customer's decision, and execution can be paused and resumed at any time. For a step that actively probes, the control deliberately does not sit with us.
The validation result rewrites the order of work
A confirmed fact is fed straight back into prioritization. What failed to reproduce drops one TDL rank and moves down the list.
Figure 5: Feeding the confirmed fact back into the ordering
Deep dive: it still doesn't leave the list
Failing to reproduce is not proof of absence. The scan path may simply have been blocked, so nothing is deleted; only the rank moves down. The ordering mechanism is covered in TER bands.
- What is CTEM? How it differs from traditional vulnerability management
- What is the Threat Discovery Level (TDL)?
- Threat Exposure Risk: technical risk multiplied by business risk
- CVSS, EPSS and KEV: how to read each score and when to use it
Validating your own external attack surface is free to try for 14 days.
Appendix: outcomes, and what qualifies for validation
Table 1: validation outcomes
| Outcome | Meaning | What follows |
|---|---|---|
| Exploitable | The check reproduced it | Worked first |
| Not exploitable | The check ran but did not reproduce it | Drops one TDL rank, moves to watch |
| Not verifiable | Needs credentials, timed out, could not execute | Routed to manual confirmation |
Table 2: what qualifies for active validation
| Condition | Detail |
|---|---|
| An actively reproducible class | A kind of flaw confirmable remotely and non-destructively |
| Priority above a bar | Sitting high enough in the ordering |
| Evidence confidence above a bar | Detection backing that is not too weak |
| Enabled by the customer | Execution can be paused and resumed at any time |
The question worth asking is not how many vulnerabilities there are, but how many exploitable ones there are and where. Raise candidates in discovery, confirm existence in validation, and concentrate people on what held up — that is how limited hands cover an attack surface.
The outcome categories were checked against PentaTrail's data definitions on 2026-08-17.
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get Started
