AI’s Impact on AppSec and the Google Cloud API Leak
The cybersecurity market is reinventing itself at unprecedented speed, leaving traditional methodologies in the dust. On this episode of Techstrong TV, Checkmarx’s Steve Boone joins Alan Shimel to explore how the conventional software development lifecycle is rapidly evolving into an “agentic delivery lifecycle” driven by AI coding assistants. The two dig deep into the recent Google Cloud API key exposure, the critical lack of API visibility across the enterprise, and how Checkmarx is blending deterministic rules with AI to help developers zero in on vulnerabilities that are actually exploitable.
Transcript
Hey, everyone. Welcome back here to Techstrong TV. Uh, my next guest, well, he's not a stranger to our show.
He's been on a number of times, my friend Steve Boone. He's Director of Product Marketing over at Checkmarx. Steve, welcome back.
How you been, man? I've been fantastic, Alan. Good to see you.
Thanks for having me on again. Pleasure. Uh, so Steve, you know, it certainly has been some interesting times around AppSec.
We're gonna talk about it and how it's affecting Checkmarx, but before we do that, I wanted to, for people who haven't caught you on the show before, maybe you're not- ... familiar with your background, give them a little bit of your history. Yeah, sure.
So I've been in the DevOps cybersecurity space now for a little over 10 years, focusing on everything from automation, vulnerability detection, remediation. Um, and now at Checkmarx, we're focusing on, you know, really helping organizations adopt some of the newer technologies like AI, but doing it in a meaningful and direct way, right? How do we allow developers to use things like, you know, Copilot, but do it in a safe way, understanding that when we're generating code, right, it's no different than bringing in strangers' code, right?
You wanna have eyes on that. You wanna understand if there's any issues with it. You wanna be able to, validate it and remediate it, and ideally use it in such a way where, you know, this new code isn't coming in, adding more challenges to your organization, more vulnerabilities to your existing backlog of, of stuff that you're working on.
So for us, you know, we see all the shifts. We see a lot of the, challenges as well, and, our goal is to make sure that we can help organizations navigate those waters. Absolutely.
Um, Steve, you know, a-as I mentioned and as I guess you said, Checkmarx is, you know, they're one of the OGs in AppSec in some ways, right? For sure. They've been around a long time.
Yeah. And, we're, we're living in a very interesting time period right now, especially as it applies to AppSec, right? The recent, releases and the amount of vulnerabilities they found, so-called vulnerabilities, right?
I wrote an article the other day. You know, they, they set it loose, I think it was on Firefox or something, and it found 112 potential bugs of which 22 were actually real vulnerabilities and only two were actually exploitable. Yeah.
But just that number, it sounds like a song from Chicago, "25 or 6 to 4," or tw- well, 12 or 22 to 2. "25 or 6 to 4," right? Exactly.
You remember the song. You know what I'm talking about. But it, it's changed...
It's moved the cheese a little bit, right? Yeah. It's changed the focus on not finding potential bugs, but on finding real vulnerabilities, and on real vulnerabilities, I mean ones that are reachable, exploitable, things we need to...
So it, it's really... It's, it's a very different focus change. I'm not saying AppSec, as we know it, is over or anything like that, but it's- It- ...
changing- Yeah ... the, the mission, if you will. It, it's, it's interesting, right?
I mean, when we look at it, for years, right, you and I have been going and talking about things like the SDLC, right? Uh- Mm. " And the, the way that I look at this is that AppSec, it's not that AppSec is dead.
Ed- to your point, it's evolving, right? And, and so now the SDLC is largely becoming an agentic delivery life cycle, right? So as we start adopting AI, we start seeing the emergence of all these agentic agents.
We're seeing them at the development level, right, where developers are writing code and generating code. We see them at the pull request level, where there's agents that are analyzing these pull requests, trying to understand if they're... can provide more feedback, or if there is a vulnerability, could I provide remediation to it?
To your point, how do I... You know, people are always worried about reachability, exploitability. Um, so, you know, can we, at the time of a pull request, give a developer confirmation, "Yes, you need to care about this.
This is absolutely exploitable. " And if we can, well, there's another opportunity to give them code that can address that, and they can make another pull request, right? So now you're starting to see these agents both at, in the IDE, at the pull request.
We're seeing them start to appear, very rapidly within the CI/CD spectrum as well, right? Agents that can help facilitate your pipelines. Agents that can help remediate your pipelines.
Um, and you also start to see them at the monitoring phase as well, and all these applications go live. You've got APIs, you've got runtime, all of that. You know, think about it as agents galore.
And so now, not only do you have to understand how to implement these agents and scale these agents, you also need to secure these agents. How do you make sure that they're not trained inappropriately? How do me make sure that the...
'Cause you always have this idea, AI for security and security for AI, and we're- Mm-hmm ... quickly running into this area where we're seeing some... You know, like I said, we've been around for 20 years.
Been around for a long time. We've always, been very, deterministic, rule-based, if you will, in how we scan code and find vulnerabilities. You mentioned something like cloud s- cloud security, right?
That's more probabilistic anal- analysis of where we see what's probability that you're gonna have these vulnerabilities or the types of findings they have. Um, and so our goal now as we evolve, as Checkmarx move forward, is to bring both of those together. Yes, we still wanna be deterministic.
There's a lot of value in all of the rules that we've built over the last 20 years to scan code and identify known things, right? That, that's not going away. But you also wanna have that probable aspect as well, right?
You also need to be able to bring those things together, and then whatever value you can squeeze out of thatFigure out a way to get it into that, into that feedback loop. And so even our feedback loops are starting to get some of that agentic feeling to it as well. Absolutely.
Absolutely. Somehow we, I, you know, I didn't mean to take us... We made a left turn.
It's all good. I hear you. Steve, what, what we were supposed to be talking about though today was the recent incident regarding Google Cloud API keys.
Yes. And it's not that far afield, but, you know, let me bring us back to here. Talk to us about this particular, incident and, and what became of it here.
Yeah. You know, I mean, when we look back at what happened with the, the Google Cloud situation, right? And, and the, the...
A lot of folks will say, "Oh, you know, the bigger issue is exposed keys," right? They had exposed API keys in their code. I, I would say the bigger issue isn't just an exposed key, it's that many organizations don't have a complete inventory over their APIs and credentials that are running in their environments, right?
So visibility is a huge problem for, I would say, 85, 90% of organizations out there. " isn't necessarily a question that a lot of application teams can answer. Um, so when you have credentials that are embedded in code, you know, they quietly expand, the API attack service.
Um, and security teams a lot of times don't even realize it. So the real risk, at least in my opinion, starts to appear when organizations lose visibility into what those credentials can actually access once they're deployed, right? So you can't secure APIs that you know, that you don't know exist or understand.
You just... It's not a thing you can do. Agreed.
Agreed. Uh, you know, and you can't defend against what you don't see or know either, and, and that, that's always been a problem. Yeah.
Um, what can we do about it? Well, I think there's, there's a couple of things, right? Um, one, you d- you need to have that inventory, right?
So being able to scan your code and just knowing, "What are my APIs? Are they internal? Are they external?
Are they secured? " is wildly important, right? That gives you your base understanding of, of the landscape.
Now, there are several different layers of API solutions on the market. We obviously, as a code-scanning company, look at things from a code perspective. Um, there's a lot of great companies that we partner with out there as well that are more of a runtime perspective on it, right?
That will analyze your network traffic, see if those APIs can be attacked, and in a lot of ways tell you that they are being attacked, and here's d- different ways that you can address that. And, I think one of the other things is as well, though, is, is that w- I, I think organizations can do a much better job at what I'll say is secret detection, right? Very, very frequently, and I'm guilty of this as a amateur developer on my own, right?
I just wanna make cool things that work for me. I'm not out here writing the mission-critical stuff that Checkmarx does. But as my, as a hobbyist, when I'm writing code, hard coding secrets, I just, I don't care.
It's running locally for me, right? But we see this in development environments, too. So all of a sudden, you're testing something, you need to make it work, and you hard code these credentials into APIs.
All of a sudden, they get promoted into lower-level environments and occasionally even production. So this idea of not understanding the full attack vector of our APIs, but also knowing that bad coding practices do happen, right? That it's always gonna be something we're gonna deal with, expands upon it.
So w- a little bit of it's going back to the basics, right? Making sure we understand exactly what our APIs are. Um, one, making sure that we can document those APIs.
Scanning regularly, because as new a- APIs get introduced, sometimes we won't find about 'em until we scan the code. Okay, great. Now we need to make sure we go back and document them, right?
Make sure that we close that gap from a development side. And then again, regularly scanning in IE in real time for those secrets. Um, you know, once Checkmarx identifies secrets in your code, we can easily help developers remediate that so it's not a problem going forward, right?
So those are the things I think is kinda easy blocking and tackling that organizations can do, to keep themselves safe. Fair. Fair.
Steve, we, you just rattled off a whole bunch of really good stuff there. Where can we go on the Checkmarx site or, you know, to kinda w- so we could study this? Yeah.
So there's, there's actually a ton of locations that you can go to, right? I'll, I'll give you a couple of the ones. com, because out there you're gonna find everything that's going to address what you want in a platform, right?
Multiple different engines. Um, you've got the API scanning, you've got the code scanning. We're doing a lot now with our DAST engines.
We're actually heading to RSA here, in, in just a couple of weeks. We're- Two weeks ... really cool announcements coming out there.
dev. dev we've got, the Checkmarx Developer Assist. You can get a free trial.
Um, it's easy to get set up working in your local IDE. It will scan your code in real time. It will help you with remediation of new vulnerabilities, existing vulnerabilities.
It'll hap you, help you with, package refactoring. So if we scan something and find a vulnerable package, right, what are the steps that you need to go through to refactor that code to adopt the new version of that package, without, you know, introducing a ton of new breaking changes, right? We, we're here talking about APIs.
Um, those change between version to version of packages, and so Developer Assist can help, ease all of that. It'll identify new packages, tell you what's changed in the code, and it's leveraging the 20 years experience that Checkmarx has to bring that into the IDE. So, you know, a lot of people say, "Oh, well, Checkmarx, you're just asking AI for how to remediate it," and that's not it, right?
We're, when we're... What we're doing is we're calling back to Checkmarx services and saying, "Hey, give us that 20 years of knowledge on how to go fix that cross-site scripting or that SQL injection," and then we pass that information back to your coding assistants to make sure that they're following the right orders and right steps to change that code securely. dev.
com will, give you everything you need to know from a platform perspective of how to make sure your enterprise is secure. Excellent. Steve, I'll be at RSA too.
I hope you'll stop by. I'll be at Broadcast Alley all... Well, Tuesday to Thursday I'm at Broadcast Alley.
Monday, you know we do our annual DevSecOps. Sure. This year it's Securing AI Native Dev.
But we'll be up there, Monday. If you're around, stop by. We have some great speakers lined up.
Um- Absolutely. Look forward to it. But until then, I hope to see you there in person.
But keep up the great work, man. It's such an exciting time. This, it's, this stuff is...
You know, I've never seen security move this fast. So- It's funny, you know, security used to always be kind of the, the thing that was the laggard, and we, "Oh, okay, we gotta catch up," and, and now it feels like the whole market is just reinventing itself. Crazy.
Yeah. Crazy times. All right, my friend, it's good seeing you.
I'll hopefully see you in two weeks. Steve Boone, Checkmarx, here on, Tekstrom TV. We're gonna take a break.
We'll be back in a moment.