Triaging Bug Reports

The Triage Process

Quick reference for severity levels, communication, and response templates. For the full walkthrough, see the Triager Guide.

Initial Assessment

Scope Validation

• Verify the affected asset is listed in your program scope
• Check whether the vulnerability type is excluded in your program policy
• If a report is technically out-of-scope but still valuable, consider making an exception

Validity Check

• Does it describe a security vulnerability (not a feature request or UX issue)?
• Is there enough information to reproduce the issue?
• Does it affect the confidentiality, integrity, or availability of your systems or data?

Duplicates

• Search existing reports for similar vulnerabilities
• Compare technical details, not just vulnerability categories
• If it's a duplicate but with additional attack vectors or impact, consider treating it as a unique finding

Severity Evaluation

Bugbop uses four severity levels. Think about how bad it would be if exploited, how easy it is to pull off, and how important the affected system is.

Severity Levels

• Critical: Full system compromise, data breach, or remote code execution. Easily exploitable with no authentication required. Affects critical assets like authentication systems, payment processing, or PII storage.
• High: Significant data exposure or functionality compromise. May require a low-privilege account or some user interaction to exploit. Affects important systems like user account management.
• Medium: Limited data exposure or partial functionality impact. Requires specific conditions or elevated access to exploit. Affects less sensitive components.
• Low: Minor information disclosure or minimal real-world risk. Requires complex conditions or unlikely scenarios to exploit. Affects non-sensitive assets like marketing pages.

Bug hunter Communication

Reply fast, be straight with people, and don't leave them hanging. See the response templates below.

• Let them know you've seen it and you're looking into it
• Update them at least weekly, even if there's no news
• If it's taking longer than expected, say so
• If you're closing a report, explain why with enough detail that they understand the decision

Remediation Planning

Before closing a report as fixed, try to reproduce the original bug to make sure it's actually gone. Test variations too.

Resolution & Rewards

Bounty Determination

When deciding on bounty amounts, consider:

• Severity level (primary factor)
• Report quality and clarity
• Creativity or novelty of the finding

Closing Reports

When closing a report, include:

• Confirmation that the issue has been fixed
• Final severity classification
• Bounty amount and payment details

Response Templates

Copy-paste these and tweak them. Don't send them as-is - mention the specific bug so the researcher knows you actually read their report.

Initial Acknowledgment

Clarification Request

Valid Report

Invalid Report

Duplicate Report

Fix Deployed & Bounty