purpleteam-doc

definitions

Key Value
Build User The person that: <ul><li>Creates the configuration (Job AKA buildUserConfig) for purpleteam</li><li>Creates test specifications if overriding desired</li></ul>
Emissary/Emissaries Containerised tools that do the Testers bidding, ZapAPI, Nikto, sslyze, etc. The intention is that you will be able to add your own
Job Test job defined by the config POSTed to the orchestrator /test or /testplan route. Also referred to as buildUserConfig
orchestrator Component responsible for:<ul><li>Actioning the CLI commands</li><li>Receiving, validating, filtering and sanitising the Job from the CLI</li><li>Initiating and coordinating the activities performed by the Testers</li><li>Providing real-time Tester progress updates to the CLI</li><li>Compiling Outcomes and transferring them to the CLI</li></ul>
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
Purple Team Organisation with Build Users that consume purpleteam
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 by the Build User, for example you could have a Test Session for a low privileged user and one for an administrative user, both testing the same areas of the SUT
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