Getting Started as a Triager
As a Triager, your job is to evaluate, reproduce, and route vulnerability reports so program owners only see what matters.
This guide covers the default flow; individual Programs may customise workflow, scope, and severities.
Step 0: Choose Your Triage Model
In triage, Bugbop is flexible - you’re not forced into a single triage path. Pick what suits your team, and you can mix-and-match over time:
- In-house triage: Invite your own staff as Triagers. Keep decisions, tone, and context in-house.
- AI Triage assist/alternate: Use Bugbop’s AI to pre-label severity/scope, suggest duplicates, provide remediation notes, and route work.
See AI Triage .
- Third-party triage: Grant access to contractors, your Managed Service Provider (MSP), or pentest firm as Triagers.
Many teams start with AI assist + in-house review, then add an MSP during peak periods.
Don't have a trusted MSP for triage? We work with several experienced Managed Service Providers who specialize in bug bounty triage and can help scale your program.
Contact us to learn more about our trusted MSP partners.
Step 1: Getting Invited
You’ll be invited to a Program by the Owner, an Admin, or another Triager.
Step 2: Receiving Notifications
Notifications arrive by email and in-app. You can also wire up
Webhooks
to n8n, Slack, etc., for triage queues and escalations.
Step 3: Evaluating Reports
Tip: Enable Bugbop AI Triage to assist with determining severity, scope checks, duplicate suggestions, remediation notes, and workflow routing.
For each new report:
- Severity: Apply the Program’s severity model (Critical/High/Medium/Low).
- Scope check: Confirm the affected asset is in scope and the activity complies with the Program policy.
- N/A low quality bugs: For known low-value findings (e.g., self-XSS, version disclosure), close as Not Applicable using the Program's standard rationale unless policy says otherwise.
- Duplicates: Search existing reports and use AI duplicate hints. Link to the canonical report if found. No bounty is required for duplicates.
- Reproduce: If it’s in scope, follow the steps to verify at your discretion—don’t blindly run every command.
Step 4: Communicating with Bug Hunters
The primary way to communicate in Bugbop is via comments on bug reports. It provides a rich text editor with formatting options and allows you to update the report status and severity at the same time. New comments will notify all users of the program and bug hunter that raised to the bug.
The triager comment field interface with rich text editing and status controls
Key features of the comment field for triagers:
- Rich text formatting: Use the toolbar to format text with images, italic, links, code blocks, and lists
- Status updates: Change the report status (New, Open, Needs More Info, etc.) while adding your comment
- Severity adjustments: Update the severity level if your evaluation differs from the initial assessment
- Bounty recommendations: Include bounty suggestions in your comments - program owners will see these and make final decisions
- Chronological conversation: All comments are displayed in chronological order, creating a conversation history visible to the bug hunter and team
- Transparency: All comments are visible to the bug hunter and your team
Step 5: Changing Report Status
Available states may vary by Program:
- New: Untriaged report. All bugs start here.
- Needs More Info: Waiting on the bug hunter to supply details or proof.
- Open: Verified and accepted; ready for remediation planning.
- Duplicate: Same underlying issue as another report; link the canonical report.
- Not Applicable: Out of scope, informational only, expected behavior, or low-value policy items (e.g., SPF/DMARC/CAA/CSP hygiene) per Program rules.
- Fixed: (Usually set by maintainers) Issue remediated and verified.
- Won’t Fix: Tracked but not planned for remediation.
Step 6: Recommending Bounties
Triagers don’t pay bounties but can recommend amounts.
Program Owners/Admins approve and pay via the Program’s Stripe-backed wallet.
- Review the Program’s bounty table/ranges and policy notes (caps, exclusions, duplicates).
- Consider severity, exploitability, affected scope, and report quality (clear PoC, minimal back-and-forth).
- Share rationale in your recommendation. If the Program prefers internal discussion, coordinate off-thread to avoid setting expectations prematurely.
Next Steps
- Use canned responses for common closures (duplicate, OOS, SPF/DMARC/CAA/CSP hardening).
- Review recently closed reports to align on severity and messaging across the team.
- Work with Program Owners to tune scope and policy to further reduce noise.
- See AI Triage for an alternative approach to manual triage.
