Skip to content
Glossary

What is continuous automated red teaming?

Short answer: Continuous automated red teaming (often abbreviated CART) discovers what is exposed and runs multi-stage attacks on a repeated cadence (outside-in) to find paths before an adversary uses them. It does not replace a deep pentest of one application, and it is not only a surface inventory.

Definition

A traditional red team emulates the attacker at breadth: objective first, not only a list of IPs. The usual limit is cadence: a manual exercise once or twice a year covers a fraction of the estate. Automating it does not mean “a magic button”. It means keeping surface discovery and offensive emulation at the speed cloud, APIs and pre-production change, without installing an internal agent to fake the attack from inside.

How it differs from a pentest

A pentest usually starts from known systems and goes deep. Continuous red teaming tries to discover surface (published services, cloud misconfiguration, exposed credentials) and chain stages on what it finds, not only on what was already in scope.

A deep test of one application is still needed. A surface finding without validation is a hypothesis; a pentest without an external map defends the perimeter of the last inventory.

How it differs from ASM and BAS

Attack surface management keeps the map of what is visible from outside. Continuous red teaming uses that kind of map and also exercises paths. Seeing an open port is not the same as proving an attack chain.

Breach-and-attack simulation (BAS) tools often install agents inside and ask how far an attacker already inside would get. An outside-in approach does not start from that agent: it tests what a stranger can reach.

Why cadence matters

The attacker does not wait for the exercise calendar. Cloud, shadow IT and test environments change between one red team and the next. An annual report describes a moment.

Continuous does not mean “no people and no authorisation”. It means the offensive scope can be repeated when the estate changes, not only when there is budget for a consultancy.

In the Azuba model

Offensive Security & Exposure Management keeps attack surface and continuous pentesting as capabilities distinct from validating one application.

In Offensive Security & Exposure Management, FireCompass covers attack surface and continuous pentesting.

Does continuous red teaming replace a pentest?

No. It keeps discovery and offensive emulation on a cadence. A deep pentest of one system validates a different kind of risk. They can complement each other.

Is it the same as attack surface management?

No. ASM keeps the map of what is exposed. Continuous red teaming exercises paths on that surface. A visible asset without a demonstrated attack chain is still a hypothesis.