Why is this a production question?
External validation tests the same systems your customers use. A test that proves a login form accepts injected input is, technically, an attack on that form. Done carelessly, validation can fill logs with alarms, trip rate limits or, in the worst case, change data. Done well, it is the cheapest way to separate real exposures from noise.
What approaches do vendors describe?
Vendors on this site describe three broad approaches. They overlap, and the labels are the vendors'.
- Non-intrusive simulation. IONIX describes "non-intrusive exploit simulations" that confirm exploitability without running a full attack.
- Large libraries of black-box tests. CyCognito describes more than 100,000 unauthenticated tests across more than 30 categories, designed with no brute force and no state changes.
- Agent-based exploitation. watchTowr describes automated red teaming with eight agents, from web applications to credential stuffing and DNS. Hadrian describes agentic AI that exploits issues to prove impact.
Deeper approaches produce stronger proof and need more care. Lighter approaches are easier to approve and may miss chains of weaknesses that only a fuller attack reveals.
What should you agree before the first test?
Write it down, even if the vendor's defaults look sensible.
- Scope. Which assets may be tested: only confirmed, owned assets, or also candidates still being attributed? Testing an asset that turns out to belong to someone else is a legal problem, not a technical one.
- Depth. Which test categories are allowed? Credential stuffing and anything that writes data deserve an explicit yes.
- Timing. Continuous, scheduled or on demand? Are there freeze windows, such as end of quarter for finance systems?
- Identification. Can your security operations team recognise the vendor's test traffic, for example by source addresses, so a test does not trigger an incident response?
- Stop rule. Who at the vendor and at your company can halt testing, and how fast?
- Evidence. What does the tool record as proof: a request and response, a screenshot, a description? Proof you cannot show an owner is weak proof.
How do you judge a vendor's safety claims?
Ask for the documentation behind the label. "Non-intrusive" and "safe" are design goals; the useful detail is what the tests do not do, such as no brute force, no state changes or no data exfiltration, and how the vendor handles a test that behaves unexpectedly. Ask also whether testing pauses automatically for assets whose ownership is uncertain.
Where does this show up in our scores?
The proves exploitability criterion rewards specific documentation of how proof is produced. Tools that describe attack-style testing in detail score highest; tools that infer risk from versions and severity scores, without a test, score lowest. Safety is not scored separately, because vendors rarely publish enough to compare it. It belongs in your proof of concept, covered in lesson 10.