PurpleTeam is a CLI and service, actually many services working together to secure your applications.
The PurpleTeam CLI communicates with the PurpleTeam service. The PurpleTeam service runs smart dynamic application security testing (DAST) against your Web applications and APIs. PurpleTeam is language agnostic.
Other DAST tools offer integrations, whereas PurpleTeam is platform agnostic. We give you a process (
purpleteam CLI) that will run anywhere, simple to administer and no gimmicky integrations required.
The CLI can be run manually which provides a dashboard, but it’s sweet spot is being inserted into Development Team’s build pipelines and run in headless (
You decide whether to run the CLI in interactive mode or headless.
Provides real-time feedback on what all of the Testers are doing and finding. At the end of the Test Run the Outcomes archive is sent to a directory of your choosing.
Allows the CLI process to be embedded in your build process or any process for that matter. At the end of the Test Run the Outcomes archive is sent to a directory of your choosing.
PurpleTeam finds security defects in your running web applications and APIs by attacking their external interfaces and providing immediate and continuous notification of what and where your security defects are, how to fix them, how to reproduce each test, along with tips for spotting similar issues in the future.
You can adjust the attack strengths and alert thresholds of the Testers.
You can add PurpleTeam alert thresholds, great for existing projects with existing security defects that you don't want to count toward a failed Test Run.
PurpleTeam under the hood
The following depicts the architecture of the
local (OWASP) environment. The
cloud (BinaryMist) environment has all the same PurpleTeam core components, with added authentication and SAM CLI and docker-compose-ui swapped for cloud alternatives. More details are provided in this blog post and our documentation.
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.
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 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
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.
The Orchestrator is responsible for:
Each Tester is responsible for:
localenv, or hosted on AWS ECS for the
cloudenv) dynamically (via Lambda Functions hosted via sam cli in
localenv, or hosted on AWS Lambda in
cloudenv) 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
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 is required to be running in order to start/stop it's hosted containers (it has access to the hosts Docker socket).
These are the work horses of PurpleTeam, they do most of the work.