PurpleTeam Architecture is Pluggable

If you find that you need a different type of Tester, talk to us, we may even ask you to implement it and plug it in.

Purpleteam CLI

The purpleteam CLI is what initiates the security testing for you. Think of it as the interface into the PurpleTeam service. It has two modes, interactive and headless.
The interactive mode is used when you want to drive the tests and see the results in real-time as your System Under Test (SUT) is being security tested. You can page through the different testers to see how they are progressing along with real-time progress meters and security defect counts.
The headless mode is used when you are running the CLI from another process such as your build pipelines.
Both modes deliver an Outcomes archive to the location of your choosing once the PurpleTeam service has completed your Test Run.

Redis

Redis pub/sub is used to transfer Tester messages (live update data) from the Tester micro-services to the Orchestrator. The Build User can configure the purpleteam CLI to receive these messages via Server Sent Events (sse) or Long Polling (lp). The Orchestrator also needs to be configured to use either sse or lp.
With Long Polling (lp) if the CLI goes off-line at some point during the Test Run and then comes back on-line, no messages will be lost due to the fact that the Orchestrator persists the messages it's subscribed to back to Redis lists, then pops them off the given list as a lp request comes in, and returns them to the CLI.
lp is request->response, sse is one way. In saying that, lp can be quite efficient as we are able to batch messages into arrays to be returned.

Orchestrator

The Orchestrator is responsible for:

• Organising and supervising the Testers
• Sending real-time Tester messages to the CLI via either sse or lp
• Packaging and sending the Outcomes (test reports, test results) back to the CLI as they become available
• Validating, filtering and sanitising the Build User's input

Testers

Each Tester is responsible for:

• Obtaining resources, cleaning up and releasing resources once the Test Run is finished
• Starting and Stopping Stage Two Containers (hosted on docker-compose-ui for the local env, or hosted on AWS ECS for the cloud env) dynamically (via Lambda Functions hosted via sam cli in local env, or hosted on AWS Lambda in cloud env) based on the number of Test Sessions provided by the Build User in the Job file which is sent from the CLI to the Orchestrator, then disseminated to the Testers
• The actual (app, server, tls, etc) test plan

Sam Cli

Sam Cli stays running and listening for the Tester requests to run the lambda functions which start and stop the Stage Two Containers.

docker-compose-ui

docker-compose-ui is required to be running in order to start/stop it's hosted containers (it has access to the hosts Docker socket).

Emissaries

These are the work horses of PurpleTeam, they do most of the work.