By Dogan Can Bakir
11 min read
“Open source isn’t about perfection; it’s about putting an idea forward and improving it together as a community.” Rishi (@rxerium)
If you’ve spent any time in the Nuclei Templates repository, you’ve almost certainly run something Rishi engineered. With over 500 templates merged, picked up by the likes of the UK’s National Cyber Security Center (NCSC), California Cybersecurity Integration Center, CERT Polska, Spain’s national security agency, and many others, he’s one of the most prolific contributors to the project. By day, he’s a Senior Security Researcher, where he hunts zero-days and actively exploited vulnerabilities and turns them into detection at scale. Outside of that, he helps lead the UK OSINT community, running events and training. We sat down with him to talk about how he got into Nuclei, how his approach to writing templates has changed, and what he’d tell anyone sitting on a contribution they haven’t shipped yet.
ProjectDiscovery: Thanks for doing this. Before I put words in your mouth, tell people who you are in your own words.
Rishi: Thanks so much for having me, it’s genuinely great to be here. At heart, my work revolves around detecting vulnerabilities, whether that’s actively exploited KEVs, zero-days, or similar, then building the detection methodologies and scripts to scan infrastructure for them at scale. Outside of my day job, I’m part of the executive leadership team of the UK OSINT community, where we collectively run CTFs, in-person events, and provide video training resources, sharing knowledge across the community. A lot of my work ends up feeding back into open source, whether that’s through ProjectDiscovery, OWASP, Artemis or other open-source tools. It’s all about building useful things that help the wider community.
ProjectDiscovery: A lot of people know you through your Nuclei contributions, but OSINT is a big part of your work too. How do those two things overlap for you?
Rishi: OSINT, I find is fragmented. The data lives in all kinds of different mediums. You might be searching for a person’s address, an email, a username, a crypto address, or a face in an image. There isn’t much consistency to it. What I find with Nuclei is that it gives you quite a bit of that structure. You can define criteria in a detection template and then automate it at scale against many targets.
So, a lot of the OSINT work that’s repeatable can be automated the same way we automate vulnerability detection. For example, you could take a single username and detect where it appears across hundreds of websites at scale, detect crypto addresses present on a web server or even detect websites seized by the FBI. It really comes down to what you want to detect in any given investigation, and a lot of the time Nuclei has the capability to get you there, sometimes it does fall short, however.
ProjectDiscovery: When did you first come across Nuclei, and what made you actually try it, rather than just bookmarking it like everything else?
Rishi: I discovered Nuclei around 4 or 5 years ago, I was looking for a tool to reliably detect actively exploited vulnerabilities at the time, the Nmap Scripting Engine had its own scripts, but Nuclei kept coming up as a top contender among the free, open-source options, and a couple of things made it stick.
The first was cost, or rather the lack of it. Cost was one of the main things that determined whether I’d adopt a tool, and Nuclei consistently provided those detection scripts for free, time and time again. The second was speed in which these detection scripts were released. Back then, Nuclei had detection scripts for new zero-days and actively exploited vulnerabilities within a couple of days, which was fast. And finally, the project is community driven. You had the whole security community contributing detection scripts, and that’s really the main part of Nuclei for me: that community-driven template library.
From there I started following ProjectDiscovery as a whole, because there were other tools in the tool belt, such as Subfinder, DNSX, Naabu, and Katana, that I was already using in my day-to-day recon workflows. They all piped into one another really well. You’d chain the tools together, adjust your flags and configs depending on the use case and whether you were scanning at scale, and get exactly the output you wanted. One of the other early things I leaned on was the Nuclei GitHub Action, which initially let me automate scans, again all structured in a YAML file. When you’re scanning a significant number of hosts at once, that automation, load balancing and all, makes a real difference. Everything fit together.
ProjectDiscovery: At what point did you go from using it to thinking, “I could contribute to this”?
Rishi: The tool was new at the time, so there were a lot of detection gaps. But I remember a zero-day vulnerability which I needed to detect. If I recall correctly, it affected Cisco iOS XE and we needed some way to detect it at scale. There was a working PoC, so, I thought, why not convert it into a Nuclei template, create a PR and contribute back? At the time I wasn’t so sure about the formatting or syntax of a Nuclei template, but I raised it anyway, and after a bit of support it was merged!
What really stuck with me was the community side of it. After I raised the PR, a few people left comments, things like “why don’t you look at creating the template from this angle,” or “why don’t you structure the template this way.” I really liked that, because everyone has a different perspective, and honestly that feedback improved the PR well beyond what it was when I opened it. That collaboration ended up being one of the most important parts of the whole process which has allowed me to continue to contribute even to this day.
Generally, because there were so many detection gaps back then, it was easy to find something to contribute. These days a lot of the templates are well covered, so it’s harder, though never impossible. There are always going to be gaps, whether in the CVE template library or in other categories. But the community support, plus good documentation, made it easy for me to get started.
ProjectDiscovery: When you write a template now, what’s your typical workflow? How do you go from an idea to a finished template?
Rishi: My workflow is very much dependent on current events and the threat landscape. I’d check the advisories, build the product-detection and/or CVE templates - this involves researching the affected product, find hosts on Shodan or Censys, or spin up my own instance to replicate the product or service, and build the template from there, validating with the right matchers and extractors.
A few habits I picked up over time. First, always check whether the template already exists, because in most cases nowadays it does, and you don’t want to duplicate work. Second, find reliable fingerprinting methods. You don’t want a weak matcher keying off something like the word “version,” because that could appear on all sorts of sites and isn’t specific to the product you’re detecting. Over time I moved towards stronger matchers and heavier fingerprinting (such as favicons and unique hashes). And finally, the most important step, validation. Before I open any PR, I validate the template against multiple hosts confirmed to be running that specific product, excluding any honeypots. That’s what keeps the templates accurate.
Most recently I’ve been focused on following more of a proactive approach by detecting AI, LLM, and machine learning products and services, building out those categories in the repository which has been progressing very well. I think recent additions have been near to 50 new fingerprints over the last couple of months, detecting things like OpenClaw (formerly Moltbot), Chroma DB, liteLLM and other popular products in that space. The idea is to detect the product first, then go a level deeper: you can say “company X is running this,” but also asking the question “is it authenticated? Are there API keys exposed?” You build on that product detection to see what else you can learn about a host or broadly a company.
I’ve also started to utilise AI to help create templates only where it makes sense to. By default it needs guidance. The typical frontier models pick up Nuclei’s format reasonably well and have access to the documentation, so they don’t do a bad job, but from experience you still need to steer them. If I want something very specific, I’ll encode that in my instructions to the model as a skill and then slowly adjust your skill overtime to cater to your needs.
ProjectDiscovery: How do you decide what’s worth turning into a template and what isn’t?
Rishi: I follow two rules. The first: if I’ve had to check something manually twice, it’s probably worth automating. If I find myself finding the same thing on the internet more than once, I can usually automate it with Nuclei and build a template that detects not just that one thing but a whole class of similar things.
The second is community value. I might find something interesting, but often ask myself if other security researchers find it interesting too. There’s a real difference between a good, broadly useful template worth submitting and something only you would ever run on your own machine.
ProjectDiscovery: Of all your templates, was there one that was particularly hard to build, and what made it difficult?
Rishi: I wouldn’t say any single template was hard, exactly. It was more that some took a while, not because the logic was difficult, but because they needed extra validation and testing.
The one that comes to mind is a privacy-policy template. It detects privacy policies on any given website and extracts information from them. So if a company collects gender, payment information, credit card details, and so on, the template flags that domain as collecting that data so users can be aware of it. The challenge was that it relied on matching fairly generic words like “card” or “payment information,” which made it trickier and prone to false positives. I found ways to validate it more thoroughly and make it stronger than it first was, but it took time, and finding enough websites to validate it against took time too. On top of that, I had to make it support multiple languages. I don’t fluently speak German, French, or Spanish fluently, but I did my best to make sure the template could handle them. So, not hard to create, just a lot of careful research and testing.
ProjectDiscovery: Your templates have been recognised by CERT Polska, the UK’s NCSC, Spain’s national security agency, and others. How does it feel to hear that kind of feedback from those institutions?
Rishi: Honestly, it was very completely unexpected. With CERT Polska, I’d submitted a detection for a Roundcube webmail vulnerability, and they reached out by email to say they loved it and asked whether I’d be willing to let them use it in their own tool, an open-source reconnaissance platform they have called Artemis. I was genuinely shocked, and honestly quite humbled, to receive the email. When I submit a template or a detection script, it’s usually just about giving back to the community, so I never expected it to have that kind of reach, to have governmental and law enforcement agencies wanting to incorporate it into their systems but its also a motivator to keep going.
ProjectDiscovery: Over 500 templates is a real milestone. Did hitting that number feel like a moment, or just another day?
Rishi: It was one of those milestones I didn’t even realise I’d reached. I was working on another template and opening another PR when people started pointing it out: “Do you know you’ve hit 500 templates?” My reaction was honestly, “Wait, what?”
When you do something consistently for long enough, it just becomes part of your routine. You stop thinking about the numbers and focus on the work itself. Looking back, 500 templates is definitely something I’m proud of, but the number was never really the goal. For me, the most rewarding part has always been contributing something useful to the community. Knowing that a template I created might help someone discover an issue, improve their security posture, or save them time means far more than any milestone ever could.
ProjectDiscovery: You’ve written templates across a lot of different areas. Would you say your overall approach has changed since you started, or do you still look at it the same way?
Rishi: It’s definitely changed over time. When I first started, I was mostly focused on reacting to newly disclosed vulnerabilities and getting coverage out as quickly as possible. While that approach still follows, these days, I spend a lot more time thinking ahead and looking for patterns or technologies that might become relevant before they make headlines. I’ve also become much more collaborative in how I work. Now, I see it as a community effort. If I’m unsure about something, I’m happy to open a draft PR and get feedback from others. Some of the best templates come from those discussions, where different people bring different perspectives and experiences to the table.
The biggest change, though, is probably how I think about the end user. I’m not just asking whether a template works anymore; I’m asking whether it’s reliable, maintainable, and genuinely useful in someone else’s workflow. That broader perspective has definitely shaped the way I approach template development today.
ProjectDiscovery: Is there a particular template you’re proud of, and why that one?
Rishi: The ones I’m most proud of are the ones that have a real-world impact, the ones picked up by national agencies, or tied to active incidents. OpenClaw is a good example. When the platform started gaining attention earlier this year, there were a lot of exposed instances with no authentication and exposed API keys. It felt like exactly the kind of issue where a template could help people quickly identify and address a genuine risk, so creating one was an easy decision. Seeing the template and the research provide practical value to the community is probably what I enjoy most.
Beyond that, I’ve recently been drawn to AI-related exposures, which I think will become increasingly important over the coming years, as well as templates for actively exploited vulnerabilities and zero-days. Those tend to see a lot of adoption because people need actionable detection as quickly as possible, and it’s satisfying knowing something you’ve built is helping defenders and researchers respond to threats in real time.
ProjectDiscovery: Last question. What do you wish more people understood about contributing to open source, especially open-source security tooling?
Rishi: I think the biggest thing I wish more people understood about open source is that you don’t need to have all the answers before you contribute. Some of my earliest contributions weren’t perfect. I’ve had PRs challenged, templates revised, assumptions corrected, and plenty of things I’d do differently today. But that’s the whole point of open source. It isn’t about getting everything right on the first attempt; it’s about putting an idea forward and improving it together.
The best contributions often start with someone scratching their head. You run into a problem, build a solution, and then realise there are thousands of other people facing the same challenge. Open source gives you a way to solve that problem collectively rather than in isolation. Along the way, you learn from people with different perspectives, build relationships, and become part of a community that wants to see each other succeed.
The other thing is consistency. One contribution rarely changes everything, but small contributions made consistently over time can have an enormous impact. Whether it’s a template, a bug fix, documentation, or research, every contribution makes the ecosystem stronger for everyone who relies on it.
So, if you’re sitting on an idea, submit it. Open the PR. Share your thinking, explain your approach, and invite discussion. It doesn’t need to be perfect, because perfection isn’t what open source is built on. It’s built on collaboration, curiosity, and people who are willing to contribute something that might help others.
You never know where a single contribution might lead. It could teach you something new, introduce you to lifelong collaborators, or become a tool that helps thousands of people. But none of that happens unless you take the first step and put yourself out there.
Want to see more of Rishi's work?
Rishi's templates are live in the Nuclei Templates repository, spanning CVEs, product detections, and the growing set of AI and LLM fingerprints he's been building out. It's the best way to see his approach in action, and a good place to start if you've been thinking about contributing your own.
Explore the repo: https://github.com/projectdiscovery/nuclei-templates
Thanks for reading, and thanks to Rishi for sharing his time and his work with the community. Take care, and we'll see you in the next Community Spotlight.