Machine‑Speed Security Risk in the Age of AI - with Niro Rajadurai of XBOW

Welcome everyone to the Emergent AI in Business podcast. Today's guest is Niro Rajadurai, Chief Revenue Officer at XBOW. XBOW is an autonomous offensive security company that helps enterprises uncover and validate exploitable risk across their applications. Niro joins us on today's episode to unpack how AI is accelerating both software development and the threats it creates, and why enterprises need offensive security that can operate at the same speed and scale as AI generated code. Today's episode is sponsored by XBOW.

The use of AI products or services emerge gives you access to trusted content and real conversations. They're now leading AI brands like Nvidia and Google Cloud work with Emerj to reach Fortune 500. AI buyers. Download our media kit at emerge dot com slash a d one. That's m e r j dot com slash a d and the number one. Now the conversation with Niro. Niro, welcome to the show.

Hi, Marilie. Uh, lovely to meet you, and thank you for having me on the show. Super excited about our conversation today.

Of course, I'm excited as well. Machine speed seems to be the new operating tempo for enterprises, and that sure carries real implications for how organizations secure their data. We're no longer dealing with human based security versus human based attacks. AI is accelerating both sides of the equation, reshaping how quickly systems evolve and how quickly adversaries can adapt. Enterprises aren't choosing new tools, they're adapting to a new tempo. Which sets up the central question for this episode.

What is the emerging scale and velocity of enterprise security risk as AI accelerates both code creation and adversarial capabilities?

Well, it's a super interesting question, and I think, you know, I've been probably blessed to have been around at the birth of AI powered code creation. So in a past career, I was at GitHub, the founder of XBOW, Hugo Demoor was actually the person that invented GitHub Copilot. So the nascent idea of can we actually use A I to go and generate code? So I had the opportunity to see how that has evolved. And so as we kind of look at the journey of what we've been on there with code creation, you know, the very early use cases were we would write some code and the model would help us complete that.

And then that evolved to, like, going into chat and saying, I have a problem, can you help me implement that? And then we had the dawn of the agents, and and we progressed from there. But what was interesting is in the very early days, you know, the models would make very simple security. So it was very critical that as that code was being written, you had to have a very good like application security strategy around what was being built.

And as time went on, the models got better and better, and we had more confidence. Not only in having the model write the code for us the first time, but also leveraging the models to help us go and fix security vulnerabilities. So one of the first use cases after we had this kind of like tool to help developers actually write code, new code was actually because I ran the advanced security business at GitHub, was can we actually use these models to help us remediate vulnerabilities that have been identified in existing code?

And the timing for that was very critical because the models had to have some higher level of probability that they weren't going to introduce a new security vulnerability as part of going through that journey. So it's exciting just seeing how that's evolved to now where you have in the market companies like Cursor and Blitzie, who are basically doing these kind of like developer boxes, right? Where you just put stuff in and, like, fully mature code pops out on the other side.

But still, as part of that, the fundamental requirement for, like, testing and validating software hasn't gone away. And so what we're seeing is as these models start writing more and more code, they're trying to understand the underlying code that they're working on. And there are all kinds of challenges with doing that. You know, the context, like, you know, still in the largest of enterprises, the volume of code that the models need to deal with are still bigger than what the models context window can cope with.

And so it's very important as part of that that we still continue to test. And so what we're seeing is that, yes, the volume of code is going in, but it's introducing new issues in these existing applications. And because a lot of this is happening at a highly automated level, it's also becoming very important as part of that. We can't have a human checking it at the end, like we used to in a PR, it used to be a human goes and evaluates the PR and says, I'm happy with what the model has done.

But if you have a model running at 200 miles an hour and then you have a speed bump of a human, which is ten miles an hour, it just doesn't uh, mix in there. And so that really is, you know, really set up, you know, sets up the opportunity for, like, what does that world look like, where we need to actually verify that the code that we're producing at machine speed is actually also secure at machine speed as well.

And then we we run into kind of the same challenges that we did as humans. So when a human writes code, a human needs to evaluate that code. And then there are some areas where there are real problems and there's some other areas where they look like problems, but they aren't problems. And we call these true positives and false positives. Well, it turns out when AI does the same thing, yes, we've gotten slightly better at it, because now it's happening at AI scale, the volume of code is huge.

So even though we've gotten better at working out what's real and what's not real, the volume of what we need to get through on that side is also huge as well. It's becoming very apparent that any kind of strategy that can be used to help operate at a much higher speed and actually come back with accurate information about what is a real issue and how you can leverage that to go. And then prioritize what the change fix should be on the change set being proposed by the the model that's writing the code or the system that's writing the code is actually really an integral part of that kind of strategy of this new kind of devsecops that's fully AI powered.

Yes, and I think two things are coming up for me that I'd like you to help me with. The first one is what you're saying is that threats are one thing, you have to deal with the threats, but false positives can be just as big of a problem because you can keep yourself busy all day rewriting code and fixing code that never really was the problem. It's being able to distinguish between the two at machine speed.

And what are the pitfalls you're seeing? Are you seeing a lot of companies falling into that trap of all of these false positives and not being able to triage between what are the the false positives and what are the true positives?

I mean, it's the problem that's kept us up at night as as a security person, like it's kept us up at night for for years, and it's still the same problem just happening at at a much larger volume. Cause even a a true positive, a real vulnerability, may not necessarily be something that you want to fix because it's not really exploitable. So when we think about a security vulnerability, there are actually two parts to it. One is like the original vulnerability, so this is a problem.

This code has has a bug in it, which can result in something bad happening. But the second part of that is, is that bug actually really reachable by someone who might want to do something bad with it? So I might have a bug, but that bug is not actually reachable by any of the interfaces that the application publishes and is not reachable by any of the indirect interfaces from what the application has. So in a situation like that, you actually probably don't need to fix it, it's a low critical vulnerability.

And if you have a lot of work to do, you probably don't need to waste your time in doing that because change also introduces risk, right, as part of the process. And so today we call that prioritization, right, where security teams are reviewing vulnerabilities that are being identified by traditional appsec tools and then determining which one of these do I need to fix because actually a bad actor can leverage it. And so really, the big thing that we want to understand as part of this work stream is if there's an issue, is it exploitable?

Because exploitable means I can build something that can use that vulnerability to go and exfiltrate some information or go and run some special command on that target machine or that Asian machine, or do something like that, or use that to kind of launch point to somewhere else. So that really is key thing is like, can you build an exploit? If you can't build an exploit, it's okay, it's Not worth one, but it's worrying about it probably worth

there right now.

something to to keep you up at night.

And then the second thing that came up for me is as you're talking about machine speed and and just the rate of what this is happening at. Are the adversaries really already at the same speed as the coders, the attackers? Are they at the same speed? Are they ahead? Are they lagging, or is it a real time threat?

Yeah, I mean, it's super interesting. We definitely see that happening already. So even, you know, when Google were building up Gemini, they had called out like, you know, they had noticed some adversarial behavior where people were trying to leverage Gemini to some target of applications. Both Anthropic and OpenAI have published many papers where they've detected bad actors trying to leverage their models to do this kind of activities. I think like, what's really scary now is that we all know what's happening with the Anthropic models right now, where they're being gated and and prevent access to the broader world.

But you can do that if it's an enterprise model where you can, like, put enterprise restrictions where an individual can say, well, no one can have this, I will control who has access to this. The problem that we're seeing right now is that some of the open source models are actually as performant as these models that we're trying to gate to the broader community. So if you look at the behavior of what we're seeing out there, actually anyone now has access to that without a gate.

And so, really, it it is a cause for concern because we're getting to the tipping point now where someone can just go and set up their own set of, you know, their own GPU farm. They can put one of these models on there and they can start actually doing this activity. But uh, for sure, we see that activity happening already, like there's been many published articles around, like, you know, attacks that have been done in this way and the patterns that these like frontier lab providers have have noticed as well happening on their systems.

And they've tried to build gates, but the problem is people have now worked out how to go and set up their own real estate and leverages without needing to use the frontier model provider.

If you're thinking about this, I don't want to spend a lot more time on the actual problem side, I want to get to the solutions. But when it comes to these automated attacks, do they seem to follow the same pattern, or is it literally a situation where for security, you ke have to keep your eyes out? Because when it comes to automated attacks, I guess you need the same AI capabilities on the security side to not only flag them, but also to to fight those adversarial attacks.

Do they seem to fall into a specific bucket at the moment?

Yeah, I mean, I think for attackers, their goal is they really need to find one thing to get into the system. So they play like a patient game. They can slowly, like, do their surveillance and and do their prospecting, uh, to get to where they need to. But it comes back to, like, as soon as they find one thing, then they're in and they can start doing all the next steps. Like to kind of use like a sports kind of, uh, you know, analogy, like, you know, the best defense is a strong offense.

And so that's one of the things that we talk about at XBOW. You know, you have to fight fire with fire, and so offensive security needs to use the same tools that these bad actors are are doing. But we need to operate at a much faster speed. Because if I have an application and the application has four holes, the attacker only needs to find one of those holes. As a defender, I have to find all four of those holes, and I have to find them faster than the bad actor can find one of them.

So scale and automation at at a massive scale is really critical to the strategy. And I think the other thing that we say actually is that every three months, the world's best static analysis tool gets launched. Because these models are getting better and better and better and better. Every time a new model comes out, it's just so much better at finding these new kind of nuanced vulnerabilities or tying relationships that weren't obvious before or didn't have the right context, the right training to be able to get there.

And so it's a constant cat and mouse game. New model comes out, it's now the best tool for finding vulnerabilities. So now I need to go work out how to go scale this out across my software portfolio to make sure that if this got in the hands of a bad actor, that they can't actually come in and leverage it to do something, uh, to my system.

Niro, when we look at these offensive capabilities that have proven most critical to actually help companies deal with this machine speed threat, what have you seen working best?

Oh, so, that's a great question. So, I mean, if we think about what's happening here, so, I mean, today, when we talk to companies, you know, a lot of them have a big public facing estate for their application, maybe sixteen, 20,000, you know, in the some of the largest enterprises, public facing application. And so today they're leveraging pen testing as one of the activities. So it's, you know, it's it's a form of offensive security exercise that's focused around regulatory compliance.

But they're only doing this like once a year, or at best twice a year on an application. And they're really because it's so time consuming and expensive, they typically focus it on what they consider their most riskiest application. So the thing is that penetration testing activity is kind of the gold standard of like validating an application, which is why regulators ask you, have you pen tested your application? Who did it? What were the outcome of those results?

So if we wanted to do something like that at scale, it's very important. We can't throw more humans at that problem, we have to drive autonomy. So this is actually one of the biggest opportunities for an autonomous offensive security tool that's able to behave like a human ethical hacker, actually fully autonomous. So it's all just raw compute, which makes it very easy to horizontally scale this to cover the whole estate and do it in a timely manner.

And so then if you think about doing that at at that scale, if you think about the activities that a typical penetration tester is doing, they're doing some reconnaissance on the application. They find some interesting endpoints and say, oh, like this one, look at this. This one takes a URL as a parameter. That's interesting for server side request forger, SSRF. Let me go and investigate what can happen there. Oh, look at this one. This is like a form.

A form is probably filling a database. Oh, let me go and do some experiments to see if I can do like a SQL injection. Now, the thing is, when a human goes to that exercise, a naive human hacker might find a SQL injection and say, Oh, wouldn't it be really cool if I got him to drop all the tables or delete all the data? Data now, an experienced hacker would say, don't do that, because if it's a production system, you're gonna wipe out all the data and that's a bad thing.

It turns out if you use a model to do the same exercise, the model say, Oh wow, I found a SQL injection, I'm gonna do a drop table. And so now, if you want to unleash this at scale within an enterprise, it's not just about having something that can detect vulnerabilities and try and build exploits. It's also about knowing, like, what's the right behavior and what's the wrong behavior to do. And so we call this the governance and safety aspect of running these things at scale.

So when companies think about this, governance and safety is a really critical part of being able to operate this at the scale that they need to for the volume of applications that they have. So if we think about then, what are the things that are really critical? One is like horizontal scaling. So you wanna remove humans from the loop because every time you have a human, you're constrained by is it three a m? Like, does someone have to wake up and like, review what's happening?

So human in the loop, I would say, is a cute response, but really the proper answer is building a proper governance and safety framework around something that can scale these models. And then having a broader framework around these models, which is actually teaching it. How does an experienced offensive security engineer behave like an experienced ethical hacker behave? And then teaching it that these are the boundaries in which you want to work. And by the way, when you see some hints like this, it may not be obvious to you because in the training data that was used to build that model, it's not obvious.

But as an experienced hacker, I can tell you, if you see X, you might want to try Y and try that idea. And so those kind of things are really important for being able to scale, and you need those to be built into the engine. And then the other one is if you're trying to build exploits and things like that, the traditional model providers are designed to explicitly not let you do that because you're actually doing the thing that they don't want you to do exactly.

So how do you build a framework that can autonomously understand here is what's happening? Go on the journey of reasoning and discovery to get to the point where it's like, Hey, this is really a thing. I now need to build a program that can actually go and leverage this and exploit it, and then being able to get that and then giving you the end result, which is not only I found a vulnerability, but I found how to exploit it.

Here is the script to go and do the exploit, and here is the evidence that the exploit worked, correct? Those elements are really critical because now you have something that is actionable. So now a human can come along and say, Oh, we found an exploit. Let me look at the script. Oh, the script looks interesting. I can run it and validate that it's real. I can see the the data that's been produced from running the exploit from XBOW to show me that it really was able to do that.

And I now actually have a meaningful work set or set of information that I can give to a developer and say, hey, in this application, I found this issue. Now, if you remember to the start of my conversation, I said one of the first things that we worked on at GitHub when I was there was this concept of an auto fix. So when a vulnerability is identified, can we use copilot to go and fix it? Well, it turns out that if you give a really good description of the problem, how to go and exploit the problem and what the outcome is if you run that exploit.

It turns out that these models are very good at taking that information and making a suggestion for a fix. So you can now take that and plug that back into that kind of autonomous like AI powered, you know, development along with AI powered detection. You can take that information and give it back to the AI code creation and say, hey, given these parameters and this problem here, here is a bug. Here is all the bug information.

Can you go and fix it? And then once it's done, it can come back and tell you, I think I fixed it. And then you can have the platform come back and say, Okay, well, let me retest it, right? Validate that you has fixed it in the right way, or did you make a naive fix where the original exploit I gave you can't be used? But if I change a couple of parameters here or there, then, uh, then we can do that.

You know, there's there's a great example of, and we actually published this on our website of one of our customers where they were working with the WAF. And they had basically said, like, you know, this string or this URL should not be accessible. And so what happened was that actually they did the fix of like putting the string in of saying, like, okay, look for this pattern and if this pattern is there, don't let it happen.

But in programming, you can represent letters as they actually are, or you can represent them as an ASCII code by putting a percent there. And so XBOW said, Well, what happens if I take one of these letters and put them in their ASCII code? Will it work? And it got through because the filter was looking for the the raw, the letter match, not for the encoded match. And so, like, those kind of things are super interesting of like, did I fix it?

did I fix it naively? And then providing that feedback back into the loop to go and do it. So the scale motion is I'm gonna run this thing at scale to go and identify all these vulnerabilities and then actually the vulnerabilities that matter because I was able to build the exploit. And then once I have a working exploit, I can trigger a patch fix exercise, and then I can collaborate with the patch fix exercise to make sure that the patch fix is being done in the right way.

And I think that's the big, big next part of this problem is like, great, we're finding lots of issues. How do we fix it? Well, you have to integrate into the developer ecosystem and work in this new kind of agentic way of fixing software of building software. I'm going to feed it to you back very naively, and you can fix me where where I got it wrong, just to sum it up in a way that hopefully the audience and I will understand.

So it seems to me that in the past we did pen testing, you did it once or twice, three times a year, maybe just to comply and make sure that you don't get into trouble with the regulations. And then now what's happening is number one, we hear from so many companies how many and how quickly they implement AI apps, software, et cetera. This is a speed that no human can handle at this point, no human team can handle it at the moment.

So if I I'm understanding you correctly, you are using expert coders, expert, let's call them the the good hackers Yep,

that check. They are training the models, training the model on a certain amount of data, checking how good they are, teaching them, making them better and better and better. At that point, when you're at the point where the expert human hacker is saying, yes, this is this model is now in a good spot, then you can run it horizontally over your company apps and software. And they are probably, if I'm understanding it correctly, they are probably some of those agents that you can send out across all of your apps.

Because some vulnerabilities are sort of universal across apps, easy, easy access, things that you need to check for, and then some of them have to be more specialized for each type of software, each, uh, type of API, app, et cetera that you have in place. And then instead of having the human in the loop, because that becomes a bottleneck, you have to make sure that the governance is set up right from the start. Because that eliminates at least to a certain point the human in the loop.

You don't have to bring in the human every time because you've set up the governance correctly. So that's an integral part of this whole process is ensuring that your governance is in place. And then making it completely auditable. In other words, it's not just finding the the bug. It's actually telling you is this exploitable, how it is exploatable, writing the script of if they were a hacker, how they would come in and actually hack this, and then give you a probable fix for that.

So it's sort of an all in one process, and then it might come back to your expert auditor if it's acute enough. Or maybe you've got a higher level agent that, let's call them a managerial agent for, uh, your security. And only then will it go in and make the fix, come back again, test the whole process again. Have you fixed it? Has it been too naive? Is it too easy to get back in? You've just made a let's call it a surface fix, not not a deep enough fix.

And this happens at machine speed with a group of agents that you send out with within your company. Am I understanding it correctly at all?

pretty close couple of minor things. So one is we actually don't try to to train the model, we we leverage the models as they are, but we have some techniques where, for example, the way to think about it is every time XBOW or this like you take a step through this process, you have to go and reason, like, what's the next step based on the feedback that you get? In software engineering, we have this concept of pair programming, where two developers sit side by side and work, and it turns out they're really productive because they're diverse thinking, you know, strengths, weaknesses, and collaborate, and you get great results.

So one of the things that we discovered here at XBOW very early on was actually that pairing different models together as part of a reasoning process actually results in higher quality and better results than just leveraging a single model. So you might like, for example, have like an anthropic model, like, do this one, and then Gemini kind of steps in here, and then Claude does the next two, and then Gemini comes in. There are like these kind of things that we use, and so we call them alloy models.

So that's the first thing is like, you know, different models have different strengths, and you can pair them together, and that diversity of thinking actually gets more interesting vulnerabilities. It is better than any individual model might solve. The second one is without necessarily training the model, you can have coaching and guidance. So you can provide as part of the context window of what the model is about to do, some guidance about how to go and approach the problem.

And it turns out, like, for the cost of trying to go and train a model and do all these things, actually providing this coaching as it's about to go and take a step is actually pretty, pretty close to being effective. The same way, and so that's the approach that we take. And it also then means that as soon as a new model comes out, we don't have to spend like a week training it. We can immediately overlay our expertise and tune the guidance that this particular model needs to get it to behave in in the way in the way that we want to.

So, so that's the first aspect. The second aspect is that when we think about how the market for autonomous offensive security sits today, and it's it's only a year old, to be clear. I mean, XBOW's two and a half years old. We did our big, like, you know, announcement, Hacker One, where we became number one back in July last year, and many new players have come to that market. So if we think about how the typical autonomous offensive security tool is operating today, they're trying to manage the ecosystem of can I go and look at this application?

And can I do some assessments? And can I get some information out of that? And then can I integrate with the existing tooling that sits in within that perimeter or within that business for building and shipping software? So that's what everyone is doing today. And if you think about it, like everyone already has their favorite model for coding of, right? The it's either the cursor or Devin or Copilot, or whomever it is, like everyone's kind of got their preference today.

So it's much easier to work with something that's already gated and cleared than to be like, oh, and I have my own new thing, and by the way, it's my side project, right? It's not an offense. So so that's the other important thing is that integrations into the ecosystem are really important for where we are today until the next step happens, and maybe more consolidation and aggregation happens in the market. So those are the the two key things.

And so that autonomous offensive security tool is deploying its solver agents or these attacking agents and validators and all the different pieces to go and do the work of, like, what a ethical hacker or a good hacker would do? It's bringing that information and then it's integrating the rest of the enterprise software development tool stack to say from this information that I have, here's what you might care about. What would you like to do? And then that that those set of agents can then take that information, do the necessary work, and once they think they're done, they can come back and say, Hey, I think I've addressed the problem that you identified.

Can you take another look? And that's that's what works. So, so that's really the key distinction is one is like, it's still pretty fragmented, how those pieces are, so there are many tools working together, integrated. And then the other one is from a model perspective, it's not cost effective today to try and train a model and keep up with all the pace at which the frontier models are driving cyber. But it's very important to build the framework around it that you can plug in any model and you can still get it working effectively, doing all the problems that I kind of spoke about earlier on of like staying within governance and safety boundaries, being able to build the right exploits

and not like fighting with the model to do those things.

And that actually makes more sense to me because as a framework, it's a lot faster to implement and it sort of bypasses the whole problem of what we've seen with pilots being stuck. If you if you train it on specific data, you've made it specific data. So it's learning on specific data, whereas a framework applies itself to a much broader range of issues. So that makes a lot of sense. To push back a little bit, yeah, let's say I'm a CISO in a company and I'm like, Well, I can do this internally, I don't need a company to come in and do this for me.

Why don't I just build these capabilities inside my company? What would you say to them? What are the pitfalls and the things that you've seen that CIS Os are probably missing when they're thinking about this from their own side?

Well, I think generally the pattern with any kind of take and build versus buy using AI is that eighty of the problem is easy, and twenty of the problem is this is really hard. And it turns out with AI, like today with the models, one of the big challenges is that they tend to want to keep you happy. And so they tend to have a high false positive rate. And we've seen a lot of feedback in the market as they've rolled out like LLM scanners is that, you know, yes, they find some really interesting vulnerabilities, but my goodness, there's a lot of noise, uh, and there's a huge volume of noise.

And so that's one of the first things is like, how do you manage that? And like, that takes a lot of you need a lot of analysis to understand how to get the most productivity out of these models and constrain them and build a framework around it that you can actually weed out what's not valid and what is valid. And so there's an architecture you have to build there. So it's it's not a a trivial problem, but it it is a problem to work through, and it's an ongoing problem that you have to do.

The second one is governance and safety is actually a really, really hard problem. Like, if you look at the space today, I think 95% of the players out there are telling the market, you have to have a human in the loop to use these tools. They're saying that because they realize it's really hard. The benefit that we've taken the opposite approach, and we made that like a requirement from day one. When you have a really hard requirement or a really hard problem to solve, there are two things you can do.

One is you can deflect it and say, like, hey, we'll get to this problem at some point. Or the other one is you can say, like, we're actually gonna build something that is able to come deal with this as a fun foundational requirement of how we build this system. Which means that everything you build in the system, in their DNA, has this kind of like tenant of like governance and safety. And so for us, it was really important that when we built XBOW, for example, that XBOW would be a fully autonomous tool that would be given zero information and would require zero humans in the loop.

Very hard problem to go and solve, but it's okay. Like, if we want to win in this space and if what the market really needs, and if you want to go and unblock all the really interesting use cases, full autonomy is really the only way you're going to do that. Otherwise, you get back to the foundational problem in security, which is there just aren't enough skilled human beings on the planet to cope with the volume of work that needs to be done.

That was, you know, it was like 100,000 to one five years ago, and it's insane now because, like, everyone. So, like, that's the the, you know, so we call this like the build versus buy dilemma for, you know, lots of companies that we've spoken to that have taken the hey, we're gonna build it ourselves. It's been a great early journey. And then they're like, man, there are some edge cases here, right? Okay, how do we deal with this?

And it's interesting to get on a call with them and they talk through it through the edge cases that they've seen. And we're like, oh yeah, we remember that one, remember how we dealt with this thing, and everyone's just like, wow, okay, that's really cool. Uh, how you approach that problem? So, like, so that's the challenge is like the last mile of safety, use it in a regulated enterprise environment, uh, is a really hard problem, uh, to go and solve.

So, uh, as we're winding down to the end of the conversation, there are again too many questions I want to ask, but let's let's focus on something practical for leaders that need to implement right now. What is the right time? And I'm pretty sure you're going to say right now, but let's say they they're at the start of their transformation, digital transformation. Let's look at the person who's just starting at their company. Is now the time?

Do you first implement a few agentic and new software digitization within your company, or do you front load this and just, uh, from the start, have something like this in place before you roll out? And what are those first steps then that they need to do before they they contact an expert?

Yeah, that's a that's a great question. I mean, I think the the first thing is to really understand how is someone gonna come up. So one of the areas is like your web apps, which are public facing. So these are apps that are sitting on the internet that people have access to. So I think the first question that you would ask yourself is for these applications that are sitting out on the internet. How comfortable do I feel that if someone was able to get hold of a model and start spending some time looking at these things using these techniques, how secure are we?

And I think it becomes most stressful when we get one of these zero days, one of these like supply chain CVEs, where, like, you know, like, so they they talk about a term like time to exploit, right? That time to exploit, like, you know, if if I go back and look at the data, like the time to exploit, like going back back to 2020 was about 1.3 years, right? So that means like, from the time that you knew you knew there was a vulnerability in application to the time that, like, someone was able to exploit it, there's something with it was quite long.

It's now down to like one day, and they're predicting that by the end of 2027, it'll be down to one minute. So with that kind of compression in time, really, the next question is to take a look at all of your public facing assets and go well, which ones are actually reaching into something in our system that might end up in a bad result? Some of these might be just like simple, like marking pages where, like, you get in and you, you, you kind of silently, you can't really do anything interesting.

Maybe you can modify the website and and do some trolling, but that's it, right? Other ones are like, this can access our customer data, this can access our billing system, this can access our internal software development system, so you can do malware insertions, things like that. So I think that's really the first thing to do is like, ask yourself that question, like, you know, what does my threat surface look like and what do I care about?

And I think once you understand that, then the question is like, well, how can I do a very quick scan of these applications that I'm concerned about and understand what my posture looks like? And so there there'sa marketing term that's out there right now, like, I think Anthropic have done a wonderful job, which is like, you know, are you mythos ready, right? But really, the question is like, are you ready for an AI powered attack? And this is where, like, working with, like, one of these autonomous offensive security tools, you can just give it a list of the applications and ask it to go and do some surveillance.

And it can be just as simple as doing like a no auth check. So they they don't have any credentials to access anything, but just going and doing a perimeter scan is super valuable to understand. Like, I have a house, all the doors and windows are locked. Can someone still get in? It's exactly so that I think is like the first thing. And it's actually a conversation that we're seeing a lot of these security teams being asked by their board today, on the back of all of the stories and communication and and like noise that's been made around, like, you know, the mythos model.

So that's the first thing to look at. Once you've done that step and you understand what the posture looks like, then you can start thinking about, like, well, what's the next step I want to do here? Do I want to continue in this space? Am I concerned about, like, internal applications? Do I want to give more context and actually have to do a deeper look because actually some of these applications are built with open source software that's readily available on the internet, which means someone could use that information to come and attack and and give more context.

So, like, that's like, that's a much broader strategy. But the simplest question to ask yourself is someone points an LLM at my site with a simple framework, and they don't care about governance and safety, what damage could you do? So I've been spending the last like eight weeks talking to customers about exactly this, and it's been super interesting to kind of hear everyone kind of saying, yeah, that is exactly a question that we're trying to answer, and we'd love love to partner with you, uh, on working through that.

I'm going to wrap us up and just highlight some of the standout insights for me today. It's number one, we've heard it in the past, and we started with speed, and you just bringing it back to 2020. It was, uh, 1.3 years to get exploited down to one day and just accelerating at tremendous speed. This really is about speed, but also volume. So when we look at speed, you need to have something that human that that's moving at the same speed on your security side, on your checking for exploitable vulnerabilities.

You have to match fire with fire. If your hackers have automated and scaled machine speed attacks, you have to attack with the same speed, or at least check with the same speed, and your security needs to be at the same speed. And then it comes to just triaging. You might be able to implement something that gives you all of the vulnerabilities you might have in your system. But then you're back to to the same problem we had in the past.

Now you're just sitting with the same system that's overloaded with too much noise. So you have to be able to triage and ensure you focus on the right vulnerabilities first, and then have something that at the same speed can solve for this problem. And having a human in the loop, from your point of view, is just not the way to go because, again, that will create the bottleneck. So creating a security system that sort of takes the human out of the loop in a safe, governed way and having it all auditable because at the end of the day, if something go goes wrong, you need to actually figure out where it went wrong.

This is really the way to go, and from the the speed things are happening at, it needs to happen today. Um, so you companies and enterprises are welcome to try it inside, but I guess, like in most cases, when it comes to AI, companies like to focus on their own bottom line and what they are trying to solve for as a company. Ensuring that you've got a partner on hand that, uh, focused the entire every second of the day on on this specific problem probably makes most sense.

This has been a great conversation. I could probably ask ten more questions, but thanks for your time, Niro.

Thank you, Mario. Yeah, really appreciate the conversation. A lot of fun.

Wrapping up today's episode, I think there are three key takeaways from our conversation with Niro. First, as AI accelerates how fast code gets written, security has to find and validate vulnerabilities it introduces at the same speed. Second, distinguishing real exploitable risk from noise matters as much as detection itself, chasing false positives wastes time security teams don't have. And finally, scaling automated defense safety means building governance into the system from the start, not adding a human checkpoint after the fact.

The use of AI products or services emerge gives you access to trusted content and real conversations. Learn how leading AI brands like Nvidia and Google Cloud work with Emerj to reach Fortune 500 AI buyers. Download our media kit at emerge dot com slash a d one. That's m e r j dot com slash a d and the number one. For further executive level analysis and to join our network of leaders delivering workflow impact with AI, visit emerge dot com.

On behalf of the team at Emerj, we'll see you on the next episode.