Safe checks or attack-style testing: how much proof of exploitability do you need?

Why is a version number not proof?

A scanner that sees a vulnerable software version reports a finding. But the vulnerable component may be disabled, unreachable or protected by another control. Treating every such finding as real fills the backlog with work that does not reduce risk.

What are safe checks?

Safe checks test the specific condition that makes an exposure exploitable, without changing anything on the target. IONIX describes non-intrusive exploit simulations. CyCognito describes unauthenticated black-box tests with no brute force or state changes, more than 100,000 of them across 30+ categories.

What is attack-style testing?

Attack-style testing behaves like an attacker: it chains steps together and tries to prove impact. watchTowr describes continuous automated red teaming with eight agents covering infrastructure, web applications, known exploited vulnerabilities, credential stuffing, cloud, sensitive data, third party and supply chain, and DNS. Hadrian describes agentic AI that, by its account, proves exploitability within 15 minutes.

What does each cost you?

• Safe checks are easier to approve for production and run widely. They tell you an exposure is exploitable; they may not tell you how far an attacker could go.
• Attack-style testing gives stronger evidence and can expose paths that checks miss. It needs more trust: you must understand what the tests do, when they run and how they are stopped.

How should you decide?

Start from your answer to two questions. Do engineers accept findings without proof of impact? If not, you need stronger evidence. Does your organisation allow active testing against production? If not, safe checks are the ceiling for now. Many teams use safe checks across the whole estate and attack-style testing on the most exposed services.

What should you ask a vendor?

1. What exactly does a test send, and what can it change?
2. How do you stop a test that misbehaves?
3. How quickly do you test for a newly published vulnerability?
4. Do you retest after we fix something?

What next?

Read exposure validation for which vendors describe which approach, then Retesting and proof of fix.