Define an authorized scope
Scope is the contract. It records what you are allowed to assess, and Oyster’s Red Team tools check every target against it.
Set the scope
Section titled “Set the scope”- Open Scope under Red Team in the sidebar, in the project the engagement belongs to.
- Project — name the engagement.
- Allowed targets — the URLs, domains, IP ranges or repositories you are authorized to assess, one per line.
- Blocked targets — anything explicitly out of scope, one per line.
- Allowed test types — switch on only the kinds of testing your authorization covers.
- Choose Save Scope. The Current Active Scope card shows what is in force.
How the scope is used
Section titled “How the scope is used”- Recon and Planner write target-specific plans only for targets inside the active scope.
- A target outside it gets general methodology and a way to reproduce the question in your own lab, instead of a plan aimed at that system.
- Out-of-scope requests are recorded in Oyster’s audit log.
- Each project has its own scope; switching projects switches the scope in force.
Good practice
Section titled “Good practice”- Keep the scope as narrow as the authorization. A wildcard covers more than you may think.
- Note the authorization’s dates, and update the scope when they change.
- List third-party services you must not touch as blocked targets, even when they sit next to your own systems.
Oyster is made by Red Orca, alongside Dolphin and Shark. One account for all three.
