How is validation different from scanning?
A scanner infers risk. It reads a version banner or a configuration, matches it to a list of known vulnerabilities and assigns a severity. Validation sends a test and checks the response. The difference matters because many version matches are not exploitable in practice: a control may block the path, a backported fix may be in place, or the vulnerable feature may be switched off.
How do ASM vendors validate?
Methods differ, and each vendor describes its own. IONIX describes non-intrusive exploit simulations. CyCognito says it runs more than 100,000 unauthenticated black-box tests without brute force or state changes. watchTowr describes continuous automated red teaming with attack agents. Hadrian describes agentic testing and says it proves exploitability within 15 minutes; that is a vendor claim we have not verified.
On our validation criterion, watchTowr and Hadrian score 9, IONIX and CyCognito 8, Cortex Xpanse, CrowdStrike EASM, Censys ASM, Tenable ASM and Rapid7 Surface Command 5, and Microsoft Defender EASM 3. See the score matrix.
What does validation not prove?
- A negative result is not a clean bill of health. A control may block the test payload but not a variant of it.
- Unauthenticated tests do not see flaws behind a login.
- A result is true at the time of the test. Assets and code change.
- Validation says nothing about attacker interest. For that, use threat signals such as CISA's KEV catalog and FIRST's EPSS.
What should you ask a vendor?
Ask what traffic each test sends to production, who approves testing on sensitive systems, how inconclusive results are reported, and whether the tool retests after a fix.
Terms in this lesson: Exposure validation, Adversarial exposure validation, Automated red teaming, KEV, EPSS
Sources: IONIX, Exposure Validation, CyCognito, Active Security Testing, watchTowr, Platform, Hadrian, Technology, CISA, Known Exploited Vulnerabilities catalog, FIRST, EPSS