Personas You'll Meet on Your Bug Bounty Journey
As we covered in the video, understanding the people and the rules of bug bounty is the foundation for your success. This guide provides a detailed breakdown of the key personas you'll interact with and the professional rules of engagement you would want to follow.
The Four Core Personas
Your bug bounty journey will involve interacting with four main groups. Understanding their roles will make your communication more effective.
The Hacker (That's You!) As an ethical hacker, your role is to be curious, creative, and persistent. Your primary responsibilities are to find valid security vulnerabilities, stay strictly within the program's scope, and communicate your findings clearly and professionally.
The Program Owner (The Company) This is the organization that owns the assets you're testing. Their goal is to reduce their security risk. They set the rules of the program, define the scope, and are the ultimate decision-makers on which bugs get paid and how much.
The Triage Team (The Gatekeepers) When you submit a report, the triage team is the first group to see it. They are security analysts whose job is to validate your finding. They will attempt to reproduce your bug, assess its severity, and check if it's a duplicate of a previous submission. As you noted in the video, this team can be run by the platform (like HackerOne) or directly by the company's internal security team. Being clear and professional with the triage team is essential for your continued success, while acknowledging that their decisions are not always accurate - due to the sheer volume of submissions they go through every single day.
The Platform (The Intermediary) Platforms like HackerOne, Bugcrowd, or YesWeHack act as the marketplace and communication hub that connects you with the programs. They provide the infrastructure for submitting reports, facilitate communication, and handle payments.
The Rules of Engagement
Every bug bounty program has a policy that outlines the rules of engagement. This is a helpful guide that tells you exactly how to participate in their program successfully.
One of the first sections you'll want to look at is the scope. Reviewing it helps you focus your efforts and avoid the disappointment of finding a great bug on an asset that the program won't accept reports for.
The scope clearly defines the playground for your testing and tells you two main things:
What you CAN test: A list of domains, applications, and IP addresses that the company wants you to look at. These are your targets.
What you CANNOT test: A list of out-of-scope assets. Focusing only on the in-scope assets is the best way to ensure your reports are successful and you won't cause any harm unintentionally.
Safe Harbor Most programs include a "Safe Harbor" or "Authorization" clause. This is the company’s promise that they authorize your security research as long as you follow their rules. It's a key part of what makes bug bounty a legal and safe activity for researchers.
Forbidden Actions The policy will also list a few actions that are not allowed because they could cause damage to the company's services. These typically include:
Denial of Service (DoS or DDoS) attacks.
Social engineering or phishing attempts against their employees.
Physical attacks against their offices or data centers.
Understanding Severity & Payouts
As the researcher, you will suggest a severity level when you submit a bug, but the final decision is made by the triage team and the program. The scale is typically:
Critical: Flaws that could lead to a full system compromise or mass data exposure.
High: Flaws that allow significant data access or privilege escalation.
Medium: Flaws with clear security impact but not much of an escalation path (such as Reflected Cross-Site Scripting without additional escalation).
Low: Flaws with minor security impact.
Responsible Disclosure
Your findings are strictly private until the company gives you permission to share them. Leaking details about a vulnerability before it is fixed can result in your bounty being forfeited and a ban from the platform. Public disclosure can only happen through a Coordinated Disclosure process, where you and the company agree on a publication date after the bug has been fixed.
Building Your Hacker Reputation
Your reputation is your most valuable asset.
Communicate Clearly: Write your reports with enough detail for the triage team to understand and reproduce your finding.
Handle Disagreements Gracefully: As mentioned in the video, you will not always agree with a program's decision on a report. If your report is closed as a duplicate (someone reported the same bug you found) or N/A (Not Applicable), it's a normal part of the process. It's okay to ask for clarification professionally, but arguing is counterproductive. A good reputation for being professional is always more valuable than winning a single dispute.
In the next chapter, "Welcome to the Terminal," we'll leave the rules and theory behind and start experimenting with the terminal that you'll need for your hands-on work.
