AI Vulnerability Discovery and the Open Source CVE Surge

Hey, guys. Thanks for the throw. We're here with Aaron Mitchell, who's the CEO of HeroDevs, and we're talking about Mythos and the implications for developers and application development teams, because it looks like there's going to be a tsunami of vulnerabilities on the way, and maybe this is the calm before the storm.

Aaron, welcome to the show. Hey, Mike. Great to be here.

Thanks for the invite. What's your assessment of what's going on here? Because on a certain level, only certain companies seem to have access to this just yet, but I got a sneaking suspicion that probably the open source community's going to go, "Hey, we can do the same thing," and we'll have this capability will be broadly available.

So if you're a developer these days, what's your take on what's going on here, and what are the implications? Yeah. Well, the thing that we're hearing from our partners, our open source maintainer partners, is that the volume of vulnerabilities that are getting disclosed and reported to their projects, it's off the charts.

NET projects. Just this last two months, we've seen 30 CVEs come in on the Spring project. And to give you a reference point, last year, all of 2025, there were only 17 CVEs that got reported.

So certainly, an overwhelming amount of vulnerabilities are being found through these AI tools. And one of the things, the repercussions, is that open source maintainers are overwhelmed. They don't have enough time to address this tsunami of CVEs that's coming in.

There's some fatigue, there's some burnout that we're starting to see. And there's a real need to lean in and help these open source communities just deal with the wave of vulnerabilities that Mythos and other LLM tools are finding out there. Are you at all worried that these maintainers, many of which are only a handful of people working on a particular project, may just decide to give up and close up shop on something because they're just going to be overwhelmed?

Or is it feasible that maybe the AI coding tools they have will allow them to keep pace with the patches that need to be created? Yeah. I think we're going to see a mix of both, to be honest.

" And the amount of time that it takes to report a CVE is a fraction of the time that it takes to actually go as a maintainer, verify if that vulnerability does indeed exist. And so as the LLM tools out there continue to evolve and mature, I think we're going to see those tools catch up, and in the hands of the maintainers, it will help deal with the influx of vulnerabilities that are coming in. But just anecdotally, what we're hearing is, yeah, there is some fatigue there.

I expect that we will see some burnout across some projects that are solo maintained by a single person. Or we may also see a lot of projects just get abandoned silently, and nobody knows that the maintainer's no longer working on them, and it's just kind of lurking in your code base until something really severe happens, and you're left without any recourse as a company. So what should be done here to support the open source maintainers?

The fact of the matter is that 95% of the companies that consume open source software don't seem to be contributing much back to it, and the maintainers don't have enough money to work on these things or hire more folks, and they're dependent upon the kindness of strangers. And so what ultimately needs to be done here from your perspective? Yeah.

Well, I think that there is a lot that can be done in the industry. HeroDevs, from the very get-go, we have partnered with open source maintainers to help keep their old versions that they don't want to support anymore, keep those secure for companies that are stuck on them. And as part of that program, we've actually created a $20 million sustainability fund for open source maintainers for exactly this reason, where we can give financial resources back, and then we also, as we're out and we're looking for vulnerabilities inside of these libraries or finding vulnerabilities, we make sure that the author, the maintainers are aware, and we give them the steps to reproduce, and then we also tell them, "Here's how we fixed it.

" So I think as much as you can, just giving your time, donating back if you're going through and you're concerned about open source security and fixing these vulnerabilities, making sure you loop the maintainers in to say, "Hey, we found this, we fixed it. " And over time, that takes a huge load off of these maintainers. Now, it does seem to me that the other elements of the open source community are probably going to try to replicate what Anthropic and OpenAI have done.

And then that'll have equal access to everybody, so at some point, won't the adversary start using something similar to start analyzing code bases and generating exploits in what may seem like, I don't know, a few minutes as we go forward here? Is this whole thing going to be now operating at machine speed? It's a great question, Mike.

I don't have the answer offhand. I don't think anyone really knows how this is all going to shake out. I think the way that Anthropic, that OpenAI are approaching this from a perspective of let's be really cautious, because to your point, this gets in the hands of the wrong actors, it could be catastrophic, cataclysmic.

Right? So I think that we're doing it the right way now, and in this whole ecosystem of vulnerabilities and CVEs, if you are somebody that's reporting these things, you have an obligation to be discreet about how you report these, and you have to follow a common vulnerability disclosure policy to make sure that all of this is being done responsibly. And I have faith that the systems that we have in place are going to protect companies from this, but certainly if I'm a CISO or I'm an app security team member at a big company right now, I've got to get a handle on this as quickly as possible, and I have to be vigilant about making sure that I'm not putting my company at risk by overexposing myself to vulnerabilities in open source libraries that aren't secure.

Do you think at some point that we're going to have to have maybe a, for lack of a better phrase, come to Jesus meeting about the quality of the legacy code that we have out there, and maybe rewrite a lot of this stuff? Because fundamentally, it was created by humans, and well, humans only have so many capabilities that if we're going to keep discovering new vulnerabilities every two minutes, maybe we should start over. Yeah, I think it's difficult to overestimate how entrenched a lot of major enterprises are in their legacy libraries that they're using.

And we see this firsthand. We have over 1,000 customers at Herodevs that are using our libraries because the pace of change of these open source libraries is too fast, and it's just not feasible to move to the latest version. And so even if we were to go back and try and rewrite and patch all of these libraries, the amount of change that that exposes enterprises to is it's not realistic for them to be able to adopt those changes quickly.

" One of the complaints that has always been around for a while is that there was, well, there are just too many CVEs, and it seems like it's easy for them to get generated and reported, and we don't really have a good way of validating whether or not that CVE is or what if the right threat level is being ascribed to it, or the right risk level, or whatever you want to call it, because a lot of folks will say the risk ratings are too high, and why is it B in this CVE that we reported only exists on every third Tuesday on a leap year, maybe. Yeah. Not all CVEs are created equally, right?

Mm-hmm. And to your point, I think companies have been like the strategy up till now has been whack-a-mole. Right?

" You got to go do the investigation about where is this in my stack, how does it actually impact me? " And you do that over and over and over again. It's a very reactive model.

It's not predictable. It's not stable, right? And as the number of CVEs getting reported is growing, right, before Mythos even launched, we were pacing at above 33% year-over-year growth in CVE reports.

And who knows what that number is now. And not only the number of CVEs, but also the unique number of libraries that have CVE reports on them. " And that way, they can get in front of this challenge that is only going to get worse and worse for companies that continue to stay reactive.

Are you at all worried that a lot of organizations will start reducing their dependency on open source because of these security concerns? And while that may not have seemed viable a few years ago, it seems like a lot of folks these days are just using AI coding tools to generate something that is the equivalent of something else, and just running it with themselves, and away they go. On one side, you have people that have never written a line of code in their life now using Claude to build these Vibe code, these applications that who knows what data they're exposing out to the ethos.

And so that's pulling in all who knows what kind of open source libraries as well. There's no governance around it. " And they will narrow the scope of how big that list is.

But I certainly don't think open source is going to go away. I don't think companies will abandon open source. Open source itself is fundamental to how these LLM tools like Anthropic, like OpenAI, are building software.

They know what libraries are out there to perform and shortcut functions that would otherwise take a long time to replicate. Of course, there have been some efforts, or at least steps in the right direction, maybe. The Linux Foundation announced an initiative, I think it was 15 million in funding, with help from a handful of the cloud service providers.

And while that was greeted with at least some recognition of the noble intent, other folks said 15 million is a drop in the bucket for what you have done here. And ultimately, those companies are reaping billions off of this software. So is there just some sort of imbalance in the system?

Yeah, I would agree. It is just a drop in the bucket. I think GitHub said the value of open source is in the trillions of dollars, maybe tens of trillions of dollars to commerce as we know it.

So 15 million, while it's a nice gesture and a big number, it pales in comparison to the value that open source is providing to the economy as we know it. So, yeah, I think as long as you have companies that have shareholders who are trying to make a buck, you're always going to have some companies that are taking advantage of the system without giving back. But I also got to believe that there's a lot of companies out there like HeroDevs that see this problem, that empathize with the maintainers, and in a lot of cases are maintainers themselves, that are saying, "You know what?

We're going to invest in the long-term viability of open source. " And so, I have hope that there is a way out of this Wild Wild West that we're in right now in open source. And the maintainers themselves, you've got to sympathize with them.

A lot of them built this project. It's a hobby. Yeah.

It didn't occur to them or wasn't intended to be used by some enterprise that was highly dependent upon it all of a sudden for nine layers of a software stack. But ultimately, what's their responsibility here? Because they built the software, but they didn't tell people to go to deploy it.

m. to start working on a patch? Yeah.

It's a great question. And I'm in the camp that I believe that any maintainer, they don't owe anybody anything. They're not getting paid to do this work.

So if I'm an enterprise, any expectations that I set on this person, it's unfair to the maintainer. They're providing you out of altruism and the goodness of their heart, something that helps you run your business. And so if something were to happen, that's the cost of using open source, right?

Now, that being said, knowing a lot of these maintainers, they care a lot about the community that is using their tools and their libraries. And so, the vast majority of them take that responsibility and onus on themselves to provide security for their community. But to expect that, I think is misplaced.

I don't think companies should be expecting that from the maintainers who, again, are just doing this out of the goodness of their heart. And to your point, Mike, a lot of these, it started as a hobby. They never expected it to get as widely adopted as they wanted.

And when it first starts getting adopted, it's exciting and it's really refreshing, but then all of a sudden now you realize, I've got the shackles on because I have all these people relying on this thing that I built, and I just want to keep innovating, but they keep pulling me back into trying to patch all this stuff. So yeah, I think we love open source maintainers and we're always going to be on the side of these guys and gals saying, "You've already given a lot back to the community," and it's the responsibility of the companies to make sure that they're using it responsibly and securely. Right.

And to your point about that, should they only be using maybe distributions of something that someone is committed to support? Because I think there's a tendency where a lot of them over the years have downloaded raw open source bits and inserted that into their enterprise environments without thinking through who's going to be responsible for ultimately who you're going to call when there's a problem. So do we need to just rethink the whole way we consume open source and to kind of take the pressure off the maintainers, but at least put somebody in the middle there who's going to step up?

I think that's right. I think that is the right model. I think we're going to see more and more of that behavior as the dust settles on what's happening in open source right now.

But I 100% am in that camp to say, yeah, if you need security and you need SLAs and you need to make sure that you're compliant, go with a commercial vendor who's on the hook to provide that for you. Don't expect the open source community to deliver that when you're not paying them a cent. All right.

So are we just waiting for some massive event and we're all kind of sitting on the edge of our seats looking at this tsunami coming our way? Or do you think organizations are going to be proactive about this and get in front of this? Or is this going to be yet another circumstance where we can see a security issue coming from 10 miles away, but we're going to wait for it to actually happen before we respond?

I have to believe with the conversations that I'm having, that almost every company sees the risk right now in adopting AI at this breakneck pace inside of their company. And so I think a lot of people see it. How they respond, I think it's going to go a lot of different ways.

There's going to be some companies that are ahead of things and securing things proactively. There's going to be some that just are stuck. They're behind.

They're not going to be able to catch up. And yes, I absolutely think that we're going to see an increase in the number of security events, and I think the question that's scary to contemplate is how seismic are those events going to be? Because the ability of AI to now really, really widen the hole on an exploit is unprecedented.

We've never seen it before, and so who knows what's going to happen next, but there's going to be a lot of headlines in the future for sure. All right, folks. You heard it here.

Those AI folks, they're always running around saying, "Go fast and break things," but I guarantee you it won't be them that's coming to help you clean it up. Hey, Aaron, thanks for being on the show. Yeah.

Thanks, Mike. All right. And back to you guys in the studio.