EPISODE 1959

[INTRODUCTION]

[0:00:00] ANNOUNCER: In the world of software security, there was historically a comfortable lag between the moment a vulnerability became public and the moment attackers could exploit it. This lag was often measured in months, but AI models can now read a vulnerability report and generate a working exploit almost instantly. They can scan the entire Internet for exposed secrets at a scale no human team could match, and surface complex flaws that traditional tools missed for years. However, the same capabilities are just as available to defenders, and there is a case to be made that defenders hold the stronger hand. Alon Schindel is the VP of AI and Threat Research at Wiz, which is a cloud security platform acquired by Google in 2026. In this episode, Alon joins Gregor Vand to discuss how AI has compressed the time from disclosure to exploit, the prospects for defenders to stay ahead, how Wiz approaches scanning and remediation, the growing strain on open-source maintainers, and more.

Gregor Vand is a CTO and founder, currently working at the intersection of communication, security, and AI, and is based in Singapore. His latest venture, Wyntk.ai, reimagines what email can be in the AI era. For more on Gregor, find him at van.hk, or on LinkedIn.

[INTERVIEW]

[0:01:35] GV: Hello, and welcome to Software Engineering Daily. My guest today is Alon Schindel. Welcome, Alon.

[0:01:41] AS: Hi, it's great to be here. Thank you for having me.

[0:01:44] GV: Yeah, absolutely. You are at Wiz, and this is, I think, the second time we've now had someone from Wiz on, which is exciting. I spoke to one of your colleagues, Rami McCarthy, probably two years ago at this point, which is crazy to think it was that long ago. Yeah, great to have you here today, Alon, and we're going to be talking all things AI threats in general, so both the threats themselves that come from AI being possible now and detection that's also then possible and all these things, which is super exciting. As we like to do, just curious, how did you get into security generally and how did you find your way to Wiz, the company?

[0:02:24] AS: For me, I think I was always curious about security. Starting building websites when I was on, I think, third or fourth grade, just enjoy the creating. I mean, ever since that I was always fascinated by hackers and how can my website be hacked. I think, I naturally was attracted to this domain. Whenever I had, when it was in school, or after that, in the professional career, whenever I had the opportunity to choose a cybersecurity position, I went there, or class, I went there. Yeah, so it's a journey that has started a long time ago, more than 20 years ago. I was really lucky to walk and meet other people in this domain. Some of them are industry leaders who guided me and mentored me, helped me to get to this point.

One of them is actually one of the first engineers at Wiz, who is one of my childhood friends. We went to the same kindergarten, we know each other since we were five. He joined Wiz, he knew the founders, joined Wiz on the first day, one of the first employees. A few months after they started, and they wanted to expand, he texted me, asked me what am I doing now, and if I'm available to talk about a new opportunity. I said, "Yeah, it sounds interesting." That's the story of how I got to Wiz there, around five and a half years ago. I'm always grateful for this opportunity. Maybe the lesson is that it's good to keep these relationships close, even when they start so early.

[0:04:03] GV: Yeah. Cyber security in kindergarten. That's definitely one, too. That's a new one. I guess, that means, because Wiz, I can't quite remember how old Wiz is a company, but that means you've been there since very early on at Wiz.

[0:04:17] AS: Yeah. Wiz now is six. Yeah, started six years ago. It feels shorter. It's been a very fast journey. I think we saw - Yeah. I mean, we feel like we saw almost everything since Log4J in 2021, when, I mean, it was one of the largest vulnerabilities that we saw. Now, we are seeing the supply chain attacks, this wave of Shai-Hulud and other similar data worms that we're seeing. But of course, in everything with AI and how AI impact security, it feels like we're starting all over again. The challenge is real. There are new challenges. The pace is faster than ever. Even though we are six, I think it feels like we started just last year, because everything changes so fast.

[0:05:07] GV: Yeah, absolutely. I think, yeah, on the things change fast point, that's where we want to talk about things today, all things AI, and how has that affected the security landscape and then how should people be then thinking about their security setup now that AI can be a part of that. It's something that we've touched on, especially we have an SED monthly episode, me and one of the other hosts talk about things. We're often noodling on this idea like, okay, how did AI really change the security landscape? It's great to have you to actually be able to answer some of those questions properly today.

Yeah. I mean, I think just opening with more of a stat, I guess, which was that in theory, the Firefox team had said that they had fixed more security bugs in April 2026 than in the entire previous year. That was because of Mythos, the Anthropic model that had been released back then. We went offline for a little while, but it has, to our understanding, come back online about six days before we recorded. If it's offline again, by the time this comes out, sorry to the audience, but it is online as we were talking today. Yeah, this model Mythos and there's a cool model Fable, which we can always get on to as well. Yeah, just talk to us about that. How has that affected how we should be, I guess, looking at just - let's just start with landscape total. What does that mean?

[0:06:40] AS: I think we'll get into Mythos and vulnerability research with AI, but I think it's always important to remember that there are two different perspectives, how you can use AI for security and also securing AI and how AI changes the threat lens, just by opening maybe new attack surfaces for the attacker. Whenever we talk about the impact of AI on security, we have to talk about both of these different aspects. I think we see today, I mean, I started with that, we see that there is a new reality. I'm saying that it's like having new rules of physics today, because everything that we knew before is changing.

For example, we see how faster you can find vulnerabilities. That's one example. We'll deep dive into that later. Mythos is only one point and it was maybe a loud wake up call for the industry. But the trend of AI models that are becoming good in vulnerability research is something that we have started seeing even last year in December. In Wiz, we launched AI vulnerability competition. We invited hackers to find vulnerabilities in software, in cloud software, AI software. Now, most of the teams that finished in the highest positions in this competition use AI to find the vulnerabilities. We are talking about around four months, five months before Mythos was announced. We keep saying that the other models like Opus 4.6, Gemini, OpenAI, the GPT-5.5, they all show great capabilities in finding vulnerabilities, and in addition to other great capabilities in just software engineering and building software.

I think this is one of the things that is changing now. We're talking about a reality that hacking is democratized and it is becoming easy for everyone to find vulnerabilities. It's even easier to do web hacking. I started by talking about how I used to build a website, how it inspired me to get into cybersecurity. I think today, if I had, when I was 10, if I had access to a model, like even, again, Opus, not even Mythos, I think it was a great tool to start scanning the Internet and find just exposed data out there, or lambda functions that whenever you trigger them, they just get you secrets back. The barrier to get into cybersecurity is becoming lower and lower. I mean, I think that you still need basic skills, understanding what you are seeing. But we see that these models can help us.

In Wiz, we saw it was one of the early users of AI for us was for what we call the red agent. It was the AI automated attacker. It was amazing to see how fast we were able to build this feature and how fast we were able to enable it to thousands of customers. Probably one of the features that we saw the fastest adoption speed for, just because they are so effective. I mean, you scan the webpage, you scan the HTML file, JavaScript file, and AI is doing amazing work in analyzing it, thinking like a hacker and finding the exposures here.

When I say that hacking has been democratized, that's what I mean, that it's becoming easier to hack website. It's also becoming, I mean, the job, this work is now scalable, because you don't need, even if you had amazing - I mean, we saw hackers before, we saw EPTs nation state that are doing great work, but it required time, effort, skills. Now, even a single person just from home can run these large operations, scan the Internet, find these exposures. I think that for us as an industry, the cybersecurity industry on the blue side, there are also great opportunities there. Everything is changing. It doesn't necessarily mean that things will be worse in the long term.

[0:10:59] GV: Yeah. There was a great article you put out, which talks about a framework around looking for vulnerabilities and then defending against. I'm going to reference that throughout our chat today. There was something you mentioned there, zerodayclock.com, which is for those that don't know, yeah, if you pull that up, it's a very interesting downward trending chart through the years of how fast it has been to basically exploit from a found exploitation. If I just look at this, 2021 was when that was seen as like, wow, it took one year to go from something has been discovered to the time it was breached. Then we fast forward to 2025 and it's already dropped to one month. Now in 2026, it's one week, or rather, sorry, and it's actually, we also reached in 2026 one day. They at least are projecting one hour by 2027. Even maybe one minute by 2027. I think that really frames it super interestingly. We've just in what, the space of five years gone from, oh, we've got a year to potentially patch this to you're lucky if you've got a day now. Does that sound right to you?

[0:12:11] AS: Yeah, definitely. I mean, we see it as part of my work here. I also own the response to vulnerabilities. It's not only finding them, it's also responding to them. We see how in the last year, we were just busy with back-to-back response to new vulnerabilities. We see more vulnerabilities and we see that, yeah, we need to respond to them faster, because you see the exploits faster. I remember days, even if I look back, I think one of the - after I joined Wiz, one of the first vulnerabilities that was released was in a critical Apache HTTP server vulnerability. I think it too, the vulnerability was published, I think it took around two or three days until we saw the exploit.

Now, maybe one of the recent examples is the vulnerability in MongoDB. Just from the report of the vulnerability that was public, you could have just send it to Claude and get the full exploit back. That's what we see. In the AI thread, the readiness framework that you mentioned, we are trying to help organizations and security teams and also software engineering teams to rethink their response framework. I think that part of that is really, how do you reduce exposure? The reason that this spot, I mean, it was always important not to have exposed resources out there. Now if you have resources that are just out there, and everyone can find them and hack them very fast.

[0:13:44] GV: This is a really interesting piece, because it crosses into ASM, which is attack surface management, which is actually something in a few moons ago, I worked on products in that area. I'm really curious, what's your then definition of what has changed, because you can apply AI to that now?

[0:14:08] AS: The way we apply AI in this space is by creating the AI attacker. Today, we see how these capabilities of attackers and defenders converge. I mean, in ways, we scan your environment from the inside. We know which resources are the important ones, where do we have sensitive data? Where are the crown jewels of your organization? We use this data to create more smarter scans and prioritize the resources according to their sensitivity, according to their criticality to your system. When we have these hints about what's actually is on this resource, we can trigger this AI scan. We scan the page from the outside like an attacker, but we can give it some hints about what's in it. In this way, we create very effective scanning mechanism.

We actually found thousands of vulnerabilities and critical exposures just out there. If it wasn't us that founded, it would have been an attacker. All this data was just out there. We scan it, we analyze the HTML file, the JavaScript file, try to find what is exposed, whether we can find, we see that we sometimes find tokens that are maybe GitHub PAT tokens, other tokens that are just accidentally embedded in these web pages. Everyone can read them, use them to log in to the organization system, and then just start their hacking campaign there.

I mean, we see different, of course, hackers, they can try to exfiltrate data, they can try to maybe start a supply chain. If it's a GitHub PAT token you can maybe add some malicious script to the product, or to the package that this company creates and infect the downstream customers. Of course, many other opportunities for attacks there. The bottom line is that we are trying to use AI leverage the same way that attackers will do. But the reason that I'm optimistic is that as attackers, we have more context. Context is the key for AI.

In cybersecurity, context has been the key and the king. Even five years ago, I think that was the significant part of how we built with to use context to prioritize. Now with AI, it's becoming even more critical, because you need to - the models, they can't work without context. If you have better context, the results will be better. When we as defenders, we know what do we have inside our system in our environment, we know what's important. Attackers, they can brute force, they can just spray and try to find exposures, but they don't know what's really important, until they actually get in. I think that's an area where we as defenders have the advantage. This is part of the reason that in the long term, I'm optimistic, because attackers, I mean, everyone, I think that we'll see that we as defenders, I mean, let's assume we have access to the same models, we can talk about whether it's going to be true or not. But let's assume that we have access to the same models, the defenders have better context. This is why I believe that we can defend and have the advantage on the attackers.

[0:17:34] GV: Yeah, that's super interesting. I hadn't maybe thought of it like that, where pre-AI, okay, the context is the developer who can say, "Well, I know how this was put together. I know where the skeletons lie a little bit and why, for example, like, oh, we had to brush this bit out. That's the one that I'm not super confident on having the same degree of the security engineer wasn't able to look at that for quite as long as this other bit over here, which got way more stakeholders looking at basically." I think that's super interesting, where that can all then be fed into, and even I guess GitHub histories, for example, where that conversation that happened around that pull request, for example, where someone says, "Ooh, okay. Well, I guess, we're going to push this out, but I'm not super happy about this," like that. That can be brought into the defend context, right?

[0:18:22] AS: Mm-hmm.

[0:18:23] GV: Yeah, exactly. Before we can move on to how AI has then helped more on the actual patching of all these discoveries, something that maybe it's a tricky topic sometimes, which is just responsible disclosure. When things are found, companies, there are various laws in different countries around how long you in theory have to then declare these, etc. If you're finding 3,000 in a week, how do you guys look at that?

[0:18:52] AS: For us, it's an important principle to comply with the different disclosure rules by different platforms. I mean, when I talk about 1,000 findings, so it's part of what you see in the Wiz product. When there is something that is - I mean, we believe that is, say, even super critical and we see that there might be an exposure that - I mean, our system flags is super critical. We also try to reach out either through the security email, or I mean, just to contact the company, yeah, the same way that the other reports are being submitted.

In other cases, when it's a custom, we can just reach out to the security team directly. I think that there's also maybe a new problem. When we talk about the scale of finding that for maybe open-source projects, or some other small maintainers, that they have a problem, that they are getting, I mean, maybe dozens, hundreds of reports from different companies every week. We just saw an example last week for one, an open-source project that disclosed the vulnerability and they had, I think, 15 different companies, or researchers who reported this issue. The reason is that everyone scans these open-source projects with AI, but it creates a problem with triage. How do you triage issues when you have so many.

We saw some other maintainers that said that they won't respond to reports that were AI generated reports, since you also see some AI slot over there. I mean, that's another problem that AI creates, that you have to review more and more data. For us, we are lucky to have a great team and enough people to actually make sure that reports go to their right place. We have, of course, the product where most of these issues are reported and security teams, they have the processes to respond to these issues. It's indeed, I think that's another area where the industry is changing now. how do you report issues to maintainers? How can maintainers - I think it is a great problem, because we have some people that, I mean, with their hobby on their free time, they do something great for everyone's good.

Now they are being - sometimes even shamed from not responding fast enough, but they don't have the resources. It's just their life. This is why it's good to say, like you mentioned before, the Mozilla, the Firefox project. I think one of the important initiatives now is how can the frontier labs work with, or scan these critical open-source projects that are the backbone of everything, of the Internet, of everything we know, and how can we help them find all these vulnerabilities before the attackers do. I know that both Google, OpenAI, Anthropic, they all invest efforts there. I think it's something that we must do now before these capabilities propagate to the red site.

[0:21:57] GV: Yeah, definitely. Yeah, as you call out in open source, it's just a whole other role game as well. I think looking at how, if we go into a bit more of the framework you mentioned in your article, and then, actually, then how to accelerate the actual patching, and the zero-day response, yeah, which again, going back to zerodayclock.com, that's no more than one day now. If we hit one day in 2026, it means we might be already down to 20 hours, because the next marker is one hour. We're probably down below 24 hours at this point.

As it probably sounds, this needs to start involving a lot more continuous automated remediation, which I think was always the Holy Grail, right? No human in the loop and something's just declared and suddenly, you've got an agent to go and deal with it. I think Wiz does have - you talked about the red agent, which is AI-powered attacking, if you like. Then we've got the green agent, which is on the response side. Could you describe how does that all work, I guess?

[0:23:10] AS: I think it's part. I mean, in order to get to full automation, it's kind of a circle where you find an exposure and you need to analyze it and remediate it automatically. Honestly, I mean, it's not easy. I don't think that anyone has the perfect solution. Today, and of course, I'm sure that the listeners, they're working on some systems that have been there for maybe years and they have their legacy code. It's not easy. It's important to say, "No, I don't want to make everyone feel bad, because they think that there's a perfect solution and they don't apply it."

The way that we say it is first, yeah, you have to continuously scan and maybe the first layer of scans is very wider and shallow scans, like the one that I mentioned with the red agent that you keep scanning your attack surface, trying to understand what's exposed. When I talk about attack surface, so it's not only your web assets, you also have to scan your GitHub repos. We saw all these recent supply chain attacks, your CI/CD pipelines. Scanning every resource that you have that can be potentially hacked, scan it continuously with AI, try to find these exposures before the attackers do.

The next step after that is trying to understand the potential risk. In order to solve that, you can either reduce exposure. I mentioned it before, I think that's a very important part. Reducing exposure is becoming critical today, because you have - And that's what we usually see. I think in many cases, the problem is not only the vulnerability, the problem is a resource that shouldn't have been exposed, or shouldn't have been public. Just trying to reduce your work by reducing exposure, that's the first step. If you have a resource that indeed has a vulnerability in it, a vulnerability that can be exploited, maybe you have a misconfiguration on this resource, maybe you have a code vulnerability on your side, more on the upside side. Yeah, you have to start planning your mediation. This is where the green agent work is starting, trying to understand first, where this issue is coming from, finding the root cause.

That's another part that is usually overlooked, because finding where is the - I mean, just finding an exposure vulnerability out there and connecting it to the owner in your organization, connecting it to the file, to your code file that it is coming from is also difficult. It used to be something that was difficult. It's still not easy, but AI can also help with that if AI has both access to your exposure data and to your code repo. You can do this, what we call the cloud to code, and find where is the source of this issue. Then you have to start and plan your remediation steps.

Again, AI is not only good in hacking. It's great, of course, in building software, understanding software. This is where we are trying, we are building this agent that finds the issue and then plans the remediation, or also sometimes offers different remediation plans. Another interesting progress, there was that, we can add some memory. You can just add instructions to these agents. If you prefer always patching, that's one thing. I mean, you can ask it to always prioritize patching, or you can ask it to prioritize reducing exposure by changing to your terraform files. Maybe focus on everything that is not the code itself.

Still very, it's not easy thing to do. I think there's still work for the industry to understand how you can do automated patching. Because after you patch, you have to test it. Part of this, I think the next step there will be how do you automatically test the new code? How do you make sure that this change doesn't have impact on other parts of your system? This automatic workflow, you can see that there are some cases where it can work well, but there's still work to do. Part of it is sometimes even changing the architecture, your architecture that will be easier, so using, for example, secure images is one solution, where you can help organizations close this end-to-end loop faster with better architecture.

[0:27:27] GV: Yeah, as you just touched on there, these hardened images, or hardened containers, depending on what people call them. Yeah, we've had a couple of episodes on that, either the drawback there, I think, or the perceived drawback is just having to, as a developer, having to accept some constraints on your tool chain, or make special changes to these containers. I guess, that's just something that developer teams just have to accept a trade off on if they're willing, if they're wanting to actually make their whole supply chain more secure for this purpose.

[0:28:01] AS: Yeah. I think this changing in supply chain, I mean, another change that we are seeing now is even assessing the potential risk from different libraries and packages that are out there. I mean, something that was discussed in the past as well, where some libraries and some packages are not maintained well. Again, we don't judge the maintainers. I think that they have a great challenger. That's another thing that we see in our research here. We also find, we try to scan these public repos, try to scan CI/CD pipelines and GitHub actions. We see that they are all - and we're working with these maintainers. As I mentioned, we do it responsibly. There are many projects that have exposures. If this project is very popular, it is used by many organizations, it has an exposure and it doesn't have good security hygiene, it is something that is a ticking bomb. You can see this package as a ticking bomb.

I think that another part of the exposure reduction processes that we see, we're not only talking about these public resources, it's also about vetting your open-source code in using more secure S bomb. I think that's another part that that when I talk about shifting left and changes in the architecture, so it's not only security images, it's also the securing the S bomb from the beginning and making better, or the more secure choices. Again, it's not going to be easy. I don't think that any software developer would like to stop using popular library. It's another change that we're seeing.

By the way, one of the reasons that we are seeing maybe more insecure use of packages is also AI. I mean, if you write your code with a coding agent, in many cases, you don't even know what's inside it. You just use all these dependencies, I mean, that were added by the coding agent. You don't really know what you have inside your code. Still, this ability is imported and also making the right choices. I hope that coding agents will also understand and that will be part of what we see from them, prioritizing and the most secure architecture and more secure S bomb for your environment.

[0:30:28] GV: Yeah. Getting into, I guess, actual code analysis, we haven't touched on that in detail yet. I think this is where things do get super interesting, because there have been tools around for a long time, effectively static analysis tools known as SAST in the industry, that basically, yeah, I would look at the code and say, "Oh, this is a known pattern for why this is going to be a problem." My understanding is that now, if we look at what frontier AI models can find, we're talking things like complex logic flaws. I think what's I was going to describe is IDOR, so insecure direct object reference, chain vulnerabilities, and then just a general insecure application flows.

I think, especially those first two are interesting, like complex logic flaws and then IDOR, which I have no idea what it is. I think we should get into that. Could you just talk us like, what are these things that AI models are finding that was quite hard to find before?

[0:31:28] AS: That's an area where we actually see this great deep in capabilities of understanding code and understanding what are these, yeah. I mean, some issues that I really think that we didn't have any technology that could have, yeah, that could have found these issues before. SAST, it's not a new acronym. These products have been around for years. We also, we've built one internally in Wiz. The goal of theirs is finding the vulnerabilities in code, more on the upsec level, on the application level. Sometimes it can be even - maybe a simple example that people know is a SQL injection, just to see if you have insecure processing of input from your users, if it can maybe lead to issue like SQL injection. I think that the reason that it was a real scientific academic problem is how do I understand languages and you needed - you saw that most of the companies that led the efforts there, the work was based on language processing. Even trying to understand code flows, building a graph flow, CFG, understanding the flow of your code. I mean, from technical perspective, it was something that was extremely difficult to do.

Now, AI models, LLMs, they understand text well, and code is also text with structure, with rules, and all that. We see, I think, yeah, since December, a great leap in capabilities of AI models in understanding code well, and this is why we see that they can be easily used for coding now, and also to find these type of vulnerabilities. When we talk about finding vulnerabilities, I mean, they're not the same. There are different classes of vulnerabilities. We have memory vulnerabilities, and that's one type of them trying to find where you have memory leaks, or memory issues that you can exploit and inject your code into the memory of the process. Some issues are more on the upsec side.

Even for us here in Wiz, we see them as different efforts. We have one team working on creating a great, more quality, very deep vulnerability engine that focuses on the memory vulnerabilities. Another agent that is more the AI SAST, that is actually, that will be part of the product. Over there, it's really trying to find these vulnerabilities that are in code, SQL injection like IDOR, the ones that we mentioned before, that are more about whether you can actually understand the code and understand - Doing the code review that we know, but more from a security perspective. The reason that we have a great opportunity now is that AI can actually understand the code. Still, it's not easy.

I mean, you can think about systems. I think I can share some of the challenges that we have. You have organizations that work with many different repositories, and you have to start and find all the references from these different repositories. That's one challenge, because you need AI in the end. The LLM, it has to get the context, the full context, understand the whole system. If you have now, and we see it. We see that we have - I mean, we see organizations with hundreds of different repos, and that the projects are scattered across these different environments, so you have to find all the - find this trail and understand it. We also see other products that are just very large. You have to start writing it down. The way that we are doing it is separating different tasks to different agents. We are trying to model the process that we are doing internally to find one business, processes that we use as humans to find vulnerabilities the old, classic manual way, and try to, for example, first, find all these different things and collect data about where we see references to this issue, then really try to hack it, then test it, validate it, even a judge. Sometimes we even use different models. It's actually a nice technique that we see, that different models, they have - so Claude has different advantages, Gemini has different advantages, GPT has different advantages. We're trying to use actually different models.

When we see that a model is maybe stuck, that doesn't find the solution, call the other model and try to do that for help, like we have different researchers, who excel in different domains. We are trying to build all that. In the end, to build a system that will be able to find these vulnerabilities. Also, to make sure, I think, the problem is that also to reduce false positive and understand the real criticality of the issue. One of the problems that we saw with LLMs were that whenever they find something, they usually flag it as super critical. It's not always - when they say something is good, it's not always critical, though, that's part of a training issue. We also need to assess the criticality of the vulnerability and make sure that we don't create false alerts.

Maybe just one last anecdote there, we say that even models, the other frontier models that are not Mythos or Fable, not from this class of very large - Mythos in the end, it's a model. I mean, it's great, but it's the largest - It's a very large model, if we talk about the number of parameters, like complete, different order of magnitude from all the others. We see that this process of building a good harness with these different agents that can work with each other and work on different tasks as part of this flow, you can get to great, like almost similar results to what you see with Mythos.

It's also something that is important to remember that whenever we talk about finding vulnerabilities, or how good the model is in this task, it's not only about the model, it's also the harness. Good harnesses and capabilities of the frontier models today that are not from the same class of Mythos and Fable are also great in these tasks.

[0:37:39] GV: Yeah. One thing just briefly on that as well is just the reproducibility of things that have been found, like how - I guess, if I think more of the SAST model, it's like, well, this thing has been found is very clear. Here's the steps, recreate it, for example. I get the impression that the AI found vulnerabilities, it can tell you what was found and what the impact might be, but actually then, for someone to reproduce that, I think, isn't a little bit more challenging?

[0:38:11] AS: Yeah, it is. I was on a call before we started recording the podcast. That was one of the issues that we discussed, that part of building a good AI system today, like every AI system is how do you create your evolves, your valuations and benchmarks and to understand what you're doing well. Sometimes what happens when you make a change to your system, whether you can actually reproduce the same processes that you saw before. First, I think that we have to remember that LLMs, there is of course some random factor there, since they are based on probabilistic processes. But our goal is to try and make them as deterministic as possible.

I think the honest answer is that we're not there yet. We see that what we're trying to build when I talked about harnesses before is really, to make sure that regardless of the probabilistic nature of the LLM. We want to make sure that it actually reproduces the - and run it deterministically. Of course, when you are a vendor that creates products, it's hard to sell something that might give different answers. Honestly, I see more tolerance, I guess, to this randomality that is out there, that if you look back four years, it was something that no one accepted. I think now, people are getting used to AI systems that give you different answers. There is maybe slightly more tolerance than what we used to see before in cybersecurity.

In the end, in cybersecurity, yeah, you can have these different results for different runs. Part of what we're doing with our engines are trying to reproduce the issue multiple times. We have to remember that some vulnerabilities also have this probabilistic nature of memory vulnerabilities, there are vulnerabilities that just, yeah, that mean vulnerability can - you can run the export, or just one out of 10 on average, just one out of 10 runs will succeed. You have two different mechanisms here that are probabilistic and probabilistic, and that makes it even harder to run. Yeah, it's part of the challenges that we have today. It's part of the work. I think, also in the frontier labs, they invest great efforts in making the models more deterministic.

[0:40:25] GV: Yeah. I think this is it. I mean, it goes outside security, but just keeping it within security, I think the unlock here is people are still - they're more willing to accept the less deterministic aspect on the basis that they'll still get quite a lot of things that would just never have been found if this had to be a completely deterministic system. That's what you get. You get the, yes, it's a larger pool of things to sift through, but equally some of those literally have been found to be some crazily problematic things that SAST haven't picked up for many years, for example. That makes sense why tolerance is a little bit higher, especially at the moment, which is super interesting.

As we cruise to the, I guess, to the end of the episode, I mean, I really like the framing, again, from your article, which is a very positive framing, which is that AI is available to attackers as much as it is on the defense side, but the defense side is looking better, basically. Yeah. I mean, again, if I look at the zero-day clock, I really encourage anyone listening to go check it out. First of all, just to go back and what I said about, we are in 2026, apparently, we are actually down to two hours on the time to exploit. That's just the fact. We're not at one yet, so that's why I hadn't been ticked off. I look at the chart again, it's like, "Oh, wow. We're down to two hours." It's not only a day, but it's down to two hours.

The other thing which is interesting is that the exploit rate, so this is percentage of all published CVEs that are confirmed exploited in the wild, versus CVE volume has actually dropped, which backs up, I think your positive thesis there, right, where actually, now in 2026, it's down to the exploit rate is down to 0.25%. That's just to give some relative terms, that's down from 2.2% in 2021. Yeah, that's really interesting. That does suggest that AI being available is actually improving things.

[0:42:29] AS: Yeah. Maybe by the time the episode is over, it will be - the exploit time will be shorter. I think that we see - I mean, maybe another fact to remember about vulnerability is finding a vulnerability doesn't necessarily mean that it's easy to exploit it, or find the exploit. We see that it's easy - By the way, most of the vulnerabilities that we find with AI, we can't really exploit. I think, maybe it's something that we'll see that models can do. I mean, when we see better models, they will be able to do it better. But it doesn't necessarily mean - I mean, finding vulnerability doesn't necessarily mean that you can actually do something - attackers can do something bad about it.

Overall, I mean, I think that my expectation is to see, yeah, in the short term, more and more vulnerabilities that are being discovered, but most of them won't be exploitable. I think that we'll get to a point. I mean, if we talk about this, there'll be a curve at some point where I think that most of the open-source software will be scanned. As long as we don't see another huge leap of advancement on the LLM side and on the model side, most of the issues will be just fixed. By the way, same for us - No, I'm not just generally speaking of things. Thinking also for how next year we look for security teams. I think they will have - we will have hard work patching our systems, fixing the vulnerabilities. There will be many CVEs that will need to patch. At some point, I think that we'll start seeing the number of vulnerabilities that are being part decreasing, just because - I mean, because we will find most of these issues, and we'll also make the changes to our architecture in order to reduce the likelihood of exploitation.

Part of the changes that we're seeing now, I think some people call the vulnerability apocalypse. There are other names they give this year, but in my opinion, if you're looking a year or two from now, after we are past that, and I think that it's also something that is in our hands. I mean, if we do great work now as a community and we work together to fix these issues and try to find them before the attackers do, we can make our life easier and in the long term, create a more secure world, where you have fast attackers, but also faster defenders.

[0:45:04] GV: Yup, absolutely. Well, yeah, I think you definitely opened my eyes a bit just to the whys here of why actually having AI and being on the defense side, why we're actually in a good position, which is great, because I think a lot of the news out there, like it's very doomsday, oh, this is going to be, yeah, as you say, vuln apocalypse. Yeah. No, I think that's been super helpful and all this tips that you've given listeners today in terms of how to use AI to secure your applications, super helpful. I would also recommend people go to as wiz.io/blog, there's articles there. Anywhere else that people can find you, or anything like that?

[0:45:46] AS: Yeah. On LinkedIn, just search my name on Twitter. Just again, with the same name. I'm there. Yeah, we're trying, I think, as part maybe something more on the first of the load is that I'm trying - I think that we have a great responsibility. I think that there's something very unique about cybersecurity, where creating content is something, or sharing your thoughts, something that can have great influence on others. That was one of my missions in Wiz on for my group to encourage everyone in my team and to support, I mean, creating, writing their blog posts, or writing, sometimes even just infographic, trying to share what we are saying.

We have the privilege to work with great security teams from all over the world, learn, and I shared some of our insights today. Yeah, this distribution channel, whether it's LinkedIn, X, and of course, podcast is the way for us to share our thoughts and we're trying to keep it. We are going to publish another blog post soon on AI and finding vulnerabilities with AI. We keep sharing our thoughts there.

[0:46:57] GV: Amazing. Well, again, thank you, Alon, for coming on today. Great to hear all these things. Learned a lot. Yeah, and we'll be following along, picking up these new discoveries on all the places you just mentioned. Thank you so much for coming on.

[0:47:11] AS: Thank you so much for having me.

[END]