Validation · Adversarial exposure validation

Discovery without validation is just a list of maybes.

Continuous Automated Red-Teaming takes the prioritised exposures ShadowMap has already discovered and attributed to you and, where it is safe and authorised, tests them. Not every finding is validated — the method is matched to the class of finding, and anything without a safe probe says so on its face. What comes back is evidence: live status, affected services, blast radius, and the probe history behind it.

Request an exposure snapshot How to evaluate this

app.shadowmap.com/org/acmecorp/cart

Bounded

Targeted only at discovered, attributed inventory

Auditable

Every validation request carries an identifier

8–15%

Of surfaced exposures, validated as exploitable

Read the other number. If eight to fifteen per cent of what discovery surfaces is demonstrably exploitable in your environment, then eighty-five to ninety-two per cent has not been shown to be — and that is a claim about what your team should chase this week, not a claim that the rest is harmless. Untested and safe are different things, and each finding says which one it is.

The category

What adversarial exposure validation actually means

Gartner calls this category adversarial exposure validation: the step that establishes whether a discovered exposure can be used against you. It is the difference between a finding and a fact.

A scanner reports presence — this host answers, this version matches, this banner appears. Validation asks the next question: with this exposure, on this asset, right now, what can actually be reached? Continuous Automated Red-Teaming answers it by exercising the exposure within a scope you set, and stopping at the point of proof rather than the point of damage. Where no safe probe exists for a class of finding, or where a target sits outside what you have authorised, the finding stays unvalidated and is labelled that way. That boundary is not a caveat bolted on afterwards. It is the reason the validated set is worth acting on at all.

Scope of testing

Four classes of finding, four ways of testing them

Validation logic is purpose-built per class of finding rather than one generic scanner pointed at everything. These are the classes shipping today — no order among them, because a finding arrives in whichever class it arrives in.

Cloud

Cloud security validation

AWS, Azure and GCP misconfigurations exercised rather than listed — IAM privilege-escalation paths, storage path traversal, and endpoints reachable from the internet that were meant to be internal.

Applications

Web and API testing

OWASP Top 10 coverage against your live applications, with screenshots and reproduction steps. Lighter than a full penetration test, and it runs continuously rather than annually. The abuse that needs someone to understand what your application is for stays with a human tester.

Vulnerabilities

Vulnerability validation

When a CVE matches your stack, the question is whether it is genuinely exploitable in your environment or merely present. A version banner is a hypothesis. A working request is not.

Secrets

Key and credential testing

A key found in a public repository is tested to establish whether it is live and what it opens. A leaked credential is probed to see whether it still authenticates — and where probing is inconclusive, the finding says so instead of guessing.

Boundaries

The controls that bound a live test, published

For a regulated buyer these decide whether adversarial validation may run against production at all, so they sit beside the claim rather than three clicks away — and the same list is published on our security page and written into the service terms, where it binds us rather than merely reassuring you.

Control	What it bounds	Set by
Non-destructive payloads, purpose-built per capability	What a probe is permitted to be. Validation logic is written for each class of finding rather than run from generic public exploit code pointed at your production estate, and automated check layers govern the process.	Platform
This is the row that answers the question the others circle: does it exploit, or does it prove. It is not a posture statement — it is §4 of the service terms and §7 of the security page, which is what makes it something you can hold us to rather than something we assert in a room.
Scan profiles with named exclusions	Hosts, paths and whole environments you name are never touched by active validation. The exclusion is a property of the profile, not a request we remember.	You
The appliance nobody wants to touch, the legacy system inside a maintenance window, the business unit mid-migration: exclude it and passive discovery carries on, so you keep the visibility without taking the probe traffic.
Request-rate limiting	How hard validation may push, per target. Set it low and testing takes longer and touches less — that trade is yours to make, not ours.	You
Scan depth, including a non-intrusive mode	An explicitly non-intrusive depth exists for production systems too fragile to absorb active testing. It validates less. That is the point of it.	You
Targeting bounded to attributed inventory	Nothing is probed that discovery has not already found and attributed to you. There is no free-text target box anywhere in the product.	Platform
Policy and software bound a tester differently. One who can be pointed anywhere is bounded by policy; one who can only reach inventory already attributed to you is bounded by the software, and software does not forget.
Discovery and enumeration precede validation	Passive discovery runs first, always. Active validation only ever runs against a set that already exists in your inventory and has been through attribution.	Platform
Progressive enablement	Adversarial validation is introduced in stages during onboarding rather than switched on at go-live, so the first active test against your estate is never a surprise to your operations team.	Jointly
Per-probe chain-of-custody history	Every probe is recorded — what was sent, when, against which asset, and under which authorisation.	Platform
This is what makes the audit identifier below usable. Reconciliation needs a record on our side to reconcile against, held per probe rather than per scan.

Non-destructive payloads, purpose-built per capability

What it bounds: What a probe is permitted to be. Validation logic is written for each class of finding rather than run from generic public exploit code pointed at your production estate, and automated check layers govern the process.
Set by: Platform

This is the row that answers the question the others circle: does it exploit, or does it prove. It is not a posture statement — it is §4 of the service terms and §7 of the security page, which is what makes it something you can hold us to rather than something we assert in a room.

Scan profiles with named exclusions

What it bounds: Hosts, paths and whole environments you name are never touched by active validation. The exclusion is a property of the profile, not a request we remember.
Set by: You

The appliance nobody wants to touch, the legacy system inside a maintenance window, the business unit mid-migration: exclude it and passive discovery carries on, so you keep the visibility without taking the probe traffic.

Request-rate limiting

What it bounds: How hard validation may push, per target. Set it low and testing takes longer and touches less — that trade is yours to make, not ours.
Set by: You

Scan depth, including a non-intrusive mode

What it bounds: An explicitly non-intrusive depth exists for production systems too fragile to absorb active testing. It validates less. That is the point of it.
Set by: You

Targeting bounded to attributed inventory

What it bounds: Nothing is probed that discovery has not already found and attributed to you. There is no free-text target box anywhere in the product.
Set by: Platform

Policy and software bound a tester differently. One who can be pointed anywhere is bounded by policy; one who can only reach inventory already attributed to you is bounded by the software, and software does not forget.

Discovery and enumeration precede validation

What it bounds: Passive discovery runs first, always. Active validation only ever runs against a set that already exists in your inventory and has been through attribution.
Set by: Platform

Progressive enablement

What it bounds: Adversarial validation is introduced in stages during onboarding rather than switched on at go-live, so the first active test against your estate is never a surprise to your operations team.
Set by: Jointly

Per-probe chain-of-custody history

What it bounds: Every probe is recorded — what was sent, when, against which asset, and under which authorisation.
Set by: Platform

This is what makes the audit identifier below usable. Reconciliation needs a record on our side to reconcile against, held per probe rather than per scan.

Evidence

What a validated finding is — and what happens when you challenge one

A validated finding is not a banner, a CVE match, a scanner signature or a claim that a credential appeared in a leak. It carries the material to act on it, and the material to dispute it.

01 What arrives

The evidence package

Status and reach: Live status at the time of testing, the affected services, and which services are enabled and which restricted on the affected asset.
Blast radius: What the exposure opens — the accounts, buckets, endpoints or environments reachable from it. This is the part that turns a severity label into a decision someone can defend in a change meeting.
Proof and provenance: Screenshots or request-and-response evidence, the probe history behind the finding, and a workflow state, so the finding can be assigned, disputed or closed rather than merely read.

02 Reconciliation

A finding your team does not believe

Your position: Your engineers pull the cloud trail and application logs for the window in question and find traffic they cannot attribute. Nobody should accept a security finding on trust, least of all one produced by automation.
The identifier: Every validation request we send carries an identifier that lands in your own logs. You do not have to take our word for what we did — you can search for it, in your systems, without asking us for anything.
The reconstruction: Matched against the per-probe history, a challenged finding reconstructs exactly: which request, at what time, against which asset, under which authorisation. Handing you the means to audit the tester is the point — a validation programme you cannot audit is one you are obliged to trust.

Where this fits

What automated validation will not do for you

Security Brigade's own comparison positions Continuous Automated Red-Teaming as automation working from predefined attack patterns: it lacks the creativity and adaptability of a human red team, and it does not test your people or your processes. Both belong in a security programme. Neither replaces the other, and a vendor who tells you otherwise is selling you one of them twice.

Approach	What it exercises	What it will not do	Where it fits
External vulnerability scanning	Presence — versions, banners, open ports, known signatures across the estate it is pointed at.	Establish whether any of it is reachable, or exploitable, in your environment.	Coverage and hygiene reporting.
Breach and attack simulation	Known attacker techniques replayed against the controls you already own, to see what your detection stack catches.	Say anything about your external exposure — it starts inside, against infrastructure you have already inventoried.	Testing detection and response coverage.
SEBI's clarifications of 28 August 2025 place breach-and-attack simulation and Continuous Automated Red-Teaming in the recommendatory category under the CSCRF, not the mandatory one. Nothing on this page should be read as saying the framework requires either.
Continuous penetration testing	Human testers on a subscription cadence, against the scope booked for that engagement.	Cover an estate that changes between engagements — the scope was fixed when the engagement was booked.	Depth on a defined, high-value application.
Continuous Automated Red-Teaming	Exposure discovered from outside and attributed to you, tested where it is safe and authorised, continuously and without a booking.	Test people or processes, or improvise beyond the attack patterns it has been given.	Keeping a changing external estate honest between human engagements.
That is the ceiling, stated on the page rather than discovered in month three of a proof of concept. Automation is repeatable, cheap to re-run and tireless. It is not creative, and creativity is what a human tester is for.
Human red teaming — Security Brigade	A goal-driven adversarial exercise against the human, process and business-logic layers automation cannot reach.	Run continuously, or at automated cadence and cost.	Proving a specific business-impact scenario end to end.
Where validation finds something that warrants deeper testing, it escalates into a Security Brigade red-team engagement with the evidence, the scope and the probe history already loaded — so the engagement starts at the interesting part.

External vulnerability scanning

What it exercises: Presence — versions, banners, open ports, known signatures across the estate it is pointed at.
What it will not do: Establish whether any of it is reachable, or exploitable, in your environment.
Where it fits: Coverage and hygiene reporting.

Breach and attack simulation

What it exercises: Known attacker techniques replayed against the controls you already own, to see what your detection stack catches.
What it will not do: Say anything about your external exposure — it starts inside, against infrastructure you have already inventoried.
Where it fits: Testing detection and response coverage.

SEBI's clarifications of 28 August 2025 place breach-and-attack simulation and Continuous Automated Red-Teaming in the recommendatory category under the CSCRF, not the mandatory one. Nothing on this page should be read as saying the framework requires either.

Continuous penetration testing

What it exercises: Human testers on a subscription cadence, against the scope booked for that engagement.
What it will not do: Cover an estate that changes between engagements — the scope was fixed when the engagement was booked.
Where it fits: Depth on a defined, high-value application.

Continuous Automated Red-Teaming

What it exercises: Exposure discovered from outside and attributed to you, tested where it is safe and authorised, continuously and without a booking.
What it will not do: Test people or processes, or improvise beyond the attack patterns it has been given.
Where it fits: Keeping a changing external estate honest between human engagements.

That is the ceiling, stated on the page rather than discovered in month three of a proof of concept. Automation is repeatable, cheap to re-run and tireless. It is not creative, and creativity is what a human tester is for.

Human red teaming — Security Brigade

What it exercises: A goal-driven adversarial exercise against the human, process and business-logic layers automation cannot reach.
What it will not do: Run continuously, or at automated cadence and cost.
Where it fits: Proving a specific business-impact scenario end to end.

Where validation finds something that warrants deeper testing, it escalates into a Security Brigade red-team engagement with the evidence, the scope and the probe history already loaded — so the engagement starts at the interesting part.

The arithmetic

Where the eight-to-fifteen-per-cent band comes from

A band, not a promise — and worth stating precisely, because a validation rate is trivially inflated by choosing a flattering denominator.

How the validated-exposure band is derived As of August 2026

The denominator is exposures that discovery surfaced and prioritisation selected for validation. It is not every asset in your inventory, and not every alert in the platform.
The numerator is findings confirmed as exploitable in the customer environment by an active probe, with evidence attached to the finding.
The band is observed across customer environments rather than modelled. The spread reflects how much of an estate is legacy, how much sits behind an edge that hides it, and how recently any of it was last tested.
It moves with the estate. One that has just been through a remediation programme validates lower; one that has just absorbed an acquisition validates higher.

Deliberately excluded

Findings for which no safe probe exists, and findings outside the scope you authorised. They are reported as unvalidated and counted in neither the numerator nor the denominator.
Any published accuracy figure. There is no shared definition of a wrong result across vendors, so the number would not mean what a buyer would reasonably take it to mean.
Severity. This is a prioritisation claim: a validated finding is one that works, which is not the same as the one that matters most to your business.

Where this gets sharper

Continuous Automated Red-Teaming works from one correlated exposure model

Attack Surface Management Validation is bounded to inventory that discovery has already found and attributed to you — nothing is probed that was not first discovered and owned.

Questions buyers actually ask

Before you evaluate this

How is this different from breach and attack simulation?

Breach-and-attack simulation starts inside, replaying known techniques against controls you already own, and its output is a statement about your detection stack. This starts outside, against exposure that discovery found and attributed to you before anything was probed, and its output is a statement about whether an exposure is reachable at all. Most estates want both eventually. The order matters, though: knowing whether your EDR would catch a technique is less urgent than knowing that an unauthenticated storage endpoint is answering the internet right now.

Does SEBI CSCRF require this?

No, and be careful with any vendor who tells you it does. SEBI's clarifications of 28 August 2025 place breach-and-attack simulation and Continuous Automated Red-Teaming in the recommendatory category rather than the mandatory one. Validation is worth buying because an untested backlog is not a prioritised backlog — not because a clause obliges you to.

Can you run this against production without breaking it?

The controls in the table above are the answer, and they are clause 4 of the service terms rather than assurances: payloads are non-destructive and purpose-built per capability rather than generic public exploit code, targeting is bounded by the software to inventory already discovered and attributed to you, and the exclusions, the rate limit and the scan depth are yours to set. What none of that settles is the system you already know cannot absorb a test. Exclude it, and treat its findings as unvalidated — an honest gap is a better outcome than a validated finding and an incident report on the same morning.

What should we still book a human test for?

Anything that needs improvisation. Business-logic abuse chained across several systems, social engineering and the human layer, assumed-breach exercises that start from inside, physical and process testing, and any scenario where the objective is to prove a specific business impact end to end rather than to establish that an exposure is live. Automated validation keeps the external estate honest between those engagements and hands the human testers a starting position; it does not replace them.

Find out how much of your backlog is actually exploitable

One apex domain, two business days, a written snapshot — with what was validated separated from what was not.

Request an exposure snapshot See Pricing