How Do White Hat Hackers Choose Bug Bounty Targets? GitHub Bounty Hunter Methodology

During Cybersecurity Awareness Month, the GitHub Bug Bounty team interviewed well-known security researcher @vaib25vicky, asking him to share his methodology, technical choices, and hands-on experience in hunting for vulnerabilities on the GitHub platform. The interview reveals a frequently overlooked question: when facing a platform with massive functionality and an astonishing amount of code, how does a bounty hunter actually decide "where to start"?

The First Step in Bug Hunting Isn't Technique — It's Choosing Targets

Many people assume a bounty hunter's daily routine consists of constant scanning, fuzzing, and brute-force enumeration of endpoints. But @vaib25vicky's approach is exactly the opposite — he spends most of his time on "choosing targets."

A platform may contain hundreds of feature modules, from identity authentication and permission management to API gateways and third-party integrations. Each module differs in complexity, historical vulnerability density, and how thoroughly other hunters have covered it. If you blindly start with the most popular endpoints, you'll often run into a large number of duplicate vulnerabilities that have already been submitted.

Therefore, choosing "where to dig" is essentially a game of information asymmetry. Whoever can discover an attack surface before others notice it is more likely to earn a valid bounty.

The Cost of Duplicates: On most bug bounty platforms (including GitHub's HackerOne program), rewards for vulnerability reports follow a "first come, first served" principle. If two hunters submit the same vulnerability, only the first confirmed report receives a bounty; subsequent reports are marked as "Duplicate" and receive no reward. This means that even if a hunter spends a great deal of time successfully finding a real vulnerability, if someone else has already submitted it first, the entire investment may yield nothing. For this reason, seasoned hunters put considerable effort into assessing "whether this area has already been thoroughly covered" — they review publicly disclosed reports, follow community discussions about popular targets, and observe patch release timelines to determine which areas remain "low-competition zones." This also explains why "choosing targets" is itself a core skill: it directly determines whether the same amount of effort can be converted into actual returns.

How He Judges Whether a Feature Is Worth Digging Into

Based on the thinking revealed in this interview, @vaib25vicky's target selection logic roughly revolves around several dimensions.

New Features Take Priority Over Old Ones

Newly launched features often lack sufficient adversarial testing. When development teams are rushing to meet deadlines, security reviews may only cover the main flow, leaving edge cases, abnormal inputs, and permission-crossing zones wide open. For hunters, new features mean lower duplication rates and a higher probability of being "first."

Focus on Permission and Identity Boundaries

Any feature involving role switching, cross-organization access, or token passing is a high-incidence area for logic vulnerabilities. These issues are difficult for automated tools to find, yet they often result in unauthorized reading or writing, carry high severity levels, and command correspondingly higher bounties.

The Limitations of Logic Vulnerabilities and Automated Tools: Logic vulnerabilities (Business Logic Vulnerabilities) refer to design flaws at the business rule level of a program, rather than technical errors in code implementation. For example, a system may correctly verify a user's identity token but fail to check whether that user is authorized to access the requested resource; or an approval workflow may normally require two levels of approval but can bypass one level through a specific combination of parameters. These vulnerabilities are difficult for automated tools to find because scanners and fuzzing tools are typically based on known attack patterns (such as SQL injection or XSS signatures) — they cannot understand "whether this operation should be allowed in the current business context." Discovering logic vulnerabilities depends on a hunter's deep understanding of business processes — manually mapping out role relationships, permission matrices, and data flows, then attempting to find illegitimate combinations beyond the boundaries of legitimate operations. This is precisely where bounty hunters provide core value relative to automated scanners.

Observe Developers' "Trust Assumptions"

Behind every feature lies an implicit trust assumption by the developer about the source of inputs. When a parameter is believed to be "callable only by internal services" but is actually exposed on the client side, an attack surface emerges. One of @vaib25vicky's methods is specifically hunting for this kind of trust misalignment.

The Concept of Trust Boundaries: A trust boundary is a foundational concept in security architecture, referring to the dividing line between areas of different trust levels within a system. For example, a trust boundary exists between the browser and the server, and between the external network and internal services. When designing features, developers typically make assumptions about data crossing trust boundaries: for instance, "this parameter will only be passed in by internal microservices" or "this request must have passed through the front-end gateway's authentication." When these assumptions don't hold in actual deployment — such as an internal interface being accidentally exposed to the public internet, or credentials that should be secret being hardcoded in front-end code — the trust boundary is broken. Attackers can exploit this "trust misalignment" by impersonating a trusted internal caller to bypass security checks. @vaib25vicky specifically hunts for these issues, which essentially means auditing whether developers' assumptions match the actual attack surface — and this is the root cause of many high-severity vulnerabilities.

The Trade-off Behind the Methodology: Balancing Breadth and Depth

The eternal dilemma bounty hunters face is: should you invest time digging deep into a familiar old module, or constantly explore new features to maintain breadth?

Based on this discussion, @vaib25vicky tends to adjust dynamically. When an area has been heavily covered by other hunters and duplicate submission rates rise, he proactively shifts to newly launched features or less-discussed integration points. This approach of "using duplication rate as a signal" essentially treats the platform as a constantly changing map rather than a static shooting range.

For ordinary developers, this also offers a reverse perspective: when your team launches a new feature, are you assuming that "no one will look at this carefully"?

The Dynamic Evolution of the Attack Surface: The attack surface is the sum of all entry points in a system that could potentially be exploited by attackers, including API endpoints, user input fields, file upload functionality, third-party integration callbacks, and more. For a continuously iterating platform like GitHub, the attack surface is not fixed — every new feature launch, every architectural adjustment, and every third-party service integration may introduce new entry points. At the same time, the attack surface of old features may "depreciate" due to continuous coverage by other hunters (rising duplication rates). Therefore, hunters need to track changes in the attack surface like following a living map: monitoring the platform's changelogs, API version changes, newly published integration announcements, and other public information to identify "just-emerged, not-yet-thoroughly-tested" new entry points. This dynamic perspective is something static vulnerability scanning lacks, and it is the key to bounty hunters maintaining efficiency in continuous competition.

Insights for Security Professionals

The value of this interview lies not just in specific techniques, but in demonstrating a transferable way of thinking.

First, target selection affects output more than effort. When resources are limited, the judgment to identify high-value targets is often more critical than mastering more tools.

Second, automated tools solve for known patterns, while a bounty hunter's core competitiveness lies in understanding business logic and trust boundaries.

Third, the launch period of new features is a high-incidence window for security risks. Whether you're a corporate security team or an independent researcher, it's worth shifting your attention toward "what has just changed."

GitHub's decision to share this researcher's story during Cybersecurity Awareness Month also sends a signal: platform security is the result of both attackers and defenders shaping it together, and the hunter's methodology itself is a set of external security review notes.

One-line Summary

GitHub bounty hunter @vaib25vicky shares his methodology: choosing targets matters more than technique, and new features and trust boundaries are high-incidence areas for vulnerabilities.

Paragraph Summary

This article summarizes the GitHub Bug Bounty team's interview with security researcher @vaib25vicky. It points out that a bounty hunter's core skill is not in using scanning tools, but in the judgment of "choosing targets." @vaib25vicky prioritizes newly launched features (lacking adversarial testing, low duplication rates), permission and identity boundaries (high-incidence areas for logic vulnerabilities), and misaligned trust assumptions by developers (internal interfaces accidentally exposed). He dynamically adjusts his investment in breadth versus depth by observing duplicate submission rates, treating the platform as a constantly changing map. The article concludes with insights for security professionals: target selection affects output more than effort, understanding business logic and trust boundaries is the hunter's core competitiveness, and the launch period of new features is a high-incidence window for security risks.