GitHub 漏洞赏金如何磨炼一位研究者的安全技能

As Cybersecurity Awareness Month continues, the GitHub Bug Bounty team is excited to spotlight another top-performing security researcher from the GitHub Security Bug Bounty Program: @r31n!

As home to the world’s developers, GitHub is dedicated to the security and reliability of the code behind millions of projects, and our Bug Bounty Program remains a cornerstone of that commitment. Collaboration with external researchers is one of the most effective ways to improve security, and every year, the community helps us identify and fix vulnerabilities that make the platform safer for everyone.

The security research landscape is changing rapidly. AI has lowered the barrier to entry and become a genuine force multiplier. We use it across our own internal security programs, and we welcome researchers who do the same. However, what separates great research has not changed: validation, a working proof of concept, and a clear demonstration of real security impact. The tools do not matter; the quality of the work does. The researchers we spotlight this month exemplify exactly that standard through findings that are verified, reproducible, and demonstrate that a security boundary has been crossed rather than simply theorizing that one exists.

Researchers who consistently work at that level can earn an invitation to our permanent VIP program, which offers higher payouts, faster response times, and early previews of beta products and features. Learn more about how to qualify on our public bounty site.

As we wrap up our Cybersecurity Awareness Month celebration, we interview @r31n, a researcher renowned for their work on GitHub Enterprise Server, where they have repeatedly uncovered high-impact issues. Their reports consistently include working proofs of concept and clear reproduction steps, helping our engineering teams move from triage to remediation more quickly.

How did you get started in security and bug bounty, and what keeps you coming back to GitHub’s program?

I got into bug bounty because I wanted a way to keep developing my security skills outside the environments I work with every day. It exposes me to different products, technologies, and architectures I probably wouldn’t run into otherwise. GitHub is one of those programs I keep coming back to because there’s just so much surface area. It’s large, complex, and constantly changing. New features ship all the time, so it never really feels like a finished target. They also work closely with researchers, the bounty structure is competitive, and the swag is a nice bonus. It’s simply a program I enjoy spending time on.

What are your favorite classes of bugs to research and why?

I don’t really have one favorite bug class. What interests me more are exploit chains, especially cases where a few things that seem relatively harmless on their own come together and create something much more serious. An open redirect is a simple example. By itself, the impact might be limited. But if you find an allowlisted-domain SSRF that follows redirects, suddenly that open redirect can become a useful part of a much bigger chain. That’s probably the part of vulnerability research I enjoy most: finding those connections, looking at two or three separate bugs and realizing they can be combined in a way that wasn’t intended. It takes some technical knowledge, but also quite a bit of creativity.

How do you keep your skills sharp and stay on top of new vulnerability trends?

It’s actually a mix of different things. Security blogs, vulnerability write-ups, conference talks, proof of concepts, research papers, courses. I try to learn from wherever useful work is being shared. But most of it only really sticks once I try it myself. I can read a vulnerability write-up, but working through it myself gives me a much deeper understanding. If I actually reproduce the technique, play around with it, break it, and figure out why it behaves the way it does, that’s when it really stays with me. And later, when I see a similar pattern on a real target, it’s much easier to recognize.

What tools or workflows have been gamechangers for your research? Any lesser-known utilities you’d recommend?

I tend to prefer manual investigation and small, purpose-built scripts over large automated toolchains. If I notice I’m repeating the same task during research, I’ll usually automate that specific part. AI has probably impacted my way of working more than any individual security tool.

Even then, I think mindset matters more than tooling. You can become extremely good with a particular tool and still miss interesting bugs because you’re only looking at the target through the lens that tool gives you. Sometimes relying too heavily on tooling actually narrows the way you think. Tools change. Techniques change. Curiosity and persistence tend to age much better. So, I don’t really have one tool I’d recommend to everyone. The most useful tool is usually the one that helps answer the specific question I’m investigating.

Walk us through your general approach. How do you pick a target area, and how do you go from “interesting feature” to a confirmed finding?

I usually start by mapping out the application and getting a feel for how its different parts fit together. I tend to spend more time on complex functionality, integrations, trust boundaries, and anything that behaves a little differently from the rest. Experience and intuition matter too. Some areas simply look more likely to expose interesting security behavior. From there, I often think in terms of sources and sinks rather than starting with a specific vulnerability class. A source is a point where attacker-controlled data enters the application.

Think of a request parameter, uploaded file, API input, or data coming from another service. A sink can be a security-sensitive operation that consumes this data, for example, a network request, file access, process execution, database query, or authorization decision. The interesting part is tracing the path between the two. I look at how the data is transformed, validated, or passed across trust boundaries, and whether those controls are sufficient before it reaches the sink.

I like this approach because it lets me reason about attack paths without forcing my investigation into a predefined bug class. Sometimes the vulnerability only becomes obvious once you understand how a particular source can influence a security-sensitive operation. I consider a finding confirmed once I understand the attack path, can produce a working PoC, and can explain the impact.

Do you use AI in your research? Where does it genuinely help and where does it fall short?

Yes. Quite a lot, actually, but mostly as an accelerator. I use it for navigating unfamiliar code, finding call sites, tracing data through the codebase, and understanding how a system is structured and how its components interact. I also find it helpful for writing PoC scripts once I’ve identified the vulnerability.

Where it works best is when the question is specific. “Is this application vulnerable?” usually isn’t a very useful prompt. Give it the right context, explain what you already know, and ask a narrow question, and the quality goes up dramatically. There’s a bit of a paradox there. AI becomes more useful as you understand the problem better yourself. And I never treat its conclusions as facts. Hallucinations, false positives, bad assumptions, and confidently wrong answers are all common. Everything should still be manually verified. AI makes my work faster. However, it doesn’t replace understanding the application, developing intuition, or proving that something actually works.

What’s your guidance on using AI responsibly in bug bounty?

Use it to improve your research, not to outsource responsibility for it. If AI tells you it found a vulnerability, that doesn’t mean you found a real vulnerability. You still need to reproduce it yourself. You should understand exactly what’s happening, which security boundary or control is being violated, and what the real impact is. Ideally, you should understand the issue well enough that you could write the report without AI at all. Build a clear PoC. Make sure the security team can follow it. Know why every step matters.

AI has lowered the barrier to doing security research, which is great in a lot of ways. But you can also see the downside in the number of unverified reports teams now have to deal with. AI should make research better. Not just make more reports.

As the industry ships more AI-powered features, does testing them require a different mindset than traditional web bugs?

Yes. Conventional vulnerabilities still matter, but attackers may also be able to influence a probabilistic decision-making component through the data, instructions, or context it receives. But getting a model to say or do something unexpected isn’t necessarily the interesting part. The more important question is what that influence allows an attacker to achieve. Can they access something they should not or cause the system to act with privileges the attacker does not have? That’s why I don’t think model-level guardrails should ever be treated as the only or primary security boundary. You still need deterministic controls around the model. This includes proper authorization, least-privilege access, isolation, and validation. The surrounding systems matter just as much as the model itself. And traditional application security doesn’t disappear just because AI is involved. Model output should still be treated as untrusted input. If that output ends up in a browser, database query, shell command, web request, or another downstream system without the right controls, you can still end up with very familiar vulnerabilities: XSS, SQL injection, command injection, SSRF, and so on. I think the model is new. A lot of the dangerous sinks aren’t.

What’s one thing you wish you’d known when you first started?

Learn systems, not checklists. When I started, I was tempted to collect huge lists of techniques, payloads, tools, and bypasses and then work through them one by one. Those lists can be useful.

I still use them. But understanding how a system works has been far more valuable. Its internal logic. The data flows. Trust relationships. Assumptions. Why one component is allowed to talk to another. Why a particular restriction exists in the first place. I also learned not to assume something is secure because it looks secure, or because plenty of researchers have already tested it.

A lot of interesting research begins with: “Why does this work this way?” rather than “Which payload should I try next?” There’s some luck involved too. Sometimes you spend days following something that goes absolutely nowhere. Then you notice one tiny detail almost by accident and it turns into a high-impact finding. You can’t control that part. You can control whether you keep questioning things long enough to notice it.

What advice or resources would you recommend to researchers trying to land their first valid report?

Get comfortable with the fundamentals, then pick one program and one target and stick with them for a while. Constantly jumping between targets makes it difficult to build a real mental model of any of them. Use the application. Explore weird flows. Test different roles and permission levels. Read the documentation. Watch the requests and responses. Look at the APIs. Labs, courses, public write-ups, disclosed bug bounty reports, and intentionally vulnerable applications are all useful too. They teach you where bugs tend to hide and, over time, help build the intuition to recognize similar situations elsewhere.

One mistake I see a lot is relying on tools too early. Another is giving up because the obvious tests didn’t find anything. Tools help. They don’t build the mental model for you. And when you finally do find something, spend the extra time validating it properly. Create a working PoC. Make reproduction easy for the security team. Understanding one target deeply will usually get you further than trying to find a bug as quickly as possible.

What do you enjoy doing when you aren’t hacking?

Endurance sports, mainly road cycling, especially in the mountains. I enjoy the physical challenge of a long climb and pushing myself over longer distances. It’s also a great way to get away from screens for a while and spend some time outside. There’s actually something about climbing that feels pretty similar to vulnerability research. You can put in a lot of effort without seeing much progress. Sometimes you have no idea whether what you’re doing is going to lead anywhere. You just keep going. And every now and then, it pays off.

Any social media profiles you’d like to share with our readers?

You can find me on HackerOne.

Thank you, @r31n, for participating in GitHub’s bug bounty researcher spotlight! Each submission to our bug bounty program is a chance to make GitHub, our products, and our customers more secure, and we continue to welcome and appreciate collaboration with the security research community. So, if this inspired you to go hunting for bugs, feel free to report your findings through HackerOne.

The post How bug bounty sharpens one researcher’s security skills appeared first on The GitHub Blog.