
Resilient Cyber · 2026-06-27 · 25 min
Key moments - from our scoring
Substance score
56 / 100
Five dimensions, 20 points each
Jerry Gamblin, creator of CVE.ICU and Robo Labs, walks through the structural drivers behind the projected 70,000 CVE milestone in 2026 - a 46% jump from February forecasts. The three main forces are AI-assisted vulnerability discovery (up 449%), GitHub's expanded security advisory program (now publishing 1-in-5 CVEs), and a surge in CNA-of-last-resort activity from Vulncheck. While the headline number sounds apocalyptic, Gamblin emphasizes the critical distinction between volume and exploitability: EPSS and KEV data show that actionable, widely-exploited vulnerabilities have remained relatively flat. He frames this as "rain versus flood" - manageable noise versus catastrophic breach conditions. The real problem isn't AI finding new vulns; it's that 25 years of latent software debt is being exposed at scale, mostly in open source projects. Gamblin also discusses how the NVD has become the bottleneck in the ecosystem, arguing that large CNAs (Fortune 500 vendors) should be required to provide quality CVE enrichment data rather than expecting NIST to do it. He recommends defenders use procurement leverage to demand better CVE data as a contract requirement, and notes that international representation on the CVE board (per recent NDAA language) could improve governance. For teams drowning in findings, the answer remains asset inventory - knowing what you actually run so you can filter irrelevant CVEs.
AI-assisted discovery tools and GitHub's expanded CNA program (now publishing 1-in-5 CVEs) are finding latent bugs in existing code at scale, but most are in low-impact software and open-source projects. EPSS and KEV signals confirm that actionable, widely-exploited vulns have remained flat despite the volume spike.
Rain (manageable discovery noise) won't cause you to drown, but flood (actual exploitable vulns overrunning defenses) will. The 2026 surge is rain - high volume but low exploitability - not the apocalypse some headlines suggest.
Build and maintain an accurate asset inventory (CMDB) to filter irrelevant CVEs. For example, if you don't run WordPress, you can ignore 3,000+ Patch Stack CVEs immediately. Then use EPSS and KEV signals to prioritize what matters.
Large vendors and CNAs should provide complete CVE enrichment data (CPE, CVSS, etc.) in their records rather than leaving NIST to "correct their homework." Defenders can use procurement contracts as a forcing function to demand this quality.
No credible signal shows wide AI-accelerated exploitation in the wild. Attackers continue targeting proven OWASP Top 10 flaws and old vulns because tried-and-true methods still work, making a shift unnecessary.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers a handful of genuinely useful data-driven claims - GitHub's outsized share of CVE issuance, the exploitability-stays-flat finding despite raw volume surge, and the procurement-leverage angle for forcing CNA quality. However, the guest spends substantial airtime on well-known fundamentals (CMDB, 'we don't know what's on our networks') and the host's long affirming responses eat into the content clock.
GitHub is now publishing one in five CVEs that are published
NVD was just basically correcting their homework for them. Filling in CPE, filling in CBSs and then presenting good clean data to the public
The 'rain versus flood' framing is a serviceable metaphor for distinguishing raw CVE count from actionable exploitability, and the idea of treating CVE data quality as a procurement lever is a relatively underused angle. But most other content - OWASP top 10 unchanged, attackers use old vulns, know your assets - is standard vulnerability management canon.
if you had a pen tester give you a finding last year in a report and then an AI tool found it this year, you could probably get the time to fix it because the new cool AI tool said that it was there
we need to start see having people see CBE Data, uh, as a product that they're paying for
Gamblin is a credible domain practitioner who built and maintains real open-source tooling (CVE ICU, Rogo Labs), co-authors CVE trend research that gets cited in the community, and has hands-on history in the CVE space at Kenneth Security. He is not a career thought-leader, but he is also not a senior operator who has run a security function at scale, which caps the ceiling.
I used to work for a startup called Kenneth Security and we were in the CVE space
I sit down and we tried to figure out a good way to describe this so people could understand
The episode is anchored by several concrete figures drawn from the guest's own published forecast - 40%+ YoY CVE growth, one-in-five CVEs from GitHub, 164% Mozilla spike, 3,000 PatchStack WordPress CVEs, 14x projected commit increase - which is above average for the genre. Dollar figures and named breach case studies are absent, and some claims (AI exploitation 'coming') remain hand-wavy.
we're just at about over 40% growth year over year
Patch Stack has put out just over 3,000 CVEs. If I don't run WordPress anywhere on my network there, those are 3,000 CVEs I don't have to even think about
The host shows some craft - he correctly anticipates the 'forcing function' follow-up and does pull apart the three structural drivers rather than accepting a lumped answer. But his questions are frequently long and leading, he rarely challenges a claim, and the episode has a fan-interview tone ('you're one of my go-to resources') that forecloses productive tension.
help us pull those apart a little bit because they're very different kind of forces from different ent, but they all get kind of lumped together in one big scary number
my follow up question to you when you said like you know, the, the responsibility or burdens falling to those who it should have been with to begin with, the cnas was going to be like what forcing function is there?
Computed from the transcript - who did the talking, and the words that came up most.
CVEs are on pace to hit nearly 70,000 in 2026, but Jerry Gamblin explains why the actual exploitable risk is staying surprisingly flat. Description Jerry Gamblin runs RogoLabs and built CVE.ICU, and he co-authored the FIRST mid-year vulnerability forecast that just put 2026 on pace for nearly 70,000 CVEs. He joins Resilient Cyber to separate the scary headline number from what actually matters for defenders. We get into why GitHub now publishes one in five CVEs, the rain versus flood distinction that explains why exploitable risk is flat even as raw volume explodes, what the NVD collapse means now that the CNAs have to step up, and how teams should really be triaging with EPSS and the CISA KEV catalog. Key takeaways CVEs are on pace for nearly 70,000 in 2026, up more than 40 percent year over year. Much of the surge traces back to a single source, with GitHub now publishing one in five CVEs after scaling up its advisory team. The three drivers behind the surge are very different forces. AI-assisted discovery that nobody can definitively flag, a 449 percent jump in GitHub security advisories, and VulnCheck acting as a CNA of last resort all get lumped into one scary number.
Transcribed and scored by The B2B Podcast Index.
Speaker A: You flagged a coming race between AI accelerated exploit generation and AI accelerated patching.
Speaker B: So I think when we talk about AI exploitation, we gotta think about you now have a determined attacker that can look at your network forever and just go into a loop until it finds its way in.
Speaker A: What's the downstream implication for those relying on NVD or other institutional entities like that?
Speaker B: The NVD was the dam that fell right in that rain versus flood. They just can't keep up. Um, nobody expected them to be able to keep up. Right. It's not fair to have one small organization in this be responsible for doing this for everyone.
Speaker A: The use of AI among attackers, as they get comfortable with the tools they use, open source gets more capable, etc, all these kind of things like how do you think about that?
Speaker B: If you have something that can just pound on every open door for days and days at a time, it's going to eventually find a way.
Speaker A: Foreign. Thank you for joining the Resilient Cyber Show. I'm joined by Jerry Gamblin. Jerry, thanks for being here.
Speaker B: Thank you so, so much for having me.
Speaker A: Yeah, I'm excited to have you on. You've been on the past. You're kind of one of my go to resources, uh, along with just a couple other folks, honestly. And like when it comes to signal from the noise of all things Vaughn, management, exploitability, exploitation, etcetera, uh, but for folks that don't follow you already and some of the resources and things you do in the community. Can you tell us a bit about yourself?
Speaker B: Yeah, so right now I'm just kind of doing the Robo Labs thing. It's an open source lab I built to kind of help democratize vulnerability data. I think a lot of the vulnerability data is starting to uh, be in a bunch of different places and a lot of smaller organizations and even larger organizations just don't have the time or the resources to kind of collect that and put that into one place. So I spent some time, my free time, just building up a few tools. You can check them out on rogolabs.net
Speaker A: yeah, one of those is CVE, uh, ICU, which I seem to cite like almost, I say bi weekly in my blogs and stuff at this point, you know, for making sense of CVEs, uh, for folks who haven't seen that, you know, what does CVE ICU do? And you know, what got you obsessed with going through the CVE data to maintain it, uh, you know, after year after year?
Speaker B: Yeah, yeah. I used to work for a startup called Kenneth Security and we were in the CVE space and we spent a lot of time there and a lot of this was back five years ago and people didn't understand how much data was in there and how the data looked and how it worked. And I ended up just building reports to send to our customers so that they could understand what was, what we saw as this wave coming and be able to dig in. And then I'm like, this data, uh, isn't available anywhere else. And I have the code, it's not proprietary, we're not making any money off it. So let's just throw it on the Internet and give it to people so that they can use it to be able to help decide what to do and kind of track some of the FUD and also some of the actual signal in the, in the noise. So, yeah, it's really, it's really a great tool for everybody to use.
Speaker A: Yeah, I have it bookmarked and I often check it out and cite it and you know, pieces I do on volume management and AI, AppSec, etc. Um, you know, also, you know, speaking of, you know, exciting, exciting news and noise, you know, first, uh, you co authored first mid year forecast that bumped the 2026 projection, uh, for CVEs from roughly 46% above the February number. Uh, if I recall from the article, you know, with the year to be on pace for maybe 70,000 CVEs for the first time. You know what surprised you most when you reran the data at the halfway mark, if anything, that we were seeing
Speaker B: a large growth and it was all from basically one source. Um, and that source is GitHub. Amazingly, GitHub is now publishing one in five CVEs that are published. So they are doing their job. They've really scaled up their CBD team and they're doing great work over there and pushing out a lot of vulnerabilities. So that's making that, that overall number look really, really high compared to where it was this time last year. We're just at about over 40% growth year over year.
Speaker A: Yeah, that's incredible. And also I noticed I'm picking up a little bit of a background noise when I speak on your end. It might be easier just to go on mute or just check your settings. There's real quick. Sorry. There you go. Yeah, I can hear myself a little bit in the background. But uh, it's crazy that they're playing such a, an outsized role. And the, the forecast points to kind of three structural drivers that it touched on in the update uh, the blog I'll share here in the show. Notes for folks. And those were AI assisted discovery, uh, a 449%, I think it was jump and GitHub security advisories, which you just touched on. And then a massive surge in V, uh, CNA of last resort activity. You know, help us pull those apart a little bit because they're very different kind of forces from different ent, but they all get kind of lumped together in one big scary number. Like how do they each play a part and what does it all look like?
Speaker B: So I think the easiest way to talk about this is AI assisted is the only thing that we can point to right now. There's nobody who has a CNA and anthropic or OpenAI yet. They're not putting out CVEs that say, hey, we found this with Mythos M or with, with OpenAI chat GPT. Right. So we just have to guess and you can see a little bit. And the best we could do is see that a lot of the findings that are coming from GitHub look like they are AI assisted. Um, but there's no way to tell for sure. And there's not a flag in the CVE record that says, hey, this is AI assisted or not. There's some discussion if it should be. I mean, I don't think it matters to most people. It would be a good geek number for me to have, but at the end of the day a vulnerability is a vulnerability and I care more about is it on my network and where is it at and how I can fit. And then you have GitHub, which we, you know, they, they've launched their GHSA, their GitHub security advisory. Most people don't know it, but just about Every repo on GitHub you can go to and report a severe security, uh, incident and say, I want to request a CVE for that and you'll get it. There's no gate on how popular the project is or how many downloads it has. So a WordPress or a Python script I have up there that might have only been used 10 times can get a CVE. And it's the first class citizen with a, um, Windows CVE that's on a billion devices and then you have Volnchek and Vulnchek is kind of interesting. I like what they're doing for the community. They're giving researchers a place to go to get their work pushed through. People just don't understand how hard it is to be on all three sides of the Vulnerability disclosure debate and I talk to people all the time about this. You have the users who just want to fix their product. You could then have the people who make it, the software engineers, the company who owns the product, who has to balance a bunch of data and a bunch of other issues before they patch it and then you have the researcher who really wants to see it get fixed and all three of them have everybody's best interest in mind but a lot of times they can't see all the data the other person has. So it gets rough. And I think V is doing a decent job trying to play that mediator role between, between companies and researchers and it's very much needed and very much welcomed.
Speaker A: Yeah, I recently actually had Patrick Garrity on from Vongtek and he kind of walked through of what that looks like on the back end to your point. There's lots of different stakeholders involved and uh, it's a process I think many don't appreciate, uh, in terms of how much is involved and how complex it can be. I actually didn't know that about GitHub as well where people can go on and request a CVE for any kind of benign uh, flaw, bug vulnerability, et cetera. And I could see where it could be problematic because it's not widely used and so on. But of course it still helps to track it like it's going to be relevant to someone in some way maybe someday. So I, you know, you don't want to just have a bunch of them that you know and also you have to who decides what the gate is. Right. Like what gets a CVE ID or not. Like that could be problematic too and subjective for sure. Um, one other thing I thought that was interesting in the, the blog and the forecast you all put out is like the headline number gets all the visibility. Uh, right. Like there's you know, everyone talking about the Vaughn apocalypse and all these different types of things and I've been guilty of it too. Uh, and everyone repeats the raw count of vulnerabilities but your guys fore forecast actually makes an opp point which is, you know, while that raw count number of vulnerabilities is going up significantly and setting records and so on, uh, the actionable exploitability has kind of stayed basically flat once you filter for Kevin epss, um, and you all use this phrase I believe in the blog, uh, where it talks about you know, kind of rain versus flood. So walk us through that rain versus flood distinction and you know, why it should change how people react to that big number. Uh, maybe they shouldn't be quite as scared or how do they, how should they think about it?
Speaker B: Yeah, we were trying, I sit down and we tried to figure out a good way to describe this so people could understand that, you know, there's really not a lot of good, good ways to do it. So we came up with the rain versus flood. Everybody knows that if it rains, you know, that that might ruin your day, but it's not the end of the world. But as soon as you get it to the point where it floods and overruns the bank and you start having water in your basement, then you really have to start start worrying about it. And we wanted to say that while we're seeing it rain, you know, for the next 10 days, it's not raining enough that, that it's going to flood. Your, your big. We're not seeing the vuln apocalypse that are finding the vulnerabilities that are easily and widely, uh, exploited. Right. And they could be there, but most of them we're just, it's doing what a good FCA tool would do and it's going through and it's cleaning up human created debt in software, mostly open source, that's easy to find and people are fixing it. So it's good. We act like there's some new issue with AI code, writing bad code, but we've been having this issue for 25 years and we have 25 years of human debt, of software code that we have to fix. I was talking to somebody at RSA and we went and looked and the OAS top 10 has barely changed since it was first published. So people have been making the exact same mistakes and now we just have tools that can find those mistakes at scale. So you're seeing what looks like a lot more issues being found, but most of them are not going to be exploitable.
Speaker A: Yeah, it's a good distinction on the exploitability piece and I think it's something that folks should still prioritize and has been for some time. But it become even more critical in the conversation lately of AI and AppSec and I think Anthropic, even, uh, recommended folks kind of rally around EPSS and things like that. Uh, and to your point, you know, it seems like a large chunk of the forecast is tied to, you know, AI assisted tooling. Right. Huge, uh, spikes from Mozilla CVEs, you know, running, uh, AI against the Firefox engine, things like that. I think it was 164% spike in Mozilla CVEs, you know, from the data you see how much of this you kind of answered this, but, like, how much of this you think is, uh, you know, AI vulnerability wave is kind of new risks and so on. Or is it just latent old bugs being found? And also I think it's like a. There's, there's multiple things there. Like it may be old latent bugs being found, which maybe it's good, maybe it's not. Maybe they matter, maybe they don't. Uh, but also GitHub, uh, there's also, I think it was a 14x increase they're projected to see in terms of commits, uh, this year. So going from 1 billion commits in 2025 to 14 billion commits this year. That's all new software, new code that would, you know, may have bugs and flaws and vulnerabilities of its own. So it's, it's kind of like, you know, yes, there's old code and now there's exponentially more new code. Like, how does all this kind of converge?
Speaker B: That's a good question. And I'm kind of just along for the ride also. It's just the speed of everything is speeding up. We know there's going to be more code written and more code equals more bugs. But on the other end we have faster security tools and security tools that will find it before it gets out there and says, hey, can you patch this? I love using Claude. I love using the security review skill that's built in, um, to find stuff that I normally would have missed even if I thought that I've done a good job. Right. So it's just another pair of eyes that is looking at the code. And there's a little bit to be said that AI is so hot right now that if you had a pen tester give you a finding last year in a report and then an AI tool found it this year, you could probably get the time to fix it because the new cool AI tool said that it was there versus the pen tester that found it last year. So people are using this kind of window that, oh, no, the AI, uh, apocalypse is going to find all this stuff to actually get some cycles in on patching their software, which I find really, really refreshing and useful.
Speaker A: Yeah, I think, uh, whether it's hype or not, you know, the vompocalypse, all these kind of things, if we can use this opportunity, uh, like as a cyber community, to get additional resources, focus prioritization around fixing things, maybe things that have been around for a long time, even that we've known about. So be it like we should take advantage of that for sure. And you're someone who, you know, you and I have talked about this before, but someone who watches, you know, institutional, uh, aspects of the ecosystem like nvd, nist National Vulnerability Database. As close as any. Right. You know, and we've talked about some of the struggles there before and now they've, they've been pretty public about them. You know, how are they supposed to enrich a flood of, you know, 70,000 CVEs a year? And you know, what does that data say about how well the MVD and broader CVE ecosystem are keeping up and kind of what breaks for defenders if enrichment does fall behind, which they talked about, uh, just doing, you know, a uh, subset of CVEs, ones that are used by, by the federal government once dubbed critical software, based on previous EOs, that kind of thing. Like what's the downstream implication for, for those relying on NVD or other institutional entities like that?
Speaker B: Yeah, the NVD was the dam that fell right in that rain versus flood. They just can't keep up. Nobody expected them to be able to keep up. Right. Um, it's, it's not fair to have one small organization in this be responsible for doing this for everyone. So who's responsible now is the, the people who should have been responsible from the very get go. And that's, that's the CNAS, right? The largest CNAS. Some of these top 100 Fortune 500 companies put out CVE records that are pretty embarrassing. Um, and for the longest time NVD was just basically correcting their homework for them. Filling in CPE, filling in CBSs and then presenting good clean data to the public with them not having to do the work. And now it's time for those companies to kind of step up and start providing the data that's needed. And I think that we talked about it at DEFCON last year is that when we renew our software, we hardly ever talk about the vulnerability data. And I, I've told CISOs and I've told security directors that you need to really look and next time you have X products coming up from review, if there's CVE records, doesn't have the data in it that you need, you have a great opportunity before you sign that contract to say, hey, we need better CVE data in here as part of this. And at the time, who's not worked in a software shop or hardware shop, the people who get the most stuff done are salespeople because if they come in and say, hey, our bad CVE Data is going to cost us an X million dollar deal. Somebody's going to say okay, we can move some stuff around, we can try to make this better. And that's the only time people have that leverage and should use it. And I think that uh, we really need to start see having people see CBE Data, uh, as a product that they're paying for.
Speaker A: Yeah, I was actually super pleased to hear you say that because my follow up question to you when you said like you know, the, the responsibility or burdens falling to those who it should have been with to begin with, the cnas was going to be like what forcing function is there? Because really they, they can say well you know, we're just going to do the status quo, no one's going to make us do anything different. But to your point, if you can use that as part of a procurement or an acquisition or you know, a contract of some. So uh, when you're getting ready to procure a product or renew or contract with a vendor, now you have that forcing function where maybe if there's a groundswell from the community, from customers, consumers, they may take action and make it a priority to kind of provide high quality CVE data. Right. CVE signal. Speaking of which, you talked about the CNAs and I saw you made a post, I uh, think it was yesterday or day before, uh, where the ndaa, the language in the latest NDAA has some information uh, in there around the CVE board I think it is, or. Right. Something of that sort. Can you elaborate on what uh, what the language was? Kind of the implications are there.
Speaker B: Yeah, you are way closer to D.C. than I am, so I won't pretend to know. But the National Defense Authorization act is a huge bill every year and it gets a lot of amendments and somebody at the House uh, committee subcommittee wrote a bill to replace the, the CVE board with a more structured board that has term limits, that's uh, made up of people both international and internal. It's interesting. I am um, in favor of it. I think that it's, it's time for the CVE board to be reshaped. I, I have some, some thoughts and issues with the governance of the CVE board to be very blunt. And if this is the portion, the, the function that actually gets them to change and to, to be more community focused, I think that would be, be really, really great. Overall. I won't pretend to know how much of a chance it has to be in the bill or whatever, but I there and people talking about what the vision for governance in that bill looks like versus what the governance is now is, is great.
Speaker A: Yeah. And I think that's actually a, ah, a good thing that it sounds like there's some international representation being moved in there because that was a big critique of the community. When NVD had its struggles originally, like I won't say originally but like a year or two years ago at this point, um, was the international community started kind of voicing concerns and wanted to stand up on their own efforts, uh, their own databases etc, which they of course have the right to do. That has implications for defenders. Now you got to reconcile the data from this database with that database and uh, so if we can get uh, more people on board and collectively, uh, working together internationally, I think it would be a win for the community overall. So I agree with you there. Um, I was going to ask you, you talked about the exploitability data staying relatively flat within the forecast. Uh, you sit pretty close to the EPSS and KEV data, uh, you know, among the community. When you look at what's actually being exploited in the wild this year, are there any trends that stand out or does that exploit set the question any meaningfully different than the noise of the full CVE list? Or how do you think about that?
Speaker B: I mean we're seeing the same classes of vulnerabilities still kind of rise to the top. Um, VPN concentrators from all the major vendors are always going to be a target for attackers because it's the keys to the kingdom. Uh, we haven't really seen any big Microsoft vulnerabilities this year. We haven't had a print nightmare of this year. But yeah, it's normally the same kind of software that gets attacked over and over again. The NSA every year puts out a list of the top 10 vulnerabilities used to breach companies. And they're always old, right, because those, those attackers are using tried and true methods of stuff that's just behind. So while AI is out there and finding stuff, we're seeing no, no news, nothing that says that it's being widely used, uh, to patch every, to, to attack everybody.
Speaker A: Yeah, it's honestly uh, it, it's. Why would they change if it's still working? Right? Like you know, it's, it works and it's tried and true to your point. So they continue to do the same things. And as you said, the OWASP, uh, top 10 hasn't changed for a long time because why would it, right. These are still the most widely pervasive flaws and vulnerabilities in the ecosystem. And really I think it's going to take bigger forces. The, you know, the market forces. The contractual stuff we talked about is good, but it's going to probably be regulatory in some way that's going to drive some big change. But of course, what that looks like, again, is a big discussion and not perfect. And it can have unintended consequences and super complicated stuff. But I'm curious to see how it all evolves. I wanted to ask you too. Like, you know the release you had in the Forecast blog, I think it was, uh, the job is no longer counting the drops, it is knowing which ones outrun the levy for teams drowning in findings like massive vulnerability backlogs, which are only getting bigger. Right. Due to AI assisted discovery. As you talked about, you know, what does billing capability look like in practice for epss and Kev? And what are some of the ways that teams still get it wrong when it comes to triage of kind of using these signals of exploitability, known exploitation, reachability, et cetera?
Speaker B: Yeah, it's data collection and data usage. It's the problem still, right? Like, we still don't know what's running on our networks, we still don't know what software we're using. And if you don't know that information, it's so hard to build tools to help you protect yourself. So I tell people that we really still need to build those CMDBs as, as best as we can. Right? Like, and then once you have that, then you can look and see and figure out what you don't need to worry about anymore, right? Like, Patch Stack has put out just over 3,000 CVEs. If I don't run WordPress anywhere on my network there, those are 3,000 CVEs I don't have to even think about. But most people couldn't answer that question with a high degree of certainty if they say, hey, I work at a big company, okay? You run WordPress anywhere? Well, I don't know, uh, because maybe marketing has it spun up somewhere, maybe somebody on the web team has it running on the back end somewhere. It's still that question, what am I running that we haven't been able to solve as an industry.
Speaker A: Yeah. And it's so fascinating because as you're saying that like, it's been a critical, you know, CIS control of, uh, asset inventory for decades, right? And it's still such a fundamental problem of understanding, like, you can't secure what you can't see or don't know exists. And like every Organization still struggles with that, uh, due to a lot of factors, shadow usage and just complexity and multiple disparate, you know, kind of trackings and methods and databases, etc. Um, but yeah, it's a fundamental step. You can't secure it, you don't know if you're impacted by it. Um, but I do think it's great to discern like how you did with like uh, WordPress is a good example because people hear the numbers and automatically assume like they're damned and it's like, well, not necessarily like what do you run? Are these even relevant to you? You know, let alone exploited and reachable and all those kind of things. Do you even have it? Like that's not part of the conversation that really happens in the industry and somewhat of cyber's fault because we love to use numbers, especially the vendors. Right. To kind of drum up fear and uncertainty and doubt, you know, FUD as we call it. Um, so last question for you. Looking ahead and kind of the back half of 2026 and beyond, you flagged a coming race between AI accelerated exploit generation and AI accelerated patching. Um, I'm curious which one you think nets out and what defenders in the CV ecosystem should do to stay ahead. I know it's a big question. I'm particularly interested in the AI accelerated exploitation piece because as you said like exploitation has stayed flat. We've seen a tremendous amount of innovation and growth around AI to system, AI assisted discovery. I am interested to see like DBIR already flagged, you know, exploitation as like the leading, um, initial, uh, access vector, attack vector. Right. I think it's going to grow even more. Right. With the use of AI among attackers as they get comfortable with the tools they use, open source gets more capable, et cetera, all these kind of things. Like how do you think about that? I'm curious how. I think we are definitely going to see, you know, AI assisted exploitation now kind of grow in time.
Speaker B: Yeah, I think AI assisted exploitation is coming, but it's not going to be as widespread. Like we're not going to have those exploits that go everywhere. But what AI is really good at, uh, is working on a problem until it solves it. So I think when we talk about AI exploitation, we got to think about you now have a determined attacker that can look at your network forever and just go into a loop until it finds its way in. Right. I can say I want to hack X company. Here's all the IPs I know spend the next 48 hours just trying to get in and doesn't need to sleep, doesn't need to do anything, right? So it's not kid in a, you know, in quotes kid in some his mom's basement anymore. It's a GPU running in some data center that is just churning away for forever until it finds its way in. And we all know that, that getting into a network, there's always a possibility, right? There's always going to be something, some way. No network is 100% secure. And if you have something that can just pound on every open door for days and days at a time, it's going to eventually find a way in.
Speaker A: And that's what uh, agents seem to be the best at, right? Is just continually, uh, persisting towards a goal until they achieve. And often they'll do it in an innovative way that we didn't even anticipate or think about out. Um, so I think it's going to be interesting to see how that plays out in the exploitation space. But, um, Gary, nonetheless, thanks so much for jumping on to me, jumping on with me. Like I said, you're one of my top folks. I follow for all things fall management. Uh, check out Robo labs, check out CVE ICU, uh, and follow Gary on LinkedIn. Again, thanks so much, Gary, for jumping on.
Speaker B: Thank you so much. I always enjoy it. It's always a highlight when I can do this. But thank you for the time.
Speaker A: Absolutely. Take care of.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.