How AI Enables Continuous Penetration Testing

Hey guys, Thanks We Throw. We're here with Mark Kerr, the CTO for Synak, and we're talking-- Let me try that again. Is it Synapse?

What the heck is it? Synak. Synak.

All right. One more time. Yeah.

Sure. Hey guys, Thanks We Throw. We're here with Mark Kerr, who's the CTO for Synak, and we're having a little chat about, well, what is happening as the rate of software delivery accelerates in the age of AI and our ability to actually keep pace with testing it because, well, maybe the delivery cycle is far exceeding our current pace, and hopefully AI might help us one day, but right now, there seems to be an imbalance in the force.

Mark, welcome to the show. Hi, Mike. Thanks for having me.

Good to be here. So what is your assessment of what's going on here? We've been struggling with DevSecOps for as long as I can remember, and it doesn't seem like it's getting any better in the age of AI because, well, we're generating more code than ever.

I'm not sure how much of it winds up in production environments just yet, but it seems like we're stressing our existing processes for penetration testing and everything that goes associated with that. How is this going to play out? Well, you're absolutely right.

AI models have gotten really good at writing software. On the software engineering benchmarks, these latest models from OpenAI and Anthropic are scoring really, really well. And they're able to write really great code, and a lot of people are moving a lot of their engineering workflows to be agent first, where the agent takes a stab at a feature before an engineer even looks at it.

And now the engineers are moving to more of a review-type role, where they're reviewing what the agent did and sometimes reviewing several sub-agents that are working together to develop out a feature. So, we're pushing a lot of code out the door, and this is going to put pressure on the security ecosystem around application security, specifically. And so, we're proposing that people move to more of a continuous model for penetration testing, and if AI's going to write the code, we need AI to assess the code and also assess the running application and do dynamic penetration testing as part of the release process.

And this was really the missing piece of DevSecOps. We relied upon static scans and dynamic scans with DevSecOps, but it never really got to the point of being on par with a human operator. And so some of these latest models with agentic pen testing and harnesses that mimic what a human pen tester would do, you're getting really, really close.

I'm not saying it's full replacement yet, but it's definitely moving in the right direction. And if we have the ability to run agents in a penetration testing mode against all these changes, it'll help us be more secure overall and maybe help us realize that dream that DevSecOps was supposed to be so many years ago. I feel like there was always a gap, and the gap existed, to your point, because as I deployed the software, I could only really reasonably run the penetration testing, I don't know, a couple of times a year maybe, if I was lucky.

And so between when the test ran the last time and the current time, there was maybe a million changes to the code base, and that would create all kinds of opportunities for mayhem from the bad guys to go in there and find some new vulnerability. So to your point, are we reasonably getting to the point where it's cost-effective to continuously run penetration testing throughout the SDL life cycle, or how often should I run it? Yeah, it's getting to that point.

Where we went wrong is we had a human in the loop for some of this. In the DevSecOps vision, it was you're moving code fast through the development and production pipelines, and then at the end, you'd wait for a human pen tester to show up and assess those changes. And you can only do that so many times a year, and it gets very, very expensive to employ consultants or internal pen testers to do that.

So where AI's going to fit in is being that agentic pen tester at the end of the pipeline, where it can assess those changes in the running production code area. So if you're deploying it to Google Cloud or Amazon, it can plug right in and assess the running application there, and also act kind of like the QA researcher in a way and start walking through the flow. So I think you're going to see this merging of QA and security as well.

And then it is getting to the point where more data centers are going to get built, energy is going to get cheaper, all of this, the price of tokens is going to come down over time. We're also seeing a boon in open-source models that are quite capable of reasoning and doing security workflows, too. And then at that point, you're just paying for compute.

So I think we're going to see the prices come down dramatically, and you'll get to a place where this is easily affordable on a continuous model, but also highly effective. And then we've got to make the decision of what is the role of the human at that stage. And this comparison study of agents versus humans is still a new field, and we're assessing that every day as we compare our agentic pen tester to human performance in our red team.

It's coming a long way, but it's not at full replacement yet. Do you think ultimately the quality and the security of the applications we're deploying, therefore, will improve versus when we just relied on humans to drive DevSecOps? And if I'm not mistaken, for every one DevSecOps person, there's probably 50 developers.

So the odds were stacked against them from the get-go. In theory, it should improve security overall, right? If we're having agents that they don't sleep, they just look at every change, they're assessing the integration of the software components at all times, you should be finding more vulnerabilities.

And I think this is what the industry's going to have to struggle with, too, is like if we're finding more vulnerabilities, then how are we fixing them or how are we preventing them from getting created in the first place? If we're doing agentic coding, presumably we can also have the agents assess their own written code for security, and then we're dealing with more downstream integration security issues. But at the end of the day, this is going to be a full pipeline change.

We're going to have to figure out how we write secure code with agents, also assess running code with agents, and then also remediate any vulnerabilities that are coming through with agents. So I think you're going to see agents across the full SDLC. Of course, everybody and his brother's talking about Mythos and the implications that has for discovering more vulnerabilities than ever.

And theoretically, I think the rest of the open source community will probably figure it out, and eventually everybody's going to have this capability for better or worse. Absolutely. But my question to you is, are we reaching a point now where maybe we just need to go back in and look at all that legacy software and start with the assumption that we're going to have to rewrite most of it because it's just going to be too rife with vulnerabilities that humans created, and they're going to get exploited now in a matter of minutes?

Over time, that will happen. I think we're finding a lot of legacy vulnerabilities with Mythos. 7 didn't really perform well in the exploit development phases.

So the reasoning capabilities of Mythos is going to yield more exploitable vulnerabilities and more chained exploits, where you're taking multiple vulnerabilities and chaining them together into an outcome. However, the idea of replacing all this legacy technology is not something we can do overnight. It's going to be very expensive.

Let's think about the foundation of the internet, the routers, the switches, the firewalls that run everything at the internet level, at the lowest level. People are not ripping those out, really, unless they break. And it's not really an upgrade that we've planned for in all these companies' capital expenditure.

They're not planning to just rip all that stuff out and upgrade it. So I think we need to find a way to upgrade in place, harden what we have, maybe through software upgrades, maybe targeted hardware upgrades if there's chip-level issues. But at the end of the day, this is going to be a long journey to replacing legacy tech.

And every large company also has legacy software debt, too. We know that some of the financial sector still runs a lot of the back-end banking systems on COBOL systems, and COBOL is not exactly an active language. It's not something we teach in colleges these days.

But we've developed agents that can now effectively develop COBOL programs and maintain them. So, we're kind of back in the game a bit of being able to maintain legacy systems at a better rate and be able to patch them more reliably. So I'm optimistic that we can find a path without massive capital expenditures to actually address these issues.

Are you at all worried that things might get worse before they get better? Because, at least in my experience, not all the best penetration testers in the world wear white hats, and they're going to have access to these tools, and they're going to be looking for stuff, right? Yeah, you're absolutely right.

Adversaries are definitely going to use these tools to gain access to targets of interest. And that could be nation-states. That could be criminal gangs.

That's all going to happen. But that would happen either way with these models here or not. So it's on us to leverage these models for collective defense to start to find the vulnerabilities ahead of the adversary.

And a continuous pen test model is the way for companies to be more secure, recognizing that attack surface is changing, their assets are changing, the technology around them, and the vulnerability space around those assets is changing. Supply chain is a bigger deal than it's ever been before as well. So you've got to think about what is in the product that you purchased, and are you downstream of malicious changes?

So it's a very complex operating environment. So adversaries will always find a way in, but we're going to have to adapt and be quick and be nimble and be able to remediate faster than ever before at a volume that we've never seen. Mm-hmm.

And that's going to be the major shift culturally inside all these companies, culturally and also technology-wise. Right. And speaking of that cultural change, how will that manifest?

Because so much of what we still think about security is an afterthought. We go do something A, and then we kind of figure out whether it's secure later. If we're going to do this in a more continuous fashion, is the way we think about security going to change, and is that a function of that we just changed a workflow and so our culture will change, or does something else have to happen?

Well, I think just like developers are modernizing how they build software with agents as copilots, agents as taking the first stab at developing a feature, security engineers are going to have to do the same. They're going to have to be managers of fleets of agents, swarms of agents that are doing the work, and they're providing that human supervision. And then that slack space, that space that's taken by AI agents, is not going to lead to massive job loss, in my opinion.

It's going to lead to people pivoting to the problems that can't be easily automated with AI. And things like remediation, you're not going to just turn over massive patching of your Cisco fleet to AI agents if you haven't tested that in isolation. You're going to want to take a different approach to managing the change.

And culturally, people are going to have to adjust to constant change. This idea that my work role is not changing, and I'm just going to do the same thing for the next 10 years, that's gone. We're going to have to adjust, and we're going to have to also give people space to learn and evolve and adapt and bring in new skills to their skill repository.

" And then there was a conversation about shifting more right, and then with the security teams and the SecOp teams are still overwhelmed. So between shifting left and shifting right, is there some sort of middle that makes sense here? And what does it look like?

Well, shifting left definitely failed in the last decade. It didn't really work well. Shifting right, we realized engineers have a lot more context about the code than security folks do.

And they don't have the same ability to make judgment calls on what's an acceptable risk at the software level. And so, the hope is with AI applied to development and AI applied to security, we can finally realize what we all wanted, which is more help in the process of managing lots of change in code, lots of change in infrastructure, with AI as a copilot, making us more effective and spotting changes that could be problematic and raising those for human review while others fly through and are automatically approved and automatically applied. So, this is going to be our process of evolution here.

But hopefully with this new tech and the reasoning that it brings, which is important, that was the missing piece before. We had complicated if/else statements in software. Now we've got also this seemingly reason space in the models that we can code with our own human logic around reasoning if a change is valid and should be applied, and is low risk enough to be applied.

So we can project our own human processes onto these AI models and hopefully remove some of the barriers that we had to achieving DevSecOps as it was defined a decade ago. " Well, it's still painful to see folks do point-in-time testing, and with a single consultant. We have to recognize that point-in-time testing is insufficient for the complexity and rate of change.

Bring in one consultant, we're only benefiting from the knowledge of that one person. And so we need to take a different approach, and use a blend of AI agents and a blend of groups of smart humans. And this has been Synack's mantra from day one, man and machine coming together with a crowd of expert hackers.

And now with agents, a swarm of agents doing pen testing, we can finally get the most comprehensive pen tests available and do it continuously. And that's really the major shift that will happen this year. And we need to recognize that adversaries are going to be using the same tools.

They're going to be using the same techniques. And so the only way to fight AI is with AI. I think it would be fair to say that a lot of the people who champion application security in organizations aren't necessarily the most popular people in those organizations.

So, what's your best advice to those folks about how to have this conversation in a way that everybody else will get on board? Well, engineers love cool tech, right? So if you're in the OPSEC role, you've got to lean into this tech, this AI tech and the development of agents that can write code, and also lean into the development of security agents.

And so I think leaning into the appeal that this new technology has with the engineering organization and getting closer to engineering as a security person is going to really engender a lot of goodwill. And you'll be able to make highly effective changes to that full pipeline of software development. It's really a matter of getting that cultural shift to happen across the silos in organizations, from engineering to product to operations to security.

It needs to happen everywhere. " All right, folks. You heard it here.

They say if you want to be popular, find a parade and get in front of it. Yeah. It's no different.

Mark, thanks for being on the show. Of course. Thank you.

Thanks for having me. All right. And back to you guys in the studio.