Find and Fix Security Bugs Fast


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.

How it Works


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 (noUi) mode.


What to test

What

How to test

How

  • PurpleTeam works out "how to test"
No tests to be written

No Tests

  • There are no more tests to be written

You Decide When to Run It


On Commit
On Push
Daily/Nightly
Any Time

Interactive or Headless


You decide whether to run the CLI in interactive mode or headless.

Interactive

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.

Headless

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.

What it tests


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.


New or existing projects

Adjust attack strength
Tester Attack Strengths and Alert Thresholds

You can adjust the attack strengths and alert thresholds of the Testers.

purpleteam alert thresholds
PurpleTeam Attack Strengths and Alert Thresholds

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 tests:

Authenticated applications
Authenticated Applications
Single page applications
Single Page Applications
TLS/SSL Deployments
TLS/SSL Deployments
Server Configurations
Server Configurations
Server Side HTML
Server Side HTML
GraphQL APIs
GraphQL APIs
REST APIs
REST APIs

Composition


PurpleTeam under the hood

Architectural Overview


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.


purpleteam local

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.

Getting Started

 

Test Your Application

  •  Review pricing page
  •  Review documentation
  •  Decide on cloud or local environment
  •  If cloud, contact us for onboarding details
  •  If local, head to the documentation
  •  Configure the purpleteam CLI
  •  Start testing your application
  •  
  •  

Test OWASP NodeGoat

  •  Deploy NodeGoat as SUT using iac-sut
  •  Review pricing page
  •  Review documentation
  •  Decide on cloud or local environment
  •  If cloud, contact us for onboarding details
  •  If local, head to the documentation
  •  Configure the purpleteam CLI
  •  Start testing NodeGoat with PurpleTeam
  •  

free forever

We are passionate about supporting open source.

If you want your open source project secured by PurpleTeam head to the community page or get started with the documentation.