A (2:47)

Yeah. My first experience with OWASP was Chuck Flieger, who wrote the textbook Security and Computing, was working a couple offices down from me at a consulting company and he said, hey Jeff, you're into AppSec. I think, you know, this new group might be something you might want to follow. So I got on a mailing list and there were like 20 people on there talking about AppSec. This is 1999 timeframe. And the first thing that I noticed they were doing was they were building an insecure application to help teach people about AppSec problems. And so you have to have real examples. They were building one and I had already built one for training classes that I was given to developers and so on. And so I said, hey, you know what, I don't know much about open source, but if they build one, nobody's ever going to use mine. So why don't I just donate mine and make it open source and see what happens. And that was called webgoat and. And it just took off. People loved it, started sending really good messages, like people started calling us about appsec services and stuff. And I was like, hey, this is really cool. So I got invested and then later that year I had this idea for having a top 10 list that we could help people focus on AppSec problems. And so I wrote the first OS top 10 and that went crazy. We got slash dotted and maybe some of you youngsters don't know what that is, look it up. But it really took off and over the year and then so a few years later, I took over as the global chair of OWASP and built out the Chapters program and turned it into a 501C3 and grew the organization. Now today it's become a global nonprofit with I think 250 chapters around the world, hundreds of open source projects and a big community trying to help people think about how to build better code.

B (4:31)

And still issuing the top 10.

A (4:33)

Yes, there've been a lot of versions of it. I think we participate every year. We provide data to it and I comment on it, but other people are leaving that project now. It's become very data driven, which is really cool. The first one was off the top of the dome and over the years it's become more and more scientific, which is researching this.

B (4:51)

I actually looked back and looked at them. It was pretty accurate, but I think we had fewer problems. Maybe we had fewer problems, I don't know. They were just.

A (4:59)

Truth is, it hasn't Changed very much. It's still the same problems basically. And not a lot has changed in AppSec maybe until the recent few weeks.

B (5:10)

Yeah, I think this, the software supply chain moved up and I think that moved up with everybody else's consciousness of it. I think that was a big one and. But yeah, I think people should. And people should look at it. This is a worthwhile thing to look at and ask yourself questions about and worth the time.

A (5:28)

But one of the last talks I did with the OAS top 10 was I added the use of unsafe libraries to the OSDOC 10 in 2013. And that was before people were really talking about it very much, but it became a very large thing in 2013.

B (5:44)

Yeah, any day now we'll catch out of it. Yeah.

A (5:49)

Listen, things in AppSec move really slowly and I caution people that, you know, even though things seem obvious and like they're going to explode, it really takes a very long time because the processes and people and companies are very embedded.

B (6:07)

There's a commercial here in Canada that we have some of these. Can a bank learn? And that was a big commercial and really bad mistake of marketing because everybody said, no, absolutely not. I sometimes think as an industry, can our industry learn eventually or it just

A (6:24)

some new industry replaces it? Right.

B (6:26)

Yeah. But I think this week or over the past weeks this, I don't know, I was, I've been reading this stuff. I'd like to. That's one of the reasons why I'd have this conversation with you is was Anthropic has made a big splash with a security problem from an AI model that hasn't even been fully released yet and, and named, thank God, Mythos. And I have to say this because as a Canadian, I still got a. I gotta call it Claude. I cannot call something that smart a Claude. It's, it just, it's our vocabulary. You just have to live with us north of the 49th parallel. Nothing you can do about it.

A (7:05)

So that's the process.

B (7:06)

Yeah, but Mythos has a big name and already some myths attached to it. Can you tell us what your impression is from what you found out?

A (7:15)

Yeah. So they've put a lot of work into making the new model, Frontier model that has a lot better training on application security, particularly finding vulnerabilities. And so they, in order to test it out, they put it to work trying to find novel vulnerabilities in a lot of open source products and it's. And commercial products and it's found a lot. Apparently they haven't released a lot of details about how it works or how long it took or how many tokens it required and so on. But they are saying the results are pretty good. That it's found new CVE is in most major operating systems and products and environments. So that, that's cool.

B (7:58)

Yeah, they've released a couple, or somebody's released a couple of them. One of them is 10 or 15 years old. It's been sitting in the code forever.

A (8:04)

Yeah.

B (8:05)

And this is. So this is code that we would think of in most cases as having been hardened.

A (8:12)

And yeah, you would think that you'd be wrong. You think about all these open source projects. There's millions of open source projects out there and the vast majority of them have had almost no scrutiny. Remember the CVEs that we find and people look at the CVE rate and they say, wow, it's going up year over year. It doubled in 2026 or 2025. And, and they don't realize that those CVEs are largely discovered by volunteer researchers just doing the work because they like it. It's not like there's a big organized effort that's systematically weeding out and hardening our open source infrastructure.

B (8:50)

Yeah. And open source obviously can't afford the bounties. But the, and we can talk about that as well because I think that's an issue that comes up out of this. But the idea of open source was supposed to be it's more secure. And we've said this about Linux because there's so many people going through the code. And you're saying that's not necessarily the truth.

A (9:13)

It would be true if more people actually went through the code, but that's not really the case. People go after some high profile things like the Linux kernel and so on. I think OpenBSD has done a really good job with security on their project. There's projects out there, but they are the exception, not the norm. And I've said for a long time, I think the number of CVEs is absolutely dwarfed by the number of latent vulnerabilities that are out there that we haven't discovered. In a way it's like bitcoin mining. They're all out there waiting to get mined and you have to invest a certain amount of time and effort and money in order to unearth those rare gems.

B (9:53)

Yeah, and I think we can. I'm not, we're not picking on the open source community, but I gotta tell you, I do a security show and the commercial software ain't doing so Good either.

A (10:04)

No, I totally agree. And in fact I spent many years doing penetration tests and code reviews of commercial applications. And we also looked at a lot of open source stuff as part of that. And generally I would say that the open source stuff is way better. There's something about having to publish it online that I think makes you have a little pride in what you publish. The internal corporate applications are often given very trivial levels of security analysis.

B (10:36)

Yeah. And I. My discovery from the open source community is people aren't shy about criticizing oh no, hi, hey stuff.

A (10:46)

As the author of several pretty widely used open source projects, I can confirm that there's People are quite brutal with open source people that are building cool stuff on their own time because they love it. But that doesn't really seem to change.

B (11:00)

Like we were starting something as an open source project in between a group of us who got along famously prior to actually starting this, which led to my joke that the difference between somebody in open source and a terrorist is you can negotiate with a terrorist. Well, yeah, but the idea is there and the bugs are there in code, both open source. So do you think that Mythos is really going to explode this? Is that what you're hearing?

A (11:30)

I think. I don't think people know exactly what's going to happen, actually. So a lot depends on some of the data that we don't know yet because Anthropic hasn't shared it. If they, for instance, reduce the cost of using Mythos to near zero, then I think it would absolutely explode the number of vulnerabilities that are out there, because people would apply it to everything. But the basic back of the envelope math that I do, the tokenomics of it say that this is going to be actually really expensive. They indicated that it might be 15 to $20 per PR. And if a developer is doing 5 to 10 PRs a week, that's a lot of money. And you multiply that out and it's 50 times more expensive than using traditional approaches.

B (12:16)

I've been amazed and I haven't dug into this yet in terms of the cost of Anthropic. I think they've got a brilliant business model going there. I was reading one piece where a developer was talking about having spent $250,000 in tokens over a year, but I'm looking at it going, holy geez. Even in today's inflated terms, you can get. You can buy a developer for that,

A (12:39)

but what if it triples the output of that one developer?

B (12:42)

Oh, yeah, absolutely.

A (12:44)

And I think that's. I Think that's actually where the price is going to end up. Leveling out is like the cost of using AI should be just a little bit lower than the cost of doing that same work with humans? And that's really expensive.

B (12:59)

Yeah. From your lips. That Adam Smith, Sears. Yeah. It's going to balance out because people are going to drive a good profit out of that. Nothing wrong with that. I think it's a business to make money. But I'm just. I'm admiring Anthropic in terms of how they've been able to turn this into a bit of a money machine. But Mythos is supposedly very expensive and that I. There's two reasons they say they kept it off the market. One is the security issue, and the other is the cost. And maybe I'm just cynical, but I'm also. I'm thinking cost had something to do with it.

A (13:34)

How long is it going to be before other models come out that can do the same thing, whether they're. And not every company is going to have that same philosophy of keeping it away from the people.

B (13:45)

Yeah. And that's the famous story from Anthropic. Whether it's true or not is that they actually had a model out that earlier than some of one of the big models for OpenAI and they didn't release it because they were worried about safety. And now they're the smaller company. And I. You never know how true these things are. They could be industry myths, but still sitting on something that is this big is a commercial problem.

A (14:10)

So you asked about what's the outcome going to be? And I think if it's more. Even if it's better, if it's more expensive or slower or not as scalable or not as deterministic as using traditional tools, then I think companies are by and large going to stick with the traditional tools. There's no real incentive for them to move to something that finds more problems. And I wish that they were more motivated to actually secure their software, but the fact is they've moved to cheaper and dumber tools over the last 10 years. The static tools from 10 years ago are way better than the static tools that people are saying selling and buying now because they're cheaper people. So the AST market has gotten commoditized that way.

B (15:04)

And the other piece of this is until something like Mythos can fix the errors, discovering a lot more errors is not necessarily a good thing. That's because of the attacker, in which

A (15:18)

case finding lots more vulnerabilities is just fine.

B (15:22)

A friend of Mine says that the attackers have always have the advantage in AI because they only have to find out the problems, they don't have to fix them. And I think that's true.

A (15:32)

I think AI can fix problems and I suspect that Mythos is better than other models at doing that. We use AI to do auto remediation of the vulnerabilities that our company's products find, and it works pretty well. But it's also, you have to think about the cost and time and other factors when you think about it.

B (15:55)

Yeah. And we divide into our own groups of who believes in this? I've got a friend who, who's. Well, I put him in the AI skepticism camp and he came to me, said, I've seen some of this code, it's terrible. Yeah. Said that you just became a programmer, my friend, because every programmer who's ever looked at code thinks it's terrible. Including. I got caught one time reading a piece of code and people fooled me on this one. I read it and I went, this is just crap. They said, it's yours. Oops. I went, oh, let me take a second look. But it's true. There's a lot of. I don't even know if we've got a good definition of good code other than it's documented.

A (16:35)

I'll give you an example from yesterday is I was creating a little utility tool to go through a bunch of. Bunch of files and make some changes to it. And it took, I ran it and it took 10 minutes and I was like, that's crazy. This should finish in 10 seconds. And so I looked into it and I was like, the way that it structured the loops was just absolutely nuts. And so it was doing the same reading of the template files, like for every single file instead of reading them in once and just having them. And so it was really super inefficient and it's a very obvious mistake. And AI makes that kind of mistakes all the time.

B (17:17)

Although I used to work with people who were always obsessed with the efficiency of code and they would. They think they'd done something really great if they spent a whole afternoon turning something into a statement that's non maintainable. Somebody's going to see that five years from now and go, you'll see code brown like abandon. Or comments are like abandon all hope. All ye who enter here.

A (17:40)

Do not change this code for any reason.

B (17:42)

And if you know what it does,

A (17:43)

I don't know why it works. Yeah, don't change it. I'd love to. Since I have you here.

B (17:48)

I just want to talk a little bit more about AI and security. It's obviously your company's trying to engage with that. Yeah, the feeling that we get, that I get from talking to people is that we. And part of it is my own opinion, I must say. I believe that AI in its current state is fundamentally insecure as a starting point. And that's been my opinion of it. But what is, what's your impression and opinion of where we're getting to with AI and AI driven code?

A (18:21)

So let's talk a little bit about a software factory. Right. The software factory that you and I grew up in is people driven and you know, started with requirements and went through a process and there was testing and eventually get to production and deployed and the, a lot of people in there. And people are fundamentally insecure too, by the way. Really bad actually. And so the trick is, how do you design the factory so that the outputs will be secure, even though the components that you use to build it are not necessarily secure themselves? And that's an interesting engineering problem is how do you design that factory? So the cool thing about AI, I think, is that you can iterate faster and change your factory based on the output. There's a feedback loop. And so if your factory is set up and it produces something insecure, you can immediately feed that back in and say, hey, okay, let's change the factory so we never do that again. And if regular software, human factories were like that, then we would have stamped out things like SQL injection and cross site scripting decades ago. But there's very little learning going on in that environment. So I think the opportunity for us is to build better software factories that are powered by AI. And if you think about what Mythos just released, it's like they released a way of streamlining one part of that factory, the part of the factory that finds vulnerabilities. And your point was like, okay, maybe it's good at that, but it's not good at fixing vulnerabilities. So the vulnerability analysis piece is the first domino to topple and you can update that, but it's not going to produce more secure code unless you fix the rest of the factory. So maybe the next thing that topples is remediation work and we take away that horrible grunt work away from people and we start getting AI to do that and we optimize that. But then you might say that's not really secure by design, which is ideally, I think, where we all want to get to. But we're strapped in place by this hamster wheel of pain process that we've engaged in for two decades. So maybe the next thing to fall is like threat modeling or something, or security architecture, and maybe we start building models that are better at that. And eventually you get to this point where you should be able to say, build me this thing. And it goes into this factory and it goes through all its cycles and iterations and design and so on. And the code that comes out is secure because it's identified the threats. It's got defenses in place for each threat. It's got tests for each defense for correctness and effectiveness. It generates assurance evidence that proves what it's saying. And so not only do we get the software, but we also get an assurance case that explains why this thing is secure. So for me, that's the journey that I want to engage on. I want to make that happen.

B (21:31)

Yeah, the. And I've been a big critic of company coding factories where people say that we have things like lessons learned. I've been said, look, it's only lessons learned if we actually don't do it again. So I'm critical of that. But the problem, and I don't mean to be flip about this, the problem, conceptually I have, is if we were speaking algorithmically, then what? I write an algorithm, I know I can count on it to do the same thing each time. The problem, the foundational problem I have with AI is that it's probabilistic, and so it's not necessarily going to execute the same thing the next time the same way. And I think all of us have discovered that. And that that, to me is what I meant, is a foundational problem of security and mythos, I guess, having something that checks it maybe takes us a long way to get there. I haven't fully thought it through myself.

A (22:22)

If you think about. There's. So the existing factory has a lot of probabilistic elements in it called developers and architects and validators and testing kinds. I'm not wedded to the idea that we can't do better than what people are doing. I think that's actually pretty easy. The trick for me is, like, how do we get to a place where we get the software and we get a good assurance case that provides the evidence that proves that the defenses we thought were in there are there and that they work and that they're effective? And then we can monitor that thing in production to see, hey, is it getting attacked? Are we detecting the attacks? Are we responding to them correctly? That's another piece of this puzzle. Is like what happens in runtime.

B (23:10)

Yeah. If you were starting from scratch now and you were building a development shop, what would you do differently from what you've learned from watching this and watching AI over the years?

A (23:27)

Yeah, I would think I'm doing that because I've got a development team here. Contrast. And so we're in this journey, we are actively working to transform our development processes to take advantage of AI. I think, like you, I come from a. An older school of software where I'm not really ready to just flip the switch and say, AI, you figure it out, you be the orchestrator. I think it's better if we have human and algorithmic orchestrators at this point, but we're actively working to generate better specs and feed those into AI tools. And we're involved in the process, but there's much more autonomy. And eventually I think there's like a progression of your maturity in using AI and it goes from you start with using it like a search engine or like autocomplete, and a lot of people get stuck there. What I've heard from a lot of people and in my own use is, is that you get to a point when you realize, I just want to write a really good spec and feed it into an army of agents that will turn that thing into code. And that is several. I think that's the kind of the goal. There's some steps in between and we're somewhere in our journey. We're starting to turn more over to the AI processes. But for us, it's always we got to validate that it did the right thing. There's no just vibe, code it and launch it into production.

B (25:01)

Yeah. And I think taking the attitude that you've taken, which is that humans are fallible and we always say if AI makes one mistake while they write it off, if a human makes one mistake, that's a learning moment. But I think that we have to have some understanding that we're not dealing with perfection on either side. I look at, you know, with most CISOs, I say that you're managing the blast radius. You can't do everything. And because you can't do everything doesn't mean you can't do something. But figure out your blast radius and try to figure out how you reduce that.

A (25:32)

I want to challenge people to think about how they're currently succeeding at AppSec. When the average application has 25 vulnerabilities and a bunch of vulnerable libraries, when they're being attacked all the time. These are not great numbers. The average Time to remediate a vulnerability is six months. Plus the bar that we're comparing to is stupefyingly low. Like, embarrassingly, like, I wouldn't want to tell my mother that's how the software she's trusting is built. And can we do better?

B (26:08)

Sure.

A (26:08)

But I think a lot of AppSec people are locked into the idea that they've got to do it this one way. They've got to follow like some ancient maturity model that we wrote 10, 15 years ago. That hasn't worked. It's demonstrably hasn't worked because it hasn't worked in two decades. We can do better. We could stamp out all of the OAuth top 10 forever. That was the original idea, but we just haven't gotten there. Let's try some new stuff. Because the biggest risk is continuing to do what we're doing now. It's not working.

B (26:41)

Yeah. And just finding what's. Because I have a lot of CISOs in my audience and many of them are standing on ledges most days. We've got to the point where don't allow them to have an office that's not on the first floor because we don't want them to be able to jump. How do you keep a sense of optimism going? You're obviously an entrepreneur. That implies some optimism. How do you keep that optimism moving forward in an era that is so challenging?

A (27:06)

I think for me it's about solving the next hard problem. Yeah. You might have seen the Martian. Right. Like he. There's one problem that comes up and you work on that one and you survive and then you work on the next one and hopefully you keep doing that and you manage to make it back to planet Earth.

B (27:23)

That's actually a good. It's not a bad model because how.

A (27:27)

You gotta be optimistic to do it, though. Cause if you. Once you decide that you're dead, it tells your motivation.

B (27:33)

Yeah. And if you stop, you're stuck in your own poo. Yeah. Sort of spoiler alert if you haven't seen the movie. But, Jeff, this has been great. Thank you very much for having the conversation with me. How do people get a hold of you if they're interested in what you're doing?

A (27:54)

A great way to reach out to me is LinkedIn. Shoot me a message. You can follow me. I post a lot on there. I was posting about Mythos just yesterday. Posted something about the new Product Liability Directive in the EU today, which is amazing. If you're interested in whether you should be liable, legally liable for software security, vulnerabilities Then you should read my post because it's coming fast.

B (28:18)

We will indeed read it. Can you just. You. We're already here. And tell me a little bit about it. Yeah.

A (28:23)

So here's the coolest thing is the EU a year and a half ago enacted a new directive called the Product Liability Directive that does something incredibly simple and amazingly powerful. They said software is a product. And what that means is that you're liable for any defects in your product that cause harm, specifically including security defects, and specifically including defects that come from open source libraries that you use like any. It doesn't matter. It's what's called a no fault liability rule, which says it really doesn't matter how you built it. You're liable for any harm that comes from defects in your software. And it's the member states had two years to implement it, which is coming up in December. On December 9 this year, everyone selling software into the EU will be potentially exposed.

B (29:21)

So if I do a Delta just thing in the eu, my company is now responsible for the damage that might do? Yeah, there was that famous lawsuit from an airline trying to sue a software company. Not altogether successful in terms of being able to.

A (29:43)

That's because in this country, software's treated differently than any other kind of product. And you can put a license agreement on it that says we're not liable for using this for its exact intended purpose, which is crazy. So they're making it like any other product, which is. I think a lot of people in this country have talked about inching towards that by maybe making people disclose some stuff or write S bombs or whatever. But the EU just went all the way to 11. They went completely other side of the scale and they said, we don't care, we don't care how you built it, we don't care what you're compliant with, we don't care how you tested it. If it's got a defect that caused harm, you're liable. And they're hoping to put the burden on the software developers for security as opposed to leaving the burden on the consumers, which is legally like the right thing to do.

B (30:36)

Even leaving the EU doesn't get you out of it. I know in many countries you leave that country, you claim you're not under their jurisdiction, but the EU has been famous also for extending its jurisdiction to anybody who does business in the eu.

A (30:49)

That's right. In this case, it's anyone who sells software to an EU citizen, regardless of where, when or how. It doesn't matter.

B (30:58)

Does that apply to open source I got a Now you may.

A (31:01)

So it applies to open source that you include in your commercial product, but it doesn't specifically go against open source projects themselves because I don't even know how that would work. Like that would kill open source tomorrow.

B (31:15)

Yeah. Because the only I was. And that's one piece that I looked at and then looked at people starting to hold CISOs accountable in the US or at least. And that to me, scared the bejesus out of me. So be interesting to see where this goes to. At least. At least maybe the CISOs are going. least it's not me they're after.

A (31:34)

Yeah. I think it's a fundamental change in the way we think about it. It's actually one that I've been pushing for a long time, but because until the economics change, we're never going to make any progress in software security. It just doesn't. It doesn't make sense for companies to spend more than their. The bare minimum.

B (31:53)

Yeah. And it goes back. Pulling it full circle goes back to that idea of there's no percentage in finding these bugs if you're not going to fix them.

A (32:02)

That's right. And like I said, you know, CISO's mostly, their behavior says that they're choosing the easiest tool to run, not necessarily the one that's going to find the most.

B (32:12)

Yeah, I forgot. Totally forgot. Something I wanted to ask you about. I'm going to just look at my notes and this is why I make notes, is why I don't look at them. But this whole thing with Mythos, what happens to bug bounties?

A (32:23)

Yeah, it's an interesting question. So essentially, I think Mythos can do the job of a bug bounty. And so if I'm a CISO and I'm deciding whether to hire a expensive bug bounty program or hire a pen tester, both of the outcome is the same. In both of those, like I get these vulnerabilities, it seems much more likely that they would use it to replace that than that they would build it into their factory and use a million tokens every time they change a piece of software. It seems much more likely that they do this maybe once a year and find stuff that way. Yeah, it's really damaging. There are parts of the industry that are going to get hit hard by this and maybe bug bounty is just something that doesn't work anymore.

B (33:12)

Yeah. And I think the industry shakeup is still some time off, but that's because it takes time for these things to work themselves in fully to the enterprises. I think we're in for a big shock in terms of what's going to happen to us with AI. But I think that's. We think we're experiencing it now, and I don't think we are.

A (33:31)

I said at the outset that AppSec takes a really long time to change, and I think that's absolutely true. On the other hand, things seem to be changing faster with AI than other things in the past, so maybe. But I think a lot of the change has to do with people's mental models of how things are supposed to work and corporate culture and things like that. And that stuff's real hard to change.

B (33:58)

Yeah. Yeah. The hardest thing to change. Yeah. And. And one that defeats a lot of people. Be interesting to see. Jeff, this has been fantastic. Thank you so much for the conversation. I'm looking forward to talking to you again. I'm. I may get on to you with LinkedIn, actually, when I start reading some more of your posts. Thank you very much for coming through and having this chat with us.

A (34:19)

Appreciate it, Jim. Thanks. It was fun.

B (34:21)

Take care.

A (34:22)

All right. Bye. Bye.

B (34:23)

And that's our show. Love to hear what you thought. You can go to technewsday CA or dot com. Take your pick. You can use the Contact Us page or if you're watching us on YouTube, just leave a note under the video. Once again, we'd like to thank Meter for their support in bringing you this podcast. Meter delivers full stack networking infrastructure, wired, wireless and cellular to leading enterprises. Working with their partners, Meter designs, deploys and manages everything required to get performant, reliable and secure connectivity in a space. They design the hardware, the firmware, build the software, manage deployments and even run support. It's a single integrated solution that scales from branch offices to warehouses and large campuses to data centers. Book a demo@meter.com that's M E T E R.com CST I'm your host, Jim Love. David Shipley will be back on the news desk on Monday morning. Thanks for listening.