ATALAIAA bug bounty is a promise to strangers: send us what you find, and we will respond quickly, fairly and in good faith. Launching one before you can keep that promise tends to produce a flood of reports, an overwhelmed inbox and annoyed researchers.
The checklist below is meant to be run in a single meeting with engineering, security and whoever owns your public website. If you cannot tick most of it, start with a disclosure policy and come back in a quarter.
Step zero: a VDP and security.txt
A vulnerability disclosure policy (VDP) is the free, always-on version of a bounty. It tells people how to report, what you consider in bounds, and that you will not take legal action against good-faith research. Publish it before any reward scheme.
Then publish a security.txt file, as described in RFC 9116, so researchers and tools can find the right contact.
# https://example.com/.well-known/security.txt
Contact: mailto:security@example.com
Expires: 2027-06-30T23:59:59Z
Policy: https://example.com/security/disclosure
Acknowledgments: https://example.com/security/thanks
Preferred-Languages: en, pt
Canonical: https://example.com/.well-known/security.txtCheck that the mailbox is monitored, that the Expires date is in the future and that someone owns renewing it.
Readiness checklist
| # | Question | Ready when |
|---|---|---|
| 1 | Do you have a public VDP? | Published, linked from security.txt, with a safe-harbour statement |
| 2 | Have you tested the in-scope assets yourselves? | A recent pentest or internal review has been run and its findings fixed |
| 3 | Is there an asset inventory? | You can list every domain, app and API you would put in scope, with an owner |
| 4 | Who triages? | Named people with time set aside, plus cover for holidays |
| 5 | Who fixes? | Each in-scope asset maps to a team that has agreed to fix SLAs |
| 6 | Can you reproduce safely? | A staging environment or test accounts that researchers and triagers can use |
| 7 | Is legal on board? | The safe-harbour wording and payment terms have been reviewed |
| 8 | Can you pay? | A budget owner and a payment route exist, even for a private program |
Scope a stranger can apply
Good scope reads like a contract, not a wish. Write it so that a researcher who has never spoken to you can decide whether a finding counts.
- In scope: exact hostnames, app identifiers and API base paths, with the environment named.
- Out of scope: third-party services you do not control, marketing sites, and anything shared with other tenants.
- Excluded classes: issues you have decided not to reward, such as missing headers without impact, self-XSS or rate limiting on non-sensitive endpoints.
- Rules of engagement: no denial of service, no social engineering of staff, no accessing other users' data beyond what proves the issue, use the test accounts provided.
Start with a private program on a narrow scope. Widen it once triage is calm.
Triage SLAs and rewards
Publish response targets you can meet on your worst week, not your best. A typical structure has four clocks:
- First responseThe researcher hears from a person that the report has been received and is being looked at.
- Triage decisionValid, duplicate, out of scope or needs more information, with a severity attached.
- Reward decisionThe reward band is confirmed once severity is agreed.
- Fix and disclosureThe issue is fixed, verified and, where agreed, disclosed.
Set rewards as a table of bands by severity and asset tier, then fill in amounts from your own budget. The structure matters more than the numbers.
| Severity | Tier 1 assets (core product, auth, payments) | Tier 2 assets (supporting apps and APIs) |
|---|---|---|
| Critical | Band A | Band B |
| High | Band B | Band C |
| Medium | Band C | Band D |
| Low | Band D | Thanks and acknowledgement |
Write down how you score severity, for example with CVSS plus a note on business impact, so two triagers reach the same answer.
Close the fix loop
A bounty that only produces payouts is a cost. One that feeds the line is an investment. For every valid report:
- Open a ticket in the owning team's backlog with the SLA attached, not in a security-only tracker.
- Verify the fix against the original proof of concept, and ask the researcher to retest where appropriate.
- Add a regression test, a Semgrep rule or a scanner check so the same class cannot quietly return.
- Ask once a quarter which stations on the line should have caught the class earlier, and fix the station.
Check yours this week
- Fetch
/.well-known/security.txton your main domain. If it is missing or expired, that is your first task. - Run the eight-row table above with the right people in the room and mark each row yes, no or partly.
- If there are more than two noes, publish a VDP, schedule a pentest and revisit the bounty next quarter.