Skip to main content
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
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. That is a claim about what your team should chase this week, not a claim that the rest is harmless. Each finding records whether it was tested, so you can tell untested from safe.

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, not 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.

Scope of testing

Four classes of finding, four ways of testing them

Validation logic is purpose-built per class of finding, not one generic scanner pointed at everything. These are the classes shipping today, in no particular order.

Cloud

Cloud security validation

AWS, Azure and GCP misconfigurations exercised, not just 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 instead of 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. 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. The same list is published on our security page and written into the service terms, where it binds us.

ControlWhat it boundsSet by
Non-destructive payloads, purpose-built per capability What a probe is permitted to be. Validation logic is written for each class of finding, not 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 published as §4 of the service terms and §7 of the security page, so you can hold us to it.
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. 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, by design. 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, not 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, not 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, not 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 published as §4 of the service terms and §7 of the security page, so you can hold us to it.

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.
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, by design.
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, not 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, not per scan.

Evidence

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

A validated finding carries more than 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.
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.
The identifier
Every validation request we send carries an identifier that lands in your own logs. You can search for it in your own 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.

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.

ApproachWhat it exercisesWhat it will not doWhere 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, because 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. 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, because 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. 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. A validation rate is trivially inflated by choosing a flattering denominator, so here is the one behind this number.

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, not 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.
  • 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.

Where this has already run

Continuous Automated Red-Teaming in customer engagements

An engagement where this did the work, and what it changed.

From nine working days to under an hour, and a board number with a stated confidence boundary

Nine brands, eleven countries, one advisory: answering “where do we even run this?” in under an hour

Read the story

All customer stories

Questions buyers 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. SEBI's clarifications of 28 August 2025 place breach-and-attack simulation and Continuous Automated Red-Teaming in the recommendatory category, not the mandatory one. The reason to buy validation is that an untested backlog is not a prioritised backlog, not that 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: payloads are non-destructive and purpose-built per capability, not 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.

Who else does this

How ShadowMap compares

Where continuous automated red-teaming is concerned, the real alternatives are the broad digital-risk platforms:

ShadowMap vs Cyble The unified agentic cybersecurity platform Read the comparison → ShadowMap vs CloudSEK Predictive Attack Graph Platform for the AI Era Read the comparison →

All five vendors side by side · What the same coverage costs if you assemble it from separate tools

Find out how much of your backlog is actually exploitable

One apex domain, two business days, a written snapshot that separates what was validated from what was not.

Request an exposure snapshot See Pricing