The following are a list of common terms used within the purpleteam project.

Key Value
Build User The person that:
  • Creates the Job for purpleteam
  • Creates test specifications if overriding desired
Emissary/Emissaries Containerised tools that do the Testers bidding, Zaproxy, Nikto,, etc.
Job Test job defined by the Build User POSTed to the orchestrator’s /test or /testplan route. Job file examples. Additional details in the Job File page.
orchestrator Component responsible for:
  • Actioning the CLI commands
  • Receiving, validating, filtering and sanitising the Job from the CLI
  • Initiating and coordinating the activities performed by the Testers
  • Providing real-time Tester progress updates to the CLI
  • Compiling Outcomes and transferring them to the CLI
Outcomes Resources (generally in the form of files) that are generated by Testers and transferred from the orchestrator (or API in the cloud environment) to a file path location specified in the CLI configuration. Additional details in the Log and Outcomes files page.
Purple Team Organisation with Build Users that consume PurpleTeam
PurpleTeam This product
purpleteam The CLI component of the PurpleTeam solution, often just referred to as the CLI in the context of the PurpleTeam solution
SUT System Under Test (your application / API)
Test Run This is the back-end activity initiated by the CLI that tests the customer’s SUT. The orchestrator is responsible for coordinating this activity and the Testers
Test Session Defined in the Job file by the Build User. Resource objects… for example those of type serverScanner, tlsScanner, appScanner and others added in the future are Test Sessions. In the case of an appScanner Test Session you can think of the Test Session as a specification for a single user with a set of credentials that may want to test one to many routes. For example you could have a Test Session for a low privileged user and one for an administrative user, both testing the same or different areas of your SUT. Test Sessions are also discussed in the Job file documentation
Tester/Testers The micro-services responsible for managing the different types of security testing you require (app, tls, server for example). The Testers execute the Job and interact with their Emissaries for which they are responsible. The intention is that you will be able to add your own