Bug bounty workflow

Use Eresus Guard when the bounty program has authorized the target and your workspace project matches that authorization. Guard does not replace the program’s rules, safe-harbor terms, or disclosure path.

Project scoped to the authorized bounty asset

Optimize the assessment, not the claim

Create a project named after the program and asset. Put only in-scope hosts in the authorization gate.
Exclude out-of-scope paths, production user data, and third-party payment or identity providers the program forbids.
Prefer a staging replica when the program allows it. If you must use production, keep authenticated testing on dedicated bounty accounts.
Run DAST first for the public surface. Add API inputs (OpenAPI, Postman, cURL) when the program includes APIs.
Use SAST on a public or explicitly allowed source mirror. Language-aware research agents stay inside the clone; they do not browse the live site.
Triage in Findings with HTTP Records and OAST. Discard anything you cannot replay or that depends on a configuration the program does not run.

DAST against the in-scope public surface

What to submit

Submit only findings that still have:

A reachable entry from an in-scope surface
Request/response or callback evidence
A non-destructive reproduction the program can repeat
Impact stated in the program’s terms, not as a CVE or “zero-day”

Do not upload customer data, real passwords, or live session cookies into the report.

Safety gates that stay on

AuthorizationGate: hosts outside the project do not get probed
Metadata-IP rejection on outbound fetches
Fixed LLM and HTTP budgets on agentic follow-up
Maximum eight concurrent agents
No unrestricted shell or raw HTTP from research workers

If the program later marks an asset out of scope, stop the scan from Workbench and remove the host from the project before the next run.

Need a workflow that is not documented here? Email contact@eresussec.com.