Security testing often starts with vulnerability categories: XSS today, authorization tomorrow, input validation next. For complex business systems, another entry point can be more productive: choose a feature worth understanding, learn how it is supposed to work, then explore how its capabilities might be misused.

This article draws on Shilpa Kumari’s October 8, 2026 GitHub Blog interview with VIP bug bounty researcher @vaib25vicky, whose research focuses on authorization and access control. It first summarizes the interview’s ideas and then separately explores their application to QA and AI Native Quality Engineering.

Source: How one bug bounty researcher chooses the features they investigate: https://github.blog/security/how-one-bug-bounty-researcher-chooses-the-features-they-investigate/. This article is based on the supplied study notes; consult GitHub’s current official materials for program details.

Reward quality over report volume

The notes describe GitHub’s emphasis on high-quality findings rather than maximizing submission counts. They describe a permanent, invitation-only VIP program, potentially exceeding $30,000 for critical findings, with faster responses and opportunities to preview some beta capabilities.

The stated invitation thresholds are one resolved Critical, two High, four Medium, or seven Low findings. These are descriptions of the program at the article’s publication, not guarantees of current rewards or eligibility.

For QA teams, the transferable principle is evidence quality: a report demonstrating a real authorization failure, its impact, and reproducible conditions is more useful than numerous unverified suspicions.

Learn the feature before choosing a vulnerability category

The following five steps are my synthesis of the interview, not a named framework presented by the researcher:

  1. Select a feature worth investigating.
  2. Use it directly and understand its normal behavior.
  3. Map users, resources, permissions, states, and dependencies.
  4. Ask how the capability might behave in unintended contexts.
  5. Explore anomalies repeatedly and determine whether they are genuine security findings.

This does not make vulnerability taxonomies such as OWASP irrelevant. It changes the starting point: taxonomies help generate hypotheses and classify findings without dictating every research session.

Why investigate complex features?

The researcher looks for features that seem complex and difficult to understand, then uses experience to judge whether a target is worth further time. Complex features may involve more actors, transitions, and implicit business rules. An organization-wide sharing capability, for example, might combine owners, members, external collaborators, administrators, pending invitations, and permission revocation.

Complexity does not imply a vulnerability. It warrants careful examination of boundaries. The researcher explores a target for a while, pursues promising signals, and moves on when the investigation is no longer productive. This is also a sensible allocation strategy for time-constrained QA teams.

The interview also sketches the researcher’s path into the field: building coding projects in college, learning to understand systems deeply and make them behave in new ways, then discovering bug bounty research by accident and finding it fun. GitHub felt like a natural place to start because the researcher already knew the platform, and its rewards, challenges, and team experience kept drawing them back. Learning sources include researchers on X, company security blogs and write-ups, Hacker News, and security subreddits; examples named in the interview include Google Project Zero, GitHub Security Lab, and PortSwigger. The advice to beginners is to be patient: progress can mean spending a long time investigating before finding a reportable issue.

Follow a boundary from normal use to a verified finding

The following is an original QA example added for this article, not a vulnerability disclosed in the GitHub interview.

Imagine an application that lets users share project reports. Begin with the expected behavior: who can create, view, share, or export a report? When do shared links expire? What happens when someone leaves the organization?

Then examine relationships and lifecycle transitions:

DimensionBusiness question to verifyUseful evidence
IdentityDoes each role see only the resources it is authorized to access?Role matrix and request outcomes
OwnershipAre resources isolated across organizations or tenants?Cross-tenant isolation results
StateDoes access expire after revocation or member removal?Before/after state and audit logs
OperationAre read-only users prevented from modifying or exporting restricted data?Server-side authorization results
Capability combinationsDo search, export, and bulk operations enforce the same rules as detail views?Cross-entry-point comparisons

Hiding a button is not an authorization control. An absent UI action does not prove the server rejects unauthorized requests. Perform all testing within an explicitly authorized environment and scope; never access real third-party data.

Keep hypotheses separate from verified findings.

The interview says AI saves the researcher time and improves efficiency, but still needs a human to guide it. The researcher compares AI to a very fast car that still needs a good driver.

For QA, AI could summarize feature documentation, propose boundary questions, organize hypotheses, and prepare evidence. These are practical extensions for this article, not uses attributed to the interviewee. AI still cannot make an unverified hypothesis true.

Keep three states distinct:

  • Risk hypothesis: a possible failure inferred from design or observed behavior.
  • Unconfirmed anomaly: unexpected behavior that still needs environmental, configuration, or business-rule explanations ruled out.
  • Verified finding: a reproducible issue in authorized scope, with clear expected-versus-actual behavior and evidence supporting the impact assessment.

The interview’s rule is straightforward: never submit a vulnerability that you have not personally verified. The same applies to AI-generated QA reports and security test cases.

AI-enabled products still need familiar security thinking. The researcher says the approach may need some adjustment, but many important issues remain recognizable: authorization failures, weak guardrails, and capabilities that were overlooked. Understanding the feature and applying established web-security skills are still useful.

A reusable AI assistance prompt.

You are a security test design assistant. Work only within an authorized scope.
Inputs: feature description, role/permission matrix, state transitions, API contracts.
Tasks:
1. Summarize expected business behavior and authorization boundaries.
2. Propose hypotheses by identity, resource ownership, state, entry point, and combined capability.
3. State the factual basis and missing information for each hypothesis.
4. Suggest human-executable checks and expected evidence.
5. Never label a hypothesis as a confirmed vulnerability.

Turn confirmed findings into regression coverage

This section is an independent engineering application of the interview, not a direct claim by the researcher.

Build feature research cards.

For high-risk features, record business purpose, roles, sensitive resources, authorization boundaries, lifecycle states, external dependencies, known anomalies, and unverified hypotheses. The aim is continuity of understanding, not documentation for its own sake.

Convert findings into layered tests.

  • Unit tests: complex permission rules, policy decisions, and state transitions.
  • API/service tests: server-side authorization, object ownership, revocation, and error paths.
  • End-to-end tests: critical user journeys involving role changes and visible feedback.
  • Human exploration: unknown combinations across roles, entry points, and lifecycle events.

Confirmed issues should become regression assets with the original failure evidence and post-fix verification. A green automated script alone is not enough.

Implications for AI Native QA.

A QA Skill or Agent could implement a controlled Understand → Hypothesize → Verify → Record → Learn loop:

  • Understand: gather requirements, API contracts, code, and permission models.
  • Hypothesize: generate evidence-grounded risk hypotheses.
  • Verify: authorized testers validate them; sensitive actions require human approval.
  • Record: capture reproduction conditions, evidence, conclusions, and uncertainty.
  • Learn: preserve confirmed findings as regression tests, evaluation examples, and change-impact obligations.

AI can assist with the first two steps and evidence organization, but a named human remains accountable for confirming findings, accepting risk, and external reporting. AI-generated tests also need assertion-quality checks: they must actually verify the authorization obligation, not merely a successful response.

One feature is enough for a first session

Choose one feature with multiple roles or lifecycle states and conduct a short session in an authorized test environment. Map the happy path, build a role/state matrix, and validate a few high-value hypotheses. At the end, classify observations as confirmed, disproved, or unresolved. Turn reproducible failures into regression tests, then decide whether to investigate further or switch features.

Do not measure every exploration session by the number of bugs found. A session without a finding can still produce a clearer authorization model, reusable test data, and a better understanding of system boundaries.

What the interview adds to a QA practice.

The interview offers more than a list of security techniques. It models a research discipline: understand the feature before challenging its assumptions; use AI to think faster, but let evidence determine the conclusion.

For quality engineering, feature-led security exploration moves beyond ticking off vulnerability categories toward understanding business capabilities and their misuse boundaries. It complements rather than replaces systematic security testing.

References

ACP (Agent Client Protocol)Active MemoryAgent AuthorizationAgent CardAgent Evals
Share