Inside a Top Bug Hunter's Process: Injection Flaws and Curiosity
GitHub VIP researcher André Storfjord Kristiansen explains how he finds injection flaws others miss — and why curiosity beats methodology when hunting critical bugs.
TL;DR
- GitHub's VIP bug bounty program gives top researchers early access to beta features and direct engineer contact
- André Storfjord Kristiansen (@dev-bio) specializes in injection vulnerabilities and chaining benign bugs into critical exploits
- His process: follow curiosity, dig deeper than the surface finding, document everything to map attack paths
- Best advice: don't settle for simple findings — explore implications to uncover real impact
The Big Picture
Bug bounty programs are how platforms stay ahead of attackers. GitHub's program has been running for years, but as AI features like Copilot and Agent HQ expand the attack surface, the stakes are higher. The company now runs a VIP tier for researchers who consistently find high-impact bugs — giving them early access to beta products, direct engineer contact, and exclusive swag.
André Storfjord Kristiansen, known as @dev-bio in the security community, is one of those VIP researchers. He's built a reputation for finding injection-related vulnerabilities that others miss — the kind of subtle flaws that look harmless until you chain them together. His reports are thorough enough that GitHub's team can assess impact and ship fixes faster.
This isn't a profile of someone who runs automated scanners and collects bounties. It's a look at how curiosity-driven research uncovers the bugs that matter. Kristiansen's approach is less about rigid methodology and more about following interesting behavior until it breaks. That mindset has led him to some of GitHub's most impactful vulnerability discoveries.
How It Works
Kristiansen didn't start bug hunting with a plan. He stumbled into GitHub's program while working on a personal project. His background is software engineering, which means he's wired to ask "what happens if..." when he encounters edge cases. That curiosity turned into a habit of picking apart new features to see how they handle unexpected input.
His specialty is injection vulnerabilities — SQL injection, command injection, XSS, and similar flaws where user input isn't properly sanitized. But he's not just looking for the obvious stuff. He hunts for logical flaws and overlooked assumptions that developers make when building features. Recently, he's been exploring novel techniques to bypass strict content security policies, the kind of defense-in-depth mechanisms that are supposed to stop attacks even when other protections fail.
What makes his work stand out is the chaining. He takes findings that look benign in isolation and demonstrates how they combine into something critical. A minor information disclosure here, a weak validation check there — suddenly you have privilege escalation or data exfiltration. This approach exposes design-level weaknesses, not just implementation bugs.
His process is deliberately unstructured. Most of his significant discoveries happened because he got sidetracked. He notices something unusual, digs into it, and keeps peeling back layers until he understands what's happening under the hood. If it looks worthwhile, he documents every step to map out potential attack paths. That documentation becomes the foundation for a detailed report that shows GitHub's team exactly how the vulnerability works and what the real-world impact could be.
Outside of bug bounties, Kristiansen works as a security engineer focused on software supply chain security. That's a field that's been neglected for years but is now critical as attacks like SolarWinds and the XZ Utils backdoor show how fragile dependencies can be. He spends his day job researching gaps in supply chain security and building solutions to mitigate emerging threats. That professional focus on systemic risk probably shapes how he approaches bug hunting — he's trained to think about cascading failures and hidden attack paths.
He writes his own tools rather than relying on off-the-shelf scanners. He hasn't published them yet, but he's planning to release a toolkit that builds comprehensive offline graphs of GitHub organizations with an extensible query suite to uncover misconfigurations and hidden attack paths. That kind of tooling is what separates researchers who find surface-level bugs from those who map entire attack surfaces.
What This Changes For Developers
If you're building features that handle user input — and you are — Kristiansen's approach is a reminder that defense-in-depth isn't optional. Developers often assume that one layer of protection is enough. Input validation at the API layer, or a content security policy in the browser, or parameterized queries in the database. But attackers don't think in layers. They think in chains.
The bugs that matter aren't always the obvious ones. A minor information leak that exposes internal API endpoints. A weak validation check that allows unexpected characters. A race condition that only triggers under specific timing. None of these look critical in isolation. But when you chain them together, you get remote code execution or account takeover.
This is why GitHub's VIP program matters. Giving top researchers early access to beta features means vulnerabilities get found before public launch. That's cheaper and less embarrassing than patching in production. It also means the researchers who find the most impactful bugs get direct access to the engineers who built the feature. That feedback loop makes both the product and the researcher better.
For developers working on AI-powered features, the attack surface is expanding faster than traditional security tooling can keep up. GitHub Copilot, Spark, and other AI integrations introduce new classes of vulnerabilities — prompt injection, model poisoning, data leakage through training sets. Kristiansen's focus on injection vulnerabilities and bypassing strict policies is exactly the kind of research that will matter as AI features become more integrated into development workflows.
Try It Yourself
If you want to get involved in bug bounty research, GitHub's program is open to anyone. You don't need to be a VIP researcher to submit findings. Start by exploring GitHub's public features and looking for edge cases. What happens if you send unexpected input to an API endpoint? What happens if you chain multiple features together in ways the developers didn't anticipate?
Kristiansen's advice: don't settle for a simple finding. If you discover a minor bug, dig deeper. Explore its implications. Can you chain it with another vulnerability? Can you escalate privileges or exfiltrate data? The difference between a low-severity report and a critical one is often just a few hours of additional research.
To submit findings, use GitHub's HackerOne program. Make sure your reports are thorough. Document every step, include proof-of-concept code, and explain the real-world impact. The better your report, the faster GitHub can assess and fix the issue — and the more likely you are to get invited to the VIP program.
If you're interested in supply chain security specifically, start by mapping the dependencies in your own projects. Look for outdated packages, weak permissions on package registries, or misconfigurations in CI/CD pipelines. Those are the kinds of systemic risks that Kristiansen focuses on professionally, and they're increasingly common attack vectors.
The Bottom Line
Use this if you're serious about security research and want to understand how top researchers think. Kristiansen's process isn't about running automated tools — it's about curiosity, persistence, and understanding systems deeply enough to see where they break. Skip this if you're looking for a step-by-step tutorial or a list of tools to download. The real insight here is mindset, not methodology.
The risk for developers is underestimating how benign bugs combine into critical exploits. The opportunity is building relationships with researchers like Kristiansen who can find those chains before attackers do. GitHub's VIP program is a model for how to do that well — early access, direct communication, and recognition for impact. If you're building a platform with an expanding attack surface, especially one involving AI features, that kind of researcher engagement isn't optional anymore.
Source: GitHub Blog