# AI Security Shifts: Defense, Debt, and Zero Trust

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-10-01

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host, Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
I'm your host, Tobi.
And my guest today is called Chris Weissopel.
And Chris was one of the first hacker group called Loft, a hacker collective in Boston.
And back in the days, the hackers used handles, I guess, like most hackers do that still, right?
And his handle was Weldpond.
I think if you look up on Wikipedia, you look up his name, you even find that there.
Also what Loft was doing.
So in 1998, Loft testified in front of the US Senate and famously said, Give us 30 minutes and we take down the internet.
Chris wrote Netcat?
Is that true?
Like you're the author of Netcat?
I wrote not the original.
I wrote the one for Windows.
I wanted to explore Windows networking, so I wrote one for Windows, but it wasn't the original, which was written for Unix.
Okay.
What do I do if I want to explore Windows networking?
Yes, I write a copy of Netcat or a clone of Netcat.
Sure.
Yeah, because you need to be able to do all the things Netcat can do to explore how ports work on Windows, right?
Okay.
Actually, I found quite a few security bugs with it.
Can you imagine?
would you find them still, if you would try again today?
Do you think with a proper agentic setup, you find security issues in Windows?
You have to remember, this was in the late 90s when the Windows networking stack was new.
And they had rewritten all the functionality, basically, of TCP IP sockets that Unix...
had written a decade before.
And so when you rewrite something, you come up with all these bugs.
Like one of the ones I found was you could bind as a user, not as a super user administrator, as a user, you could bind to a port that the super user was using.
Like say there was a mail server running on a machine.
You could bind to the same port and you would get the packets first.
obviously, you shouldn't be able to bind as a user to a port the super users using.
That makes sense.
That was because there was no real concept of users in Windows back in the days, right?
Exactly.
Like the different authorization levels, there was a lot of bugs, a lot of logic problems.
And so I found a lot of things like that that could be used to intercept data.
Cool, cool.
Yeah.
Happy to hear a few war stories today as well, like about the dark spaces on the internet.
But generally we wanted to talk about the idea of security first.
I think like if I look at also the companies that I was CTO on, like security was always an afterthought and you have that idea of secure on the first ride.
Happy to talk about that, but let's like...
Go back to the intro then.
Sorry to bloat the intro a bit.
You're also the founder of a company called Veracode, which you founded in 2006.
And it is mostly security scanning, right?
As far as I understood it?
Yeah, we have a suite of products that developers use while they're building their software.
for us to make sure by the time you're going to push it to production or ship it to your customer that you've done all the security testing you need to do.
Cool.
And to hopefully eliminate all the security bugs right before.
Hopefully.
And today you're the chief security evangelist of that company, right?
Yes.
And I guess you have...
looked at more insecure code than anyone else in the world potentially?
I think Veracode probably has.
We're in the trillions of lines of code because we do a high volume.
We have a couple thousand customers and some of them have hundreds and hundreds of applications each.
And so we've looked at a lot of software.
Maybe let's zoom out a little if you go back in time.
before the late 90s.
I don't know how old you are, sorry, no offense.
But when did you actually found that fascination for computers?
What's your personal nerd path?
Why are you a geek or nerd?
And what sparkled that interest?
Yeah, I was fascinated with technology as a kid.
My father was a, you'd call him a materials engineer today.
for General Electric aircraft engines.
So he built aircraft engines.
So I got a little bit of insight of how things work at a young age and how do you test things and understand how things work.
And so I think some of those stories that he would tell of coming back from the factory.
I think sunk in.
And even as a young child at like eight years old, I was taking apart the family telephone and trying to figure out how it worked.
It had a wire that came into the wall, and there was this ringer on it and buttons to dial.
And so I took it apart to look at it.
And then I realized that mom was coming home, and she probably wasn't going to be happy if the phone was taken apart.
I kind of just put the shell back on and said, maybe later I'll get to hooking the wires back up that I disconnected.
But that was sort of early fascination with how things work.
And then I was lucky enough to live near, we had these stores in the US called Radio Shack.
And Radio Shack was a place where you could buy radios, obviously, but other technology.
And they sold computers.
So I would ride my bike as a teenager to Radio Shack, and the manager of the store would let me use their computer.
So I would type in my own program.
Back then, they didn't even have floppy disks.
You recorded your program, saved your program on a cassette tape.
So I was able to take the program home.
after i was done go back another day and and work on it so that i had a really early experience with computers that i don't think a lot of other kids had um because i was doing it right when they were first available in the store and that's that's how i decided hey i i really want to um be a computer engineer um and i ended up going to college and getting a degree in computer engineering because I was really interested in programming them, but I was also interested in understanding how they physically worked.
And so I was fascinated because these things were right around me and I was able to take advantage of that.
Yeah, super cool.
And how did you step into the security world then?
I mean, that's like kind of a bit...
further away?
Did you get into gaming first or programming directly and then ultimately found out that programs have issues?
Or how did that work?
Yeah, so when you're sitting there with a PC computer, not on a network, and you can write programs and you can purchase programs and you can play simple games and use the word processor, it's an interesting tool.
But then the idea of getting a modem where you could connect out to other computers, and then other people connected to those computers, there was a whole world out there.
And so I was fascinated by that.
And so a few years after getting my computer, modems were inexpensive enough that I could get one.
and started exploring bulletin board systems, or BBSs for short.
And this was a precursor to the public internet.
I guess it's kind of like AOL.
You could dial up a service, and they would have forums where you could talk to people, you could download files.
And these were all individually run systems.
And some of these systems, they all had a specialty, right?
There were some that had gaming software, like legitimate.
shareware or freeware gaming software.
And then there were other ones that had pirated software on them.
There were ones that had forums that talked about different topics.
And I somehow was fascinated by the idea that there's knowledge out there that you're not supposed to have, right?
Like it's not in the libraries, there's no public.
place to have this, you know, some of this stuff was dangerous, like bomb-making files, right?
And as a sort of a college-age person, I was fascinated that there were these, or anarchy files, people would call them.
And you had that printed on paper partly in the school, or only on the mailbox?
No, no, I just kept it, you know, reading it online, you know, downloading the files.
And looking around, and I never made a bomber.
I never used the information that way.
But I did find that there was hacking information.
And I learned about the world of hacking through these websites that had sort of the dark side of information.
And met people that were creating this information, exploring technology, and then writing it down and uploading these files.
And so they explained things like default passwords.
Like when you log into a system, try these default passwords, right?
Default usernames.
They would document things like this is what the screen looks like when you connect to a telephone company's computer, like here in, you know.
AT&T would have these computers called Cosmos.
And you would say, oh, here's the prompt for Cosmos, and here are some default passwords.
So it was really early days of exploring how to hack different systems, and all this information was out there.
And so I was fascinated by it.
And then eventually I started to get to know the people that were creating these files.
And then I did my own exploring myself and shared information.
And that was the old hacker saying, information wants to be free.
There was a whole sharing culture of information.
It's like, you share some stuff, I'll share some stuff.
We'll all get smarter.
And that led me into the, I'm going to call it the hacker community.
We didn't call it cybersecurity until much later.
And that community in a way is still similar, right?
Like there's still this culture of sharing on conferences, which are like partly not very commercial.
Like I come from Germany, so we have CCC here and the yearly CCC gathering, which is always like a different world, right?
Really like doesn't feel like a commercial planet, but more like a different planet.
So this is still the case, right?
Yes, DEF CON started back in 92, and I think I went to my first one in 96.
So like DEF CON 4, I think they're on, I think it's DEF CON 34 now.
So it's, and it's been growing, you know, it was first a few hundred people.
When I first started going, it was a couple thousand people.
And now you have 25,000 people.
So it's grown quite large.
And it's still mostly the same.
It's mostly about people sharing their ideas, presenting, coming and just bringing their cool stuff that they've built and sharing it with people and taking part in hacking activities like Capture the Flag.
That's been going on for almost 30 years now.
People will practice how to hack into stuff and how to defend stuff and make a game out of it.
So it is quite a big, huge sharing culture of information.
And the cybersecurity world, the professional cybersecurity world, really grew out of that culture.
There's less Mohawks and anarchy.
But the basic ideas of sharing information, sharing tools, getting an understanding of weaknesses through people sharing information is still part of the culture of cybersecurity.
Did you at a certain point turn into a person which is now seen as very commercial by them?
Or are you still part of that culture in a way?
Yeah, I think you span both the cultures.
Most people...
who are in that hacking culture, I would say, have some relationship with working in technology.
And some of those people are actually cybersecurity practitioners.
But when that first happened back, I would say around 2000, that was when I had my first security consulting job.
And there was a lot of people in the community that, you know, they called us sellouts, right?
Because We're not exploring anymore and sharing our information.
We're using those skills to help an organization secure itself, right?
Like consultants working for a bank, helping the bank make its online banking secure, right?
The idea that you would find vulnerabilities and give them to the people who owned the technology to some was sort of anathema to the hacking.
It's like, no, you should be sharing that with everybody, right?
And so, you know, I think that the culture, the hacking culture kind of changed when there was this huge need for cybersecurity professionals because everyone was going online, you know, after 2000.
And every company was going online.
There were whole companies that their whole purpose was being online.
And they needed...
The technology just is not secure out of the box, right?
We all know that.
There's lots of pitfalls when you're building something with software and everyone, and you're building networks and systems.
So every organization needed cybersecurity people.
So there was a huge demand for people from the hacking community to go and use their skills to help organizations secure themselves.
Okay.
And before we talk about today, What's the story behind the 30 minutes to take down the internet in 1998?
Tell us.
Yeah, so that basically was a good way for us to say how the infrastructure of the internet itself was insecure.
This happened to be one type of vulnerability.
which is how different networks talk to each other.
Like, you know, internet means a network of networks, right?
So you connect your company or organization's network to an ISP and your network can route over the internet.
And the way that this works is a protocol called Border Gateway Protocol or BGP.
And it's one of the foundational internet protocols.
And at the Loft, we did research on this protocol and found that it didn't have authentication, and you could spoof the routing commands.
So you could tell a router the wrong information, right?
So if you tell enough of the core routers of the internet the wrong information, then nothing gets routed properly and essentially the internet breaks.
And so we found a way to do this.
We tested it on a small network.
We just put a few routers together and tested it.
We didn't try to take down the internet.
And we used that as an example of a fundamental flaw which could take down the internet.
Now, there's other fundamental flaws in things like DNS, that have been fixed over time.
There was one very famous about 15 years ago that Dan Kaminsky discovered, and he said the same thing.
He said, if this wasn't patched correctly, it would take the internet down, and we'd all have no way to look up where we are going on the internet when we type in our URLs to go somewhere.
So these things, some of them get fixed over time.
The BGP problem is still there.
um there is a secure bgp but uh it's not really hasn't been adopted it actually came out a few years after we spoke at the senate and uh and uh but it it puts overhead on on the internet and people don't want to use it but so you know just to get back to the 30 minutes to take down the internet that became sort of the sound bite of the hearing like hackers came to the to the senate and told them told the Senate we could take down the internet in 30 minutes, became a way to crystallize what we were talking about into one statement.
I guess that's what a soundbite is.
And it ended up being very good because it got the point across.
Moving forward slightly, how do you see the difference as of today?
How does it feel to be alive as a security professional these days?
in comparison and do you sometimes think that this is too much right like i mean looking at lms and the the the amount of issues that you can find with a good setup and the amount of of money you have to put into defense now because i think it like slightly changed the weights right a while ago it was expensive to attack someone and now it's gotten more expensive to defend your own premise, right?
How does that feel today and what do you think are we doing wrong or what do you think how the world has to change to adopt?
Yeah, so things are sort of infinitely more complex now than they were 25 years ago.
We just keep building more and more complex systems.
And we have containers, and then we have virtual hosts, and then we have virtual networks within a cloud environment.
And we're able to just build these huge, complicated systems, all software-defined.
And so at the end of the day, it's mostly a software problem.
And the software itself has, you know, that you pull off the shelf or you download has security bugs in them.
And as you build software, you are going to be creating software with security bugs in them.
It's these languages that we use have by sort of by default, unless you're taking extra care.
have have a set of classes of vulnerabilities that are that are just bound to show up you know some languages have solved some of the problems like memory memory safe languages managed memory languages like java or python or rust don't have the kind of memory corruption issues that you know c the c language has unfortunately a huge amount of software as was written in the c language uh before we we we had alternatives maybe starting 10 15 years ago um so but that's just one class of vulnerability you know there you know you could write a java program and you're going to have a whole nother also other class of vulnerability so uh building software is is a complex challenge and, and you're always going to have vulnerabilities in that software.
So that's why, uh, assessing that software, testing it through lots of different techniques, um, before you let an attacker, uh, you know, get at that software before you put sensitive data in that software and, you know, let it, let, let, let the internet touch it.
Um, and that's been the model that, that, uh, you know, we've done it at Veracode and how, Most companies have been building their software where they care about security or they're required to care about security, like in a regulated industry like finance or healthcare.
Of course, big brands care about security and everyone that's doing something that needs to be online to make money cares about their systems being up and not taken down.
That's sort of the world we're in.
And now, as you said, AI has come along and entered this world where there's attackers trying to steal data, encrypt data, and ransom it.
Ransom, or they're going to shut down your systems, or they're just going to steal your secrets.
The attackers have always been able to do that throughout the history of software.
And a lot of what we talk about is how do we change the incentives to change the economics of things to make it cheaper to build secure systems and more expensive to attack systems.
And, you know, I think that's what you were alluding to with the coming of AI.
AI drops the skill level immensely to be an attacker, actually to be a sophisticated attacker.
It's already, you could be an unsophisticated attacker already with a low skill level, but the sophistication of an attack is no longer something that tells you anything about the attacker, right?
It used to be.
oh, this is very sophisticated.
They have their own custom exploits here.
They have their own custom implants.
This must be a nation state attacker.
We don't see this toolkit out on the dark web.
It's a nation state attacker.
Well, we don't know that anymore because the LLMs can build sophisticated exploits and sophisticated software that attackers would use.
So that's definitely one of the big changes.
But the other one, the other big...
So that's a cost issue, right?
Sophisticated attackers are going to charge more than what we call them script kitties, people that just know how to download and run tools.
But also, there's that factor, which is more on the expense side, that has gone down.
But there's also the speed factor.
The speed factor where if someone...
gets into a network, they can really quickly traverse that network, find where all the crown jewels are, and encrypt them or take them.
So it's both cost and speed.
And that is currently now, I would say, has a chance of aiding the attackers.
But I think that's only if the defense doesn't pick up.
pick up the ball themselves and uses the same technology to make it so that it's cheaper to secure, it's quicker to secure.
And this has been the trend over cybersecurity for a really long time.
When a new class of tools comes out, if attackers are using that class of tools, they're going to have an advantage, like, say, fuzzers.
Fuzzers came out about 20 years ago.
And it allowed attackers to find vulnerabilities that they couldn't find before just using, say, static analysis or code review.
And this fuzzing found new bugs that defenders couldn't find unless they were using fuzzers themselves, right?
So we've had these cycles of new tools have come out, offense has used them, and then eventually defense starts using them and we get sort of parity again.
So I think when we talk about AI, the same thing is going to happen.
If defense has the same access to the same tools, like the same models, and they have the ability to use them to do all the things attackers would do to their software, to their networks, but they get the information about what the problems are, and they fix those problems, I think we don't have a doomsday.
cyber scenario.
We will have a doomsday cyber scenario if there are large pockets of people who are controlling technology that don't use AI for defense.
Now, AI for defense shouldn't replace all the other things you're already doing for defense.
It's an additional factor.
Like when fuzzers came out, we still did code review.
We still did static analysis.
We didn't say because some of the older tools can find things that the newer tools can't find.
And we find that AIs actually are not good at finding particular classes of vulnerability or it's just too expensive to use them to find those classes of vulnerability.
So you keep using the traditional tools to use that.
But the thing that has everyone freaked out a little bit is how good AI is at finding vulnerabilities that the traditional tools struggle or can't find.
Things like authorization issues and business logic issues, which the traditional tools can't really find, and people would have to do manual code review with experts.
That's very expensive and time-consuming.
And here we have AI doing that very quickly.
So clearly, defense has to adopt these tools.
But I don't really see the doomsday scenario, especially if the people who are running the critical applications, critical environments, critical infrastructure are jumping on this.
And that's part of the plan of some of these frontier labs is to, through projects like Daybreak and… I'm sure OpenAI has one too, to get these tools in the hands of the critical places.
But they're going to have to get everywhere eventually.
So you're not scared that AI will destroy us in three years?
No, no, I'm not.
And it's because I think we have incentives to secure our infrastructure, right?
AWS has an incentive to secure their infrastructure.
Google does too.
The big banks have an incentive to secure their infrastructure.
They don't want criminals shutting them down or stealing funds.
So the places that traditionally do cybersecurity well will do it well.
I guess I worry about places that traditionally have not done cybersecurity well because they're underfunded, right?
So we see that in schools and local governments and hospitals.
And unfortunately, a lot of utilities.
We're seeing it in the water supply here in the U.S.
has not funded cybersecurity to the level that they do.
So where underfunded places meet critical risk, we need to do something extra in those places.
I'm not worried about...
you know, the big internet companies and the banks.
I'm worried about sort of the smaller organizations that we all rely on.
And that's where I think government has to come in and some of these frontier companies have to come in and help.
And I think they are starting to do that.
I think one could also say, at least from my very simplified perspective, that it's also a chance.
If you had no CISO, and you had no security expert in the company and you were yourself not like too deep into it, then it was always like the afterthought of an afterthought, right?
And now, I mean, it is, I would say everyone, every CTOs, every engineering leads, every engineer's responsibility to take security for granted and to like take it seriously.
And with LLMs, you maybe have better approach to that straight away, right?
Even if you're not an expert.
Yes, security has to be part of the building process.
Sure, we can have protection after the fact too and detection after the fact too.
You know, those are necessary, but nothing is more important than having security be part of that building process.
So the architects and the engineers that are actually doing the building have to use tools that can either, you know, build things securely the first time, you know, that's never going to be perfect, right?
But we can improve there.
But then once something is built, before it's a risk, right?
Before it's put into production or shipped to customers, we're going to find the vulnerabilities that would be found if we didn't fix it now.
And we just push that out there and connect it to the internet.
So let's find those things now and fix them and not let them get exposed to potentially an AI-enabled attacker, a swarm of agents that an attacker is controlling.
We want to find the vulnerabilities.
As the builders, we have additional information, right?
We know what the design and architecture is.
We have the source code.
We can feed that into the LLM and say, you know, this is the context of a vulnerability or a context of, you know, a bug.
And it'll help it understand what is a risk and what actually needs to be fixed.
And then in a perfect world, uh the the llm would be able to create create a patch that would then that would then fix it um you know there's there's nothing is perfect right uh we're evolving towards that kind of solution but i can tell you now that there's been studies out there that say um you know ais are writing code that's vulnerable um when they're asked to fix the code that's vulnerable their patches fail you know 50 45, 50% of the time.
So I think we can eventually get there, but we're certainly not there today.
It's still early days for AI helping us build secure software, but I'm very hopeful that we're going to get better at it.
And AI is also abusing issues that we don't know about or know about, right?
Like one anecdote, I recently, I mean, acquiring companies and i recently like been in talks with um a company uh preparing the due diligence sometimes i now send over prompts uh that they can execute on their their end to kind of um like give me a first bit of like taste um first bite and and there my um clawed dynamic workflow actually accidentally found a publicly accessible Kubernetes cluster that you could just connect to without me really understanding and them really knowing about that.
And so the due diligence or this first prompt that I sent over then ultimately helped them fix that issue.
I mean, if it takes a company name to find such an issue, isn't that like… super crazy?
Isn't there so much to come in the next months that we are not aware of?
Or is it just like the normal leveling up phase that you have experienced with other technological shifts in the last decades?
Yes.
So I think that as we're adding the AI technology to our to the infrastructure where we're using it on a daily basis, you know, on our personal computers, on our mobile devices, but more importantly on sort of the enterprise infrastructure, like developers are using AI agents and plugins and MCPs that are able to have the LLM call out to an API.
All these things are creating a massive new amount of attack surface.
All of these things can have bugs in them, security bugs.
So the agents can have them, the plugins can have them, the MCPs can have them, they can leak credentials is a big one.
And you mentioned prompt injection, anything that eventually sends a prompt to an LLM is potentially having.
prompt injection, which is a very difficult problem to solve.
An unsolvable problem in a way, right?
As long as it stays like that.
Yeah, some people would say it's unsolvable.
So you never want to allow an attacker to actually choose what data eventually gets sent to the LLM.
And you want to design systems that do that.
Now, that's very hard if your system is like a customer support system that has a a chat interface.
It's easier if some of the ways we're using it where you want to click on a line of code and say that has a security bug on it and say, you need to fix this.
It's a little easier to constrain and control environments where you don't get to You don't get to send free text, but things that read email, they read calendar entries, they go out on the internet and they read information and process it.
That's where you have some real prompt injection issues.
And would you just not use it yourself?
Or where do you draw the line?
Yeah, so I don't think a lot of these tools are ready.
I don't necessarily have AI reading my email or handling my calendar for me.
But I think the place where prompt injection becomes a problem is really when the LM is able to take some sort of actions, and then you have to give it permission to do those things.
Like say you give Claude CLI command line access to your PC, we've heard cases where, oh no, it decided to delete my repo, right?
Because we gave it command line.
So you have to be very careful where you're connecting something where an attacker could prompt inject you to something that has...
those higher level permissions.
If it doesn't have permission to do anything except maybe display text to you, then maybe the prompt injection can trick you into understanding something wrong.
But that's not nearly as bad as prompt injecting into something which has the ability to delete files or change configuration.
So that's a big attack vector.
And that's why anyone who's using MCPs or agents really has to worry about, is prompt injection a possibility for the system I'm building?
So minus-miners dangerously skip permissions is not on your whitelist of parameters to use for Cloud or so.
Yeah, I mean, so we have to...
When we're designing these systems, you're designing a system that you'll definitely have vulnerabilities in them.
And prompt injection is one of them, one of the newer classes.
But all the old classes are still there.
And so we need to build these systems where there's compartmentalized identity, things that only have permissions to do exactly what they need to do, least privilege.
This has been around forever in security.
Now it's more important than ever.
And these permissions are short-lived, right?
They're created just for the particular task.
And then segmentation of things like data and segmentation of networking.
So one vulnerability doesn't become take over the whole environment.
The vulnerable code that's compromised can only do a very limited set of things.
It's not going to...
absolutely stop every vulnerability.
But in many cases, it can stop every exploit, but in many cases, it can.
So, you know, then these are the things that, you know, have always been techniques, you know, we call it zero trust, right, for building out infrastructure where applications would run.
You know, some organizations have gone down that path, but I think a lot more organizations have to go down that path.
I was at a conference in Washington, D.C.
last week, and the CIO, I'm sorry, the CISO of the U.S.
federal government was doing a fireside chat and said, you know, when we talked about zero trust a few years ago, and it kind of...
It kind of went away.
People stopped talking about it.
People stopped building it.
Now you really have to build it.
So the ideas are correct.
And now AI might be that incentive for people to build more of this defensive capability.
Or what actually helps you to implement it.
I think with Zero Trust, the issue is that for many organizations, it's just...
in the way, right?
It's just like slightly too complex to introduce it on the go.
Maybe there is some sort of a middle ground to at least like introduce zero trust wherever you really, really need it, wherever shit could really hit the fan, right?
I heard there's a concept called minimum viable zero trust now, which kind of tries to like...
disarm it slightly so that becomes more realistic to some organizations.
And maybe that's the issue with the first version of the concept, that it's kind of too drastic for many organizations, right?
Yes, it definitely takes work and expertise to do.
And as you say, there is some friction there because you change the functionality of the system and now this...
you know, this agent or this service needs to go and do something with another service.
Oh, well, now I have to change my identity.
Now I have to change my network segmenting.
And, you know, there's, you know, some approaches to, you know, try to automate that.
I think if something's important, we'll figure out how to do it faster and cheaper over time.
Just like, you know.
managing firewalls, you're typically not logging into each one and typing into the configuration file anymore.
So that was sort of the original network segmentation was the firewall.
And so I think it can improve over time and we can get better at it if there's an incentive to use it.
And I think when people will get compromised, there's an incentive to build more protection afterwards.
That's a very pragmatic view.
And then maybe slightly pans down, if you were me, I acquire B2B SaaS companies and it's all different stacks, different technologies, different languages.
And yes, obviously, we do security checks obviously we like do audits etc but if you were me like and uh you had like a blank piece of paper you would acquire b2b sas companies uh like between like let's say 1 million and 5 million in ar and revenue yearly um what would you do to those companies to not kill them straight away when you acquired them like hey this is the the the the top 100 list of things you have to fix.
What would be your pragmatic approach to that?
So I would say every startup company that's a SaaS company, when they get purchased, they have their first liquidity event, at that time, I'm sure there's a huge amount of technical debt.
And so part of that due diligence, the buyer, is trying to understand how much is...
how much risk is there in this technical debt?
And what do I actually really need to fix over time?
What do I want them to fix before the deal closes?
What am I going to plan to fix afterwards and budget that in?
I hear the analogy, it's like buying a house all the time.
You get your home inspection and some things you're like, I'm not buying this unless you fix this because it needs to be fixed on day one.
And other things, oh, the roof only has two years left on it.
I just have to...
take something off the price because I'm going to have to budget for that.
And we can think about that technical debt.
Also, there's security debt is a flavor of technical debt.
So you want to look at what processes does the company have in place to remove risk in the systems and software they're building.
before they put it into production?
And do they have those systems in place?
Do they work well?
And what was their risk tolerance, right?
Like what we call that security debt, right?
Like what did they decide they found?
They saw that there was risk, but they decided they didn't need to fix it.
And so you need to get an understanding of that.
And then I know what we do at Veracode, when we purchase a company, we can't put the Veracode name on this and hook this up with this amount of risk in it.
So you need to fix these things before acquisition, and then we'll plan to fix things later.
But one of the most important things is understanding what security processes they have for building and deploying their software.
Right.
So, so, so what, what are they testing?
What are they fixing?
How does their identity work?
How do the services in their environment work that an application uses?
How are those, how are those secured?
And you need to, you really need to get an assessment of all that.
Sure.
Sure.
I mean, that's what we do obviously, but like taking a step back, I mean, you see so many.
secure and insecure setups and I think there must be like this shortlist on your mind of like the like five dramatic things that like everyone should do and no one really does like simple best practice that like where people are too lazy people are too comfortable or however you want to want to spin it like I don't know I think like credentials and code, stuff like that, right?
Like what is from your perspective still around, even though it shouldn't be?
Yeah, so I think that when a company is smaller, they're pre-revenue, maybe they don't even have hired the security people.
You're going to be taking on security debt, right?
And this is just the classic.
case because if you don't ship a product if you don't get some revenue if you don't get some customers then you don't have a company um and and you're never gonna you know move forward so i i think that most organizations when they start out are are not caring that much um about about security and you're gonna get like a lot of these uh basic problems um that that are put in the software And then if someone is acquired, now you're tacking that technology onto potentially a bigger brand name.
There's plans to raise revenue, increase revenue, get bigger customers, get more customers.
Those bigger customers.
probably want to look at your security posture, right?
If their data is going into you or you're going to become a critical part of a transactional process that they're doing.
And so I tell startup SaaS companies what they need to do is it's okay to not be super rigorous on security in the beginning.
Like it's okay to go fast and not be as rigorous.
But at some point you're going to need to do that.
And the tricky part is understanding when you need to sort of work on those processes.
The CFO is like, we're going to burn money, burn money, burn money.
But at some point, if we want to IPO or get acquired, we have to work towards profitability.
We have to have a plan to get to profitability, whether that's like cutting costs or increasing revenue.
Usually it's both.
We have a plan.
to do that and so i tell security leaders you get you're going to have to do that same thing when you transition from startup to you know becoming an enterprise with with uh sophisticated uh customers that that that that care about the security of the data that you you have but but still like a few like concrete like best practices that you do find all over the place um i mean yes implementing security also like security on first write that you propose, right?
Like, it makes sense, but like, just some things, some bytes that you always find?
Yeah, so, I mean, you want to use a language to start off with that does not have memory corruption issues in it, unless you absolutely have to for some sort of high-performance reason and you can't use Rust.
Don't use C.
So that's a concrete one.
Most enterprises writing software don't use C anymore.
It's really only used for operating systems and critical performance these days.
But of course, there's a lot of legacy code.
But if you can help it, don't use C.
You're undoubtedly going to be using open source packages as you build your software.
That's how we build software today.
don't have a free-for-all where every developer can just pull down any package and include it in there.
You want to manage the security of your open source risk that's coming through the packages that you're installing.
So you need a process to know what packages you're using in each application, what versions they are, what's the known risk in those packages.
And with the rise of malicious malicious code being embedded in these packages, I would recommend what people are calling a package firewall, something that actually inspects the package before it gets downloaded onto a developer's machine and runs.
Because sometimes that first run is going to install malware if there's a malicious package.
So you need to have a way to manage your packages.
That's a big one.
And then you need a way to inspect the code as it's written.
It's something that before a developer checks in some code, does a pull request, adds it to the main branch, you need a process that says, okay, let's inspect this first as part of the program.
We'll do a whole program analysis and see what new risk is showing up there.
So we call that shifting left for security and shifting left for application security.
And since we've been continuously building faster and faster and faster, first with Agile, then with DevOps, and now with agentic coding, we're just going at lightning speed.
So we need to actually do the testing.
security testing, security analysis is close to after that code was written.
So I would recommend doing things like static analysis and people are now calling it AI SAST, right?
So having an agent look at the code that you just wrote and hopefully with as much context as it can get.
So feed the code in, but also feed the context of you know, this is a, you know, this is a, a date, a database application.
It's, it's managing customer records.
This is the architecture.
These are the components it's using.
These are the identities that, that the application has.
This is the design documentation so that it can find things in that code, like authorization issues, business logic issues.
It needs to have that.
To find those types of things, it needs to have that context.
And that's the real benefit of people calling it AI SaaS, right?
Because you're statically looking at the code, you're not running it.
So I think those are a few of the concrete things that I think everyone should be doing.
So that's literally what you mean when you say secure on first write, right?
That you basically have a library of skills or...
plugins or whatever, like running locally that even before you commit or the agent commits, like whenever you imagine like you're doing like agentic coding or vibe coding and you run that whenever you change something basically, right?
You run a review process which even runs locally instead of in a pull request or in some cloud or how do you imagine that?
Or what is your best practice personally?
I guess you also...
every once in a while, wipe code something or so?
Sure, sure.
So, well, I think the very earliest you can do is give the, if your code is being written by an LLM, give security intent to the LLM.
So give it context and give it security intent because What we found with our testing at Veracode is if you don't give it any security intent, it often writes vulnerable code, you know, as, you know, basically as bad as a human developer.
And, you know, that makes sense, right?
It learned how to code by reading code that human developers wrote.
All human developers are not trained in secure code.
They don't know to not make these mistakes.
They just are ignorant of it, right?
So if we can think about it, a lot of the code that was written that's out there in open source was written without security intent.
And the LLMs learned from that.
But we can fix that now by giving them security intent when we ask them to write the code.
It's not going to write.
perfectly secure code, but it will help.
And just like training a developer, giving them a secure coding class and giving them tools where they can easily look up how to do things in a secure way, helps get secure code written.
That's not the standard in the industry.
A lot of developers have never taken secure code training, but we can sort of fix that problem with generative AI-created code.
by giving context and security intent before, while we're saying, I need you to write a routine that will do this to my database.
And then after that code is written, then we want to do that testing before we do our merge and make it.
make it something that will eventually get to production.
So instead of only ending your prompts with make no mistakes, also make it secure, make no mistakes.
Yeah, and you can't just say make it secure.
You know, it's too generic, right?
So you want to say maybe have a skill file for the particular language and framework you're using, saying, and you know, you can...
get a lot of this information up on like OWASP's website.
You know, if I'm using Java and I'm using the Spring framework, these are the things that I should look out for.
And these are the ways I should write particular constructs like interacting with the database so that I don't get SQL injection, et cetera.
And that, you know, you need something more rigorous than just make it.
make it secure.
I was just joking.
But sometimes it just works to ask again, like, how would you prompt yourself to make the application of this purpose secure?
And what would you advise me to do?
And then, like, spend some time in planning, etc.
again.
And then you'll have an almost perfect prompt written by an LLM for an LLM, which is absurd in a way.
or works to a certain level, right?
Yeah, I mean, it's getting us in the right direction, right?
It's an improvement.
None of this is going to be perfect.
It's always belts and suspenders here in security worlds, right?
But each of these processes gets us closer to where we want to be.
So we're finding less vulnerabilities in the code that then we need to patch because every time you...
change code to fix something, now you have another process which could break the code or be incorrect that you then need to verify that that's correct.
So getting it right out of the box is the best.
But if we can't do that and we know it's not perfect, we're going to have to test and patch and retest.
And it's really the only solution we have right now.
So what do you think, how will engineering look like in two years from now?
Like, I mean, it's right now, like going through a massive shift.
Do you think that like every company will have to have like a security expert?
Even if you're a smaller company, will engineers ultimately turn into security experts?
Because the biggest task you have at hand is to make applications secure ultimately instead of like...
reading code necessarily?
I don't know if that will still be a thing in a few years.
How do you imagine that world to be?
Yeah, so I think that the engineers are moving more to not writing code, but more working at the design level, the architecture level, understanding how to guide the generative AI to actually write the code.
um so sort of moving up to you know the engineers are becoming architects um i i guess giving the giving the intent uh to the people that are i'm sorry the the machines that are that are that are writing the code just like maybe an architect would would do and a product manager would do to to a junior junior engineer uh so i think that's still that's still important uh i mean that that's that's going to be the the job, but we're going to need security people to make sure that this process has the right checks and balances in there to make sure that the right security intent is being put in at the right time, the right security assessments are being done at the right time, and then there's that verification that's happening.
But these security people aren't going to necessarily be reading the code.
There are more going to be people that are governing the tooling that is going to be doing it.
So everyone sort of up-levels themselves to up higher in the work chain, more towards management and governance than actually doing the grunt work.
And I really think that that's how it's going to evolve.
And also, I think we're going to, you know, we're going to, a lot of people say we're going to need less people with this new model.
And, you know, I disagree with that.
I think maybe we need less junior people.
And that might be a problem for entry level jobs.
But I think what happens is, you know, we just end up writing more software, right?
So we're going to write as much software as we can with the capabilities that are out there.
with the people that we have to do the design, architecture, product management, and govern the security processes that are used.
I guess there's really an infinite demand for software if you look at the world out there, right?
Even if you look at cars, everything is software-defined these days.
And I think if you think further, then it's even possible to define more with software and now less.
And it's also quite practical if you have the people that can maintain it and can operate it, right?
Yeah, it does seem like there is an insatiable demand for more software.
It's not like food, right?
You can only eat so much and then you're satisfied.
It seems like software can allow us to do things that we just couldn't do before, right?
Think about in science, right?
You can do the experiments and explore things that you could never do before.
So there's always, if there's a demand to...
you know, have medical breakthroughs or scientific breakthroughs, it's like the sky's the limit, right?
We could just have more and more better software that can handle more and more different tasks there.
And, you know, of course, in the consumer world, everyone wants everything to be at their fingertips as convenient as possible, and everything's already thought of, and infinite choices, infinite customization.
So I don't see that.
I don't see that.
changing.
And so I don't know if I subscribe to the fact that software companies are going to go away because everyone's going to be able to vibe code their own thing and there's going to be all this free software out there.
It's like most people just want a user interface, right?
And someone else built something behind, they built that user interface and something behind that user interface.
or when user interfaces go away and it's all agentic, I don't see a lot of people writing their own agents.
So I think we're still going to have software companies and it's just going to change how they do their work and what they do.
And how deep AI is integrated in there, etc.
There's a lot to learn still.
Yes.
So Chris, I still...
Slowly coming to the end, or quickly coming to the end, I still have a little surprise for you.
So I was actually digging in your GitHub profile, and I found this old NETCAT software that you wrote for Windows to understand the stack.
And you were always into also slightly bending reality back in the day, so what is possible.
And as far as I saw, there's like a little...
feature in it that almost no one ever discovered beforehand, which is called a time machine feature.
So it's minus T.
So you can actually call your old netcat minus T and then you give it a year and then if you run it, it brings you back to that year that you just stated in your own life.
And imagine we would now run it and we would now give it the year 1998.
And we are now back in Boston in the loft a few days before you all fly to Washington to testify in front of the Senate.
And you now can watch like young Welpond for a while and you get...
the chance to whisper something into your younger self's ears, what would you whisper?
I think that what I would have whispered back then was, you need to think about how to solve these problems instead of just being a critic or someone who is pointing out problems.
someone who is educating people about problems.
When you do that, really think about what is the solution that you would like to see at the same time.
And it kind of took me many years to make a transition from someone who is just a breaker.
Someone who can figure out how to break things to someone who's a builder who can build solutions that either the things don't break or we can fix it.
And so that probably took me about another eight years until I founded Veracode.
I kind of went through this process of being a software consultant, going in and pen testing and breaking systems.
But then later I kind of had an epiphany when we actually, so around five years after that Senate testimony, I got hired as part of being a consultant by Microsoft to help them secure the first product that was going to go through a secure development lifecycle.
And here I was with a team of breakers and we had to figure out, well, what should the developers actually be doing so we can't break the software and had to come up with that process then.
And so I wish I came in 98 and said, this is what people should start thinking about.
And being that.
being a builder.
So, you know, that's how I started my career.
I was a software engineer.
That's how I started my career.
And then I started to become a hobbyist, breaking things.
And it took me a while to come back to being a software engineer and saying, well, let me put my, you know, engineering hat on and say, how can we improve this process that we're using as builders to fix these issues?
I think it's absolutely critical that the people building systems think about security as a property of the system that they're building and that they have the tools and capabilities to do that.
So it took me a while to get there.
And if I was able to whisper in my ear in 98, maybe I'd get there sooner and maybe some security companies would have been founded sooner.
Maybe we are already a few years ahead securing things than we are now in 26.
Who knows?
Yeah, very good learning.
So don't just only complain, but also help people to fix it.
It's a very, very valuable learning.
And I can imagine that sometimes this could save a few years.
of learning it the hard way, right?
Exactly.
Thanks a lot, Chris.
It was really nice talking to you and really like value the discussion.
A lot of like very pragmatic ways of looking at the world that you have there.
But I guess you have to be that pragmatic if you see so many.
so many issues day and night right um at a certain point you just be pragmatic right absolutely figure out you know what risk you can tolerate and figure out what are the problems that you need to get to that level and fix them and then figure out a process that can keep you at that level of risk tolerance like so that it's not a fire drill uh and and and and and a rush that they can just keep you at that level.
Like a company would be maintaining manufacturing quality, right?
Like if something goes wrong, diagnose the problem, improve the process so it doesn't happen again.
And taking so, I started off talking a little bit about my father being an engineer building jet engines.
Obviously, quality was important there.
And I think I you know, I learned about quality in a process.
So same thing you can think of when you talk about security, that that's a property of a system that you can make happen.
So fix it once and then build the processes around it and never let it happen again, right?
That's how I see that.
Yes.
Thanks a lot, Chris.
Thank you.
Thank you for having me on your podcast.
Hope to see you soon.
Bye-bye.
Bye-bye.
Thank you for listening to the Alphalist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or, as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.