Building Open Source Communities With Rishiraj Sharma

EPISODE 124

“Rishiraj Sharma: The most common workflow is running against your attack surface. So in an organization, you might have a pretty large set of assets, and these could be varieties of applications or APIs, I mean, in your environment. So you basically give your list of assets to. These could be IPs. These could be domains and/or API endpoints that you want to run against, and you pass it to Nuclei and give your templates that we have designed and run against them.”

[INTRO]

[00:00:02] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators, and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk’s developer security platform helps developers build secure applications without slowing down, fixing vulnerabilities in code, open source, containers, and infrastructure as code. To learn more, visit snyk.io/tsd. That’s S-N-Y-K.io/tsd. 

[INTERVIEW]

[00:01:22] SIMON MAPLE: Hello and welcome to another session of The Secure Developer. My name is Simon Maple, and I'll be the host for this session, which brings along Rishi Sharma, and Rishi is the CEO and Co-Founder of ProjectDiscovery. Welcome, Rishi.

[00:01:35] RISHIRAJ SHARMA: Yeah, thanks for having me. Really appreciate for inviting.

[00:01:39] SIMON MAPLE: Yes. Absolute pleasure, absolute pleasure. Now, Rishi, why don't we start with a little bit of background into you personally? Tell us a little bit about how you got into the security space and what steps you took to join us.

[00:01:50] RISHIRAJ SHARMA: Sure. My career started in Bug Bounties in 2012, 2013. It was before the era of HackerOne and Bugcrowd platforms. I used to hunt on these traditional programs like Facebook, Google, and that's where my journey got started. I probably did it for two years full time. Then for the rest of my career, I mostly spent time working as pen tester, cybersecurity engineer, application security engineer. I also took the job of product managers in between and also worked as product designer in between, mostly for startups and tech companies. But, yeah, before pursuing this career, I mostly worked as an application security engineer. 

[00:02:32] SIMON MAPLE: Wow. So you had a variety of roles before moving into the security space then. 

[00:02:37] RISHIRAJ SHARMA: Yeah. 

[00:02:37] SIMON MAPLE: Always been fascinated around products. So that's why I co-founded few small startups, as well as worked with startups. So I spend the majority of my career working startups, just to gain the momentum of building products, how the products are being shipped, etc. But, yeah, I love the overall journey throughout these years.

[00:02:58zs] SIMON MAPLE: Excellent. Well, that's great to hear. Today, we're actually going to be talking about a specific technology and, in fact, one of the areas in which one of the open source projects that you co-founded and created called Nuclei. This really brings together some of the developer security aspects of the shift that we've seen over the number of years. 

But with an area of security that traditionally hasn't really – Is probably even the furthest away from the left and in and around the kind of like pen testing space and even into the DAST space, if we could have a really – We don't normally talk about technologies and products so much, but we're going to make a slight exception here, simply because this is a very, very interesting space. Also, there's a big open source component to this. 

Now, Rishi talked a little bit about ProjectDiscovery there. Tell us a little bit about what the company is, how the company works, how it drives so much open source contributions.

[00:03:50] RISHIRAJ SHARMA: Sure. We are an open source cybersecurity company. We basically develop varieties of open source tools for security engineering. Two of our top categories of tools are – One is asset discovery tools. So we have designed a range of tools for different personas within the security teams for them to easily track the deployments happening across the organizations. The second set of tools are vulnerability assessment tools. Basically, once we have the data around your asset, how do you do the vulnerability assessment on top of them? Or how do you find security vulnerabilities within those? So those are the two kind of categories we have. Although we do have other kinds of tools, but these are the top categories. 

Our approach on the product is like all the co-founders came from security engineering world. If you know like products in our cybersecurity are too complex. These are siloed tools. You can't easily collaborate with the teams. That was some of the fundamentals we kind of designed on building these tools. So these tools are really highly programmable, customizable, really simple to use, and easily integratable across your different workflows. So you can collaborate with different team members. 

We then built it on top of open source to make sure that it drives through the community, not through the vendor-driven approach. Yeah, these are some of the core essential part of our tools.

[00:05:11] SIMON MAPLE: It's very interesting then when you talk about collaboration because, of course, when we try and shift left, when we try and put tools in developers’ hands, that collaboration between the development on the security or who was traditionally owning the security tools, that collaboration across back to the development organization has always been one of the biggest sticking points or one of the biggest problems to the adoption of developers taking on these kinds of new processes or ownership. 

If we're looking at Nuclei specifically, and we'll talk about that in just a sec, but the problems that Nuclei is kind of trying to address, I guess, stem from the DAST and pentesting space. Talk us through the problems that you see in that area right now and why it's hard for organizations to shift that kind of testing further left and trying to put those tools into developers’ hands.

[00:06:00] RISHIRAJ SHARMA: There are many reasons. One, first, if you closely see the cybersecurity industry, we have a range of dozens of different security scanners or tools that you have to manage within the workflows. So that mess of different tools is one key area of security engineering. Then these tools are designed in a way that you can’t easily attach within your modern workflows. These are like really siloed complex tools that can only run by specific security engineer and can't easily attach within the different workflows. 

There are many key reasons. One is, these are closed source products, and you don't really have the programmability or access on doing or programming as per your organizations, so you lose that momentum on designing and customizing your workflows based on organizations. 

So Nuclei, in the context, we kind of like put the focus in a way where this one – We create a framework where all the different kinds of attack vectors can be automated. So whether it's a task fuzzing, or your different kind of attack vectors can easily be programmed, and we are continuously growing within those supportive protocols or supportive workflows. 

Then the piece of template or the programmability, once you compose a template, you can then use it consistently or easily across your different pipelines. So giving that power to the security engineer or different team members within that workflow allow teams to easily minimise the vulnerability lifecycle of your different workflows. 

[00:07:35] SIMON MAPLE: So it sounds almost like a DAST as code or a pentesting as code way of doing things, kind of looking at it from the nest and map of old kind of style of how we update that in terms of bringing it back to code that is shareable and that is contributable, right?

[00:07:49] RISHIRAJ SHARMA: Yes. We use these relational tools in our entire career, and that was one of the key inception of why these tools don't work. When we really spent the time on these key workflows, we kind of like thought, “Okay, we need, first, a really collaborative nature of tools that can easily attach within workflows.” Then giving these powers to the end security engineers would allow a flourish mechanism to push different kinds of attack vectors or easily let security engineers design their workflows. 

Yeah, we kind of like really got inspired from TerraForm initially, so we even call it this whole phenomena like it is like TerraForm. But for vulnerabilities, you compose different vulnerabilities within a template, and then you kind of plug it within your different pipelines, and basically run across your different teams or workflows.

[00:08:45] SIMON MAPLE: So tell us a little bit about the origin story of Nuclei then. How was it created? What were the – Was it a number of projects that kind of like came in and created this? Or did it come from a problem that you were experiencing? Was it requests coming in from the community? How's the concepts thought about?

[00:09:01] RISHIRAJ SHARMA: I can give a bit of insight on how ProjectDiscovery, and then like this whole story was like really attached to the Nuclei. So we all co-founders were like really active on open source community. So I was using one open source tool in my company, in my previous company. Basically, I found one of the top contributors of the same repo that I was using the tool for. He then introduced me to other top two contributors of the same repo. Because we all were security engineers and we had decent software engineering experience, we thought, “Let's dive into some of the core problems.” These problems were like very similar to mine, like these tools are. We have to manage like lots of different tools. These are really complex to manage. These are siloed tools. Don't have collaborative nature. We kind of started with that inception. 

So for the next six or eight months, we didn't know our names. We just got connected on GitHub. We used to communicate with usernames. Probably after six or eight months, we became really good friends, and that was the inception of ProjectDiscovery. We picked this username on GitHub called ProjectDiscovery. Never thought we would ever be a company. We kind of like started just to build the tools for ourselves. So we started putting out tools on the open source, started seeing a decent or maybe like some couple of GitHub stars on our projects. That gave us enough motivation to continue doing it. 

Within that framework, we had this idea of Nuclei. So we put that repo. If you go back to our commit history, Nuclei looks very basic, initially. When we released it, it was very, very basic. But community really pushed because of open source. We got really amazing ideas. We had only one protocol supported. Now, we have like seven or eight protocols supported. So community pushed different features, different workflows we needed to support. So to be honest, like we never thought Nuclei would actually push in the way that it has now got only possible because of our open source community.

[00:11:04] SIMON MAPLE: Yeah. Well, it was an amazing story. It's always great to hear those success stories that are built from the community and from developers who, obviously, finding the projects and the technology useful and useful enough to be able to contribute back to, which is always a wonderful success story. Of course, this isn't just an open source project. There's a commercial aspect to this as well, right?

[00:11:24] RISHIRAJ SHARMA: Yes. Our role was to first build the community when we went full time. So in 2021, we raised a small round. We went full time into ProjectDiscovery. But our entire goal was to build the community, because like we don't really have culture of open source and communities in cybersecurity. So our entire goal was to whether we can really have a community, like really an active community who uses the tools, who contributes back or not. 

Yeah, we always had the plan that, eventually, once we see that there's a community of forestation happening, we will start working or approaching on how to commercialise it. We are pretty early in our stages, but our approach is very similar to like how other open source companies did it, like how HashiCorp and other companies did it.

[00:12:11] SIMON MAPLE: So let's get a little bit deeper then, and you mentioned kind of like Nuclei is using the TerraForm style of working. Tell us a little bit more about that and how people would actually contribute and use those kinds of things because it's essentially pulling what we would consider more black box kind of work or more manual work into code. So tell us a little bit more about how that gets done.

[00:12:33] RISHIRAJ SHARMA: Yeah. Similar to like how TerraForm has the concept of TerraForm templates, we have the concept of Nuclei templates. In each Nuclei template, you can put all the essential information or all the data around vulnerability lifecycle of a vulnerability. So you put the data around what is the vulnerability about description. You put the data around remediation. Or you put out the data around privatization, classification, security data. 

The fourth key part of the template is the validation of the vulnerability, and it is essentially what a human would do to verify the vulnerability. You describe that vulnerability step by step that you call on to this endpoint, you perform this action, you do this, and you compose that into a template. This is basically a basic structure of a template. We support a range of different protocols. So you can basically write almost all kinds of vulnerabilities within Nuclei. Then you can use it to scan against your assets, data, or scan within your CI/CD workflows. Or you can use the same template to do the lifecycle management of annuities. So triaging or creating tickets, remediation workflows. All can be done through the single templates. So the collaboration becomes seamless through the data of template.

[00:13:54] SIMON MAPLE: Very interesting and is a great segue actually. It’s where would you then run Nuclei in terms of executing it in your pipeline. Or is it more on the developers? Or is it later to the right? What would be, I guess, the three primary use cases of using Nuclei?

[00:14:09] RISHIRAJ SHARMA: The most common workflow is running against your attack surface. So in an organization, you might have pretty large set of assets, and these could be varieties of applications or APIs running in your environment. So you basically give your list of assets. These could be IPs. These could be domains and/or API endpoints that you want to run against, and you pass it on Nuclei and give your templates that you have designed and run against them. It will do the assessment across those assets in the fast manner and give you the results back. 

The second one is CI/CD integrations, and Nuclei acts more like an integration tool. You basically put your templates within your CI/CD workflow, and you run against your local application or within your build workflow to ensure that vulnerabilities that you have put as regression are not passing through to the production. So that is the one use case. Even in that use case, like there are many bug bounty programs that are basically giving rewards or incentives on hacker submitting vulnerability along with template. So once they received a template, they put that template into the CI/CD to ensure that it doesn't fit again, as well as they use the same template or run against all their internal external assets to ensure that there are no repetitions of vulnerabilities within other environments. These are top two workflows. 

The second one is more around security engineering. So many pen testers or security engineers design their workflows to automate many of their regular workflows. So if you have suite of checks that you are running through the assessment or the pentest or audit, you design these checks are run against within any audit or your assessment project. These are some of the top three workflows. 

[00:16:03] SIMON MAPLE: Yeah, very interesting. Do you find people who are working with bug bounties, so people who are actually trying to test against folks who run bug bounties? Do you see them using Nuclei a lot for that kind of thing?

[00:16:14] RISHIRAJ SHARMA: The bug bounty hunters or you are talking about bug bounty products?

[00:16:16] SIMON MAPLE: The hunters. 

[00:16:18] RISHIRAJ SHARMA: Yes. They use a lot, and we have one of the largest user base within the bug bounty too. They use it mostly because they have their unique approaches on testing across a large number of assets or a large number of bug bounty programs to find the vulnerabilities faster. Their core approach is to like find vulnerabilities as fast as they can, and Nuclei has done a lot. So basically, whatever their unique techniques that they use it against an application, they basically compose within the templates, and then they run it as if get access to any program or doing any assessment. 

They also do the verification of vulnerabilities against other hosts. So let's say there's part of the vulnerability. They will compose that vulnerability into a template, then they will immediately run against all the other assets they know about, and they will know, okay, this vulnerability also exists across other 10 hosts that they can report against or these five other programs that they can report against. So bug bounty hunters use a lot within their workflow to test unique vulnerabilities.

[00:17:25] SIMON MAPLE: Like you say, being able to supply that template afterwards is very, very valuable to the bug bounty program hosts.

[00:17:32] RISHIRAJ SHARMA: Yes, yeah.

[00:17:33] SIMON MAPLE: Let's move into the CI/CD pipeline. As you mentioned, that was a good use case. Obviously, when we – There are reasons why traditional DAST pen testing isn't as well adopted in CI/CD, certainly not synchronously very often because they can often be very long running. Then particularly, as we mentioned before, when you try and get that collaboration or communication with the development teams, the development teams then very often aren't necessarily as quick to fix as they can be very often because it's not necessarily linked to code, or they don't necessarily have access to rerun testing to make sure things are fixed. How have you approached these types of problems?

[00:18:13] RISHIRAJ SHARMA: So one of the core key problems of a traditional DAST is the time it requires to run the scan. This is, I would say, one of the key reasons that DAST really doesn't fit into the CI/CD or modern chain workflow that it requires a really good amount of time to complete. The second piece is the noise or the false positives that DAST may produce because of the nature of finding unknown vulnerabilities. 

So Nuclei, in this context, works on known vulnerabilities. So you define the templates that you have already found a vulnerability around, and then you are running it in your CI/CD. So Nuclei, it won't really find vulnerabilities by its own. It will only run the scans based on the templates that you have provided. These templates are mostly around the vulnerabilities that you have already discovered. Now, you are using more like a regression engine within your CI/CD workflow. So the time it requires is pretty fast. If you run Nuclei even on a large set of data, it is very, very fast. That was one of the key focus of us on building Nuclei. That it works pretty seamlessly, and it works pretty fast. 

One the second part, the noise and the false positives. Because Nuclei has this concept of validation data, it is basically what a human would do to verify the vulnerability. Now, you have composed that same stripe into the Nuclei template. Now, when you are running or testing against application, the number of false positives are really, really low because you have kind of designed based on your steps. 

Second, even if error or false positive occurs, you can go back to that template, re-edit it, and refresh the pipeline immediately. So now, you have all of our false positives. These are one of the core problems or within the traditional DAST. 

[00:20:03] SIMON MAPLE: Which is a great flow, actually, because you fix it for yourself, but you also fix it for the remainder of the community who are going to use that template as well. 

[00:20:10] RISHIRAJ SHARMA: Yes, yeah. 

[00:20:11] SIMON MAPLE: Really interesting. So the approach, I do like the approach. It's something we actually kind of use a little bit at Snyk as well, whereby in order to sometimes reduce the false positives, you need to consider the idea of allowing potentially some false negatives that are getting by saying that we're only going to look at these vulnerabilities that come in, that we know about the unknown vulnerabilities, for example, or that we have very, very high confidence over. 

But the benefit of that is you actually have something that you can have high trust on, that your development teams will have high trust on and will actually be more likely to want to go ahead and remediate and have the ability to go to remediate versus tens and tens of false positives or hundreds of false positives that just become very frustrating. Developers actually push away against that. So you're actually in a worse place by providing as much data as you possibly can versus very succinct and very trustworthy data.

[00:21:09] RISHIRAJ SHARMA: Yes, and it's really important. It saves a ton of time, both for security engineers, as well as developers. Security engineers, also, waste a lot of time triaging the vulnerabilities discovered by scanners. If those alerts are being triggered within developer’ pipelines, they also get frustrated because now they have spent the time to find that vulnerability that actually doesn't exist. It was just impossible to do. Both within the world of security engineering, as well as developers collaborating, it really saves a ton of time by having vulnerabilities upfront validated by the scanner.

[00:21:42] SIMON MAPLE: Yeah, yeah. So we talked a little bit about DAST, and we talked about pentesting and other things. Fuzzing is another interesting space that we haven't mentioned just yet, well, we've talked about with Nuclei. How does that work in a world that already has DAST, fuzzing, and pen testing? Is it designed to effectively work within that space, where it's complementary to those tools? Or is this looking like potentially a replacement? Do you see companies replacing their existing solutions with this? Or is it more complimentary today?

[00:22:11] RISHIRAJ SHARMA: It depends. We have seen many companies replacing their existing tools because mostly two core reasons, the speed and the false positives. I would say false positives are one of the core reasons that they have stopped using their tools because it's just been two years. Framework is still growing. We just dropped the fuzzing support just a month back, and we are now pushing our framework to support unknown vulnerabilities. But we are very careful on making sure that it doesn't go into the same space where the tool is just producing tons of false positives. 

So there are still areas that we need to work in order to completely replace. But we have seen many companies just replacing that traditional tools over Nuclei.

[00:22:54] SIMON MAPLE: I think one of the other areas there where we talk about DAST and pentesting is ownership. Talk about that in just a second. But I want to kind of hover around community just for one last piece, actually, because communities are an area that needs nurturing. It's something which can sometimes build very organically, which it sounds like that's how it started in and around the Nuclei project. 

But let's talk a little bit about that because Nuclei does have an unusually large community today, and that community does seem very keen to contribute and very engaged. Talk to us a little bit about what you do as an open source maintainer to nurture that community, to help that community. What are the key things that you feel the community needs to remain that engaged and remain that open to feeding back?

[00:23:40] RISHIRAJ SHARMA: Yes. So I think when we started, to be honest, we never thought I would have this kind of community. But one thing we really, really spent a lot of time with our users are like shipping features as a request or like having that one-on-one conversation with them every time they put out the feedback, or they get any enhancement or reports, any bugs, or any security features that they want to see.

I think it was really needed in our industry, where products are generally closed source. They are not generally accessible. You can't easily program. So when we started, people really saw that benefit of having really open framework where they can collaborate. So when we started, we really put a consistent time on any requests that they were putting out, whether it be in the Twitter or GitHub or any other community we generally saw people speaking around Nuclei. I would say like spending close time or building the relations are really, really important. Because we all co-founders came from open source community, we had that natural understanding of how to communicate, how to go after the users or relationship. So I think we did that in a really consistent manner. 

The second piece is education that we might not have done a lot of work, but you're still working on that area, is the area, like just educating through the content or the new varieties of blogs or just pushing out regular content on Discord or GitHub discussions. So people have a lot of ideas that they can go through or new pieces that they can start with, and that was really important for us too. Yeah, I think these were two. Then appreciating back, rewarding back users were also really important. Like once you see users contributing, you call, reward them, appreciate them on your channels or your GitHub social channels. So they feel rewarded that they are part of the community. They are part of that the roadmap or the innovation cycle that we are pushing out tools for. These are some of the core areas. 

[00:25:58] SIMON MAPLE: Yeah. It sounds very common in terms of the things that users want, right? They want to know. They want to see how others are doing things. They want that documentation about how to do things. Then that celebration of success is a core piece to actually almost like ignite the next steps from them personally, as well as others seeing that in their community, which is great to hear. 

I think the as code piece is really important as well, right? That ability to actually – There isn't a black box. There is actually things that are being created as code that actually let users as developers create this, as well as security engineers and others. In terms of your community, what split do you feel you have in terms of developers versus security engineers versus others?

[00:26:40] RISHIRAJ SHARMA: Oh, we started the entire focus on security first, like security practitioners first. The core reasons were like these security engineers are the one who like spend a lot of time doing the assessment, designing the assessment. We feel that products aren't designed for the end user experience of security engineer. So we kind of like really focused on them first, like what are the key problems they face, how to really empower them. Because we all – Well, security engineers, we also had our own problems that we wanted to solve with the tools. So we really, really focused on security practitioners, like how to empower them. That actually like really worked for us. 

As you mentioned, like the piece of code, the programmability allowed different security practitioners to connect and also share their ideas and push how they can design their workflows better. It really worked for us. In terms of developers, we still – I won't say that we have really evolved or like put entire focus on developers. But we are gradually working to ensure that developers have the right experience when using the tools. 

In terms of ratio, I would say like majority of our user base is security practitioners. We do have developers also using, as well as contributing back. But it's actually led by security practitioners and then driven to the developers teams entirely within the organizations or different teams. 

[00:28:04] SIMON MAPLE: Yeah, yeah, interesting. Do you see an ownership change, maybe more on pentesting side versus the DAST side perhaps, of who is going to be running these types of testing or tooling going forward?

[00:28:17] RISHIRAJ SHARMA: Yes. As I mentioned, the Nuclei framework was designed in a really flexible way, and our core idea was that, over time, we will consolidate all the different kinds of security workloads within it. So if you are running as pen tester, you are working as red team engineer, you are working as DevOps, DevSecOps or application security engineer, you can use Nuclei within your workflows. 

Our ultimate goal is like we would want to make sure that Nuclei works on all the different security teams within the organizations. Whether you are sharing around cloud, whether you are sharing around audit or application, Nuclei can fit into those workflows and allow them to easily collaborate within the different teams. But, yeah, over time, we are seeing as a more productive approach on using Nuclei.

[00:29:07] SIMON MAPLE: Yeah, excellent. How are companies using it today? You mentioned a couple of ways just there. But how are you noticing maybe larger organizations or enterprises using that today in their testing?

[00:29:18] RISHIRAJ SHARMA: It's pretty diverse. The one popular work was running or ensuring around attack surface mapping. So those who are working as application security engineers or managing infra use Nuclei, write their templates, design their compliance, and run against those attack surfaces. But we also have pretty unusual varieties of users by engineers working in enterprises. Some of them used for cloud. Some of them used for infra security. Many of them used for application. Some of them used for the purely DAST approach. Some also used, as I mentioned, like bug bounty programs management. So all the reports coming in, they provide incentives on incoming reports, as well as they, by default, write the templates of all the incoming template, even if researcher doesn't submit the template. Then use those templates to like put into different development pipelines. 

But, yeah, because of this flexibility on writing your own templates, we have seen varieties of use cases. But the majority of them use it for attack surface, infra, as well as application security.

[00:30:28] SIMON MAPLE: You mentioned in those templates as well, you can add remediation advice in or remediation steps in those templates. Tell us a little bit more about that. I'd love to kind of like understand how that kind of bridges the gap slightly between what perhaps developers are more used to in and around kind of like pentesting reports or data reports to actually help them fixing issues.

[00:30:51] RISHIRAJ SHARMA: Yes. So there are two remediation workflows. One is when you can put out all the required information to how to fix the vulnerability. The second piece is if you want to automate that workflow, you can define the action, like you want to create a pull request for this version. You can put it into the template itself. When a template executes, it will perform based on that. 

So let's say you have put out all the necessary information on the remediation. If you triage that template, it will create it necessary ticket on whether you're Jira or any picking platform. When developers try to fix it, they can either use the information to fix it or can use the automation that defined in the template to run either on those cases. Once they've put out the fix or remediation, they can rerun the template to see whether the vulnerability is actually fixed or not, without needing to communicate with the security engineer again. 

So we like minimise the gap on doing the back and forth between security teams and developers, and developers can’t rerun to verify and push out the new status based on that.

[00:31:59] SIMON MAPLE: Yeah. I think that's really, really valuable, the fact that developers can actually run the tests themselves as well and actually validate that. They are fixing, and they can even debug using those tests. It’s so different to how it kind of like traditional pen testing is done today, where kind of the areas of trying to understand where an issue can be, based on a pen test being run by someone potentially very, very far away. It's a very different space to try and understand and fix an issue.

[00:32:25] RISHIRAJ SHARMA: Yeah. Also, these black box tools do not give the technical context around the vulnerabilities. With templates, you can actually – Like because these developers are technical, they can really see what's actually happening behind vulnerability. Like this action is being performed. They can really simulate that and can debug that easily, versus like having that black box, just the data around vulnerability without having the technical context behind the vulnerability.

[00:32:52] SIMON MAPLE: Yeah, very interesting. So in terms of – For you, I guess, in projectdiscovery and also for Nuclei, what are the next step? What are the things you're looking forward to doing in 2023?

[00:33:02] RISHIRAJ SHARMA: There are so many things. In terms of open source within the Nuclei, we are going to support a range of different workflows of security protocols. So users can expect to write different like varieties of new vulnerabilities using Nuclei. We are also very focused on supporting or pushing out new templates for different categories. So we have been focused mostly on application. Users can expect more templates in different categories too. Yeah, I think these are the two areas.

We are also going to push out this new program on top of our open source community. We are basically going to reward and incentivise for every contribution’s user make. The key reasons we are doing is that we have felt that we might not be able to scale our internal team to manage these varieties of public templates being contributed because we have to triage them. We have to do the QA stuff. Then we merge back into our master branch. We have felt that we are now getting overburdened with the amount of incoming pull requests coming from the community or new ideas coming from community. 

That's why we are starting this program where users can actually get rewarded based on each of their contribution side, reviewing the templates, putting out the right content, validating the false positives. In each of these steps, they can be rewarded. The ultimate idea is that we can make Nuclei completely community-driven, versus like us running as a vendor-driven. 

[00:34:36] SIMON MAPLE: Amazing. What a goal. It's a great goal to drive towards. Well, thanks very much, Rishi, for sharing that with us and our community. Where can people learn more about some of the tools and some of the ways in which you were building this?

[00:34:49] RISHIRAJ SHARMA: The best place is GitHub. So we use an MS called github.com/projectdiscovery. So project and discovery, like combine them, and we have all the tools listed there. And in each of the readme for any tool you pick, you can see all the documentation or necessary information to get started.

[00:35:10] SIMON MAPLE: Amazing. Well, thank you very much for joining us, Rishi. It's been a pleasure chatting with you. 

[00:35:13] RISHIRAJ SHARMA: Yeah. I really appreciate your inviting. Thank you.

[00:35:16] SIMON MAPLE: My pleasure. I look forward to speaking to you all next time on The Secure Developer.

[00:35:21] RISHIRAJ SHARMA: Thank you. Appreciate it. Looking forward.

[END OF INTERVIEW]

[00:35:28] ANNOUNCER: Thanks for listening to The Secure Developer, and that's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredevloper.com. If you'd like to be a guest on the show or get involved in the community, also find us on Twitter at @devseccon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.

[END]