I’ve been thinking a lot lately about how the best security researchers approach their work, and it’s nothing like how most developers think about bugs. We tend to hunt for individual vulnerabilities in isolation. A researcher spots an open redirect here, an SSRF there. But the researchers who consistently find high-impact issues? They’re thinking in chains.
Recently, I came across an interview with @r31n, a top performer in GitHub’s Bug Bounty Program, and their approach fundamentally changed how I think about vulnerability research. Instead of looking for specific bug classes, they think about sources and sinks. A source is where attacker-controlled data enters a system. A sink is a security-sensitive operation that uses that data. The vulnerability lives in the path between them.
This matters because it reframes security from “find bad thing” to “trace the impact.” That open redirect? Harmless on its own. But if it chains with an SSRF that follows redirects, suddenly you’ve crossed a security boundary that matters. That’s the difference between a low-severity finding and something that actually impacts users.
Tooling Won’t Save You
Here’s what struck me most: @r31n explicitly said they prefer manual investigation over massive automated toolchains. AI has been a bigger game-changer than any individual security tool. But they also warned against over-reliance on tooling. You can become really good with a specific tool and still miss interesting bugs because you’re only looking through that tool’s lens.
This is a hard truth for those of us who love automation. We want to scan, find, fix, ship. But security research requires something different: curiosity, persistence, and the ability to think sideways. Tools change. Techniques change. Understanding how systems work and how data flows through them? That ages much better.
I think there’s a real lesson here for how we approach security in development workflows. We can’t automate our way to secure code if we don’t understand the attack surface. Tools should accelerate our thinking, not replace it.
Where AI Actually Helps (And Where It Doesn’t)
The interview touched on something I find myself wrestling with constantly: how to use AI responsibly in technical work. @r31n uses it heavily, but strategically. For navigating unfamiliar code, finding call sites, understanding system architecture. But they’re ruthless about verification. AI hallucinations are real. Confidently wrong answers are common.
The paradox they identified is perfect: AI becomes more useful as you understand the problem better yourself. When you ask it a vague question like “Is this vulnerable?”, you get vague answers. Ask it a specific question with context, and the quality improves dramatically. But you still need to reproduce everything yourself. AI makes work faster. It doesn’t replace understanding.
This is critical for the industry right now. We’re seeing AI code generation become mainstream, and there’s real value there. But if developers start treating AI output as gospel without understanding what the code actually does or how it interacts with their system, we’re building on sand. The tool isn’t the problem. Outsourcing responsibility is.
What This Means for Your Threat Model
The research methodology @r31n described has implications that go beyond individual bug hunters. If you’re building software, understanding that vulnerabilities often exist at boundaries and in exploit chains changes how you think about defense. It’s not just about fixing individual bugs. It’s about understanding your trust boundaries, how data flows across them, and what security-sensitive operations consume untrusted data.
This is why security needs to be part of the development conversation from the start, not bolted on at the end. The most dangerous bugs aren’t always the obvious ones. They’re the combinations of things that seem relatively harmless individually but create serious impact when chained together.
It’s also a reminder that security is still fundamentally about people and thinking, not just tools. The best researchers aren’t the ones with the fanciest automated scanners. They’re the ones asking the right questions, understanding systems deeply, and making unexpected connections.
If we want to build more secure software, we need developers who think like security researchers: tracing data flows, understanding boundaries, and asking what could go wrong at each handoff. The tools will evolve. The thinking matters most.