Bug bounty workflow

Use Eresus Guard only against assets the program has authorized and that your Workbench project includes. The program's scope, safe-harbor terms, and disclosure process remain in force; a project setup does not grant permission from the program.

#Prepare the assessment

1. Check the program's current scope and rules. Create or select the project that will hold the assessment evidence.
2. Add only approved hosts and paths to the project. Exclude out-of-scope assets and any production data or third-party services the program forbids.
3. Prefer a staging replica when the program allows it. For explicitly authorized production work, use dedicated bounty accounts and stay within the program's safety rules.
4. In Assessment setup, select the authorized web or API target and review scope, exclusions, and safety limits. Add API specifications or captured traffic separately through Import traffic (Ingest).
5. For source analysis, connect only a repository or mirror the program allows and select a pinned commit. Source-only analysis does not authorize network testing.
6. Save the setup, then start the separate run action only after the current authorization checks pass.

#Decide what to report

Review each candidate in Findings register. Before submitting, confirm that the affected route or source is in scope, inspect its supporting HTTP Record or OAST callback when available, and reproduce the behavior without destructive actions. Describe impact in the program's terms and follow its disclosure instructions.

Do not treat a source finding as proof of a live exploit until it has been reviewed against the program's allowed environment. Keep customer data, real passwords, and live session cookies out of reports.

If the program removes an asset from scope, stop its active assessment in Workbench and update the project authorization before starting another run.

#Related guides

• Projects and scans
• Scope and safety
• Findings and evidence