James Berthothy: [00:00:00] I really hate what analysts have done to CNAPP. Like I see some people even include SaaS as part of CNAPP, at which point, like it is literally every piece of security you could have, but I think cloud security is really just container security and it almost always has been. But that's been obscured through several layers of people learning the infrastructure of how containerization works at the same time as cloud.

There are too many different users in that one platform for it to fully satisfy any one of them. Most vendors in this space are very confused about how to go to market. They are vulnerability management but built for cloud applications. This is why I push the runtime path so much is we've gone down this path as though we can create this perfectly secure cloud environment, where if we just fix all the vulnerabilities, there's no attacks.

But fixing all the vulnerabilities is first of all, a waste of time. And it's second of all, like it can't be done. If anyone is telling you they have solved the vulnerability problem, there are issues with it.

Ashish Rajan: If you wanted an engineering perspective on space like ASPM, [00:01:00] CSPM, CNAPP, AI security, all the acronyms that come with the cloud application and AI space.

Today's lucky episode. Today I have James Bertotti who runs latio.tech who has been a secure engineer for a long time and now runs a newsletter under the same name or pulse.latio.tech as well. Overall, I've enjoyed the conversation that I had with James and I think you will enjoy it too, especially if you want an engineering perspective on the entire cybersecurity landscape, whether it's vulnerability management, whether it's the acronyms that we are landing on or what you should look out for as new acronyms that will come out in 2025.

All that and a lot more in this episode with James Berthoty. Now, if you are listening or watching the Cloud Security Podcast episode for the end time, click First of all, thank you so much for your support. And secondly, if you would love to support us, hitting a simple follow on any of your audio or video platforms like Apple, Spotify, LinkedIn, YouTube would be a great way for you to show some love to us and support the work we do over here.

And I appreciate all the love you show us on all the conferences and everywhere else as well. I just want to say thank you for all the love and support. I hope you enjoy this episode and I'll talk to you soon.

Hello, welcome to another [00:02:00] episode of Cloud Security Podcast. I have James Berthoty. Hey man, thanks so much for coming in and we finally made this happen.

James Berthothy: Yes, it is excellent to be here. I see my dog just showing himself. Thank you for having me.And it's crazy to be on here because I started learning cloud security via this podcast. It was one of the initial episodes with Atlassian was one of the first like episodes I listened to about securing microservices and how to do that.

And Yeah. So it is very cool to now, be on it.

Ashish Rajan: I've known you for some time, but for people who may not be familiar with James and your work as well, could you just give us a brief intro of yourself and the work you do, man?

James Berthothy: Yeah. So I still think of myself primarily as like a DevSecOps security, cloud security, app security, product security, whatever the title of the week is person. But a few months ago, I went full time with a business I had started called Latio Tech and the goal is just to give engineering first opinions and analysts on the market, as well as on which security tools should I choose? Because when selecting a CNAPP, for example they'll all say they all do the same things, [00:03:00] but anyone who's used them knows they're all pretty different.

And so my goal is to speak directly to engineers to give like the guidance around what tools you should get and what the real differences are instead of the sort of vague marketing, everyone does everything sort of thing.

Ashish Rajan: One of the reasons why I wanted to have this conversation as well, because of the unbiased opinion you share as from an engineer's lens, and since you touched on cloud, I'm going to start there.

How do you define cloud security today? Cause both you and I have been in this space for a long time. What comes to mind when you look at cloud security, people talk about cloud security today.

James Berthothy: I have a very edgy opinion on this because it tends to make people very upset, but I think cloud security is really just container security and it almost always has been but that's been obscured through several layers of people learning the infrastructure of how containerization works at the same time as cloud.

And I also recognize that my perspective is very biased towards like mid market cloud native architectures, but more and more enterprises, like the heart of their application runs on containerized infrastructure. And so I think the cloud is really about container security at its [00:04:00] core with a bunch of other stuff, like RDS, like cloud native services and the cloud hosted environments, but yeah, really, that's what I think is at the heart of it.

And then I generally separate cloud security focuses into like posture management stuff. And so I don't differentiate like a CVE from like RDS misconfiguration. To me, all of those are just things that have to get fixed on like the scanning side. And then I have the runtime protection side of the house, which is the thing that I've always loved the most.

Because to me, it's like everything else is a work generator, where I'm creating work to send to developers. versus everything else on the runtime side, I can actually do something about it. Like I can actually kill a pod, I can stop a container, I can actually take an action myself. And so that's why I've always been heavily biased towards the runtime side, but I think in the CNAPP landscape, we've seen the prioritization of that be opposite of what I would like.

And that's how I approach it.

Ashish Rajan: Oh, I love, and I think we will definitely, you'll be surprised by how many people don't even know what CNAPP is. I think I was running a training some time ago and I think mostly were [00:05:00] enterprise, it was an enterprise corporate training. And I just I'll raise of hand for who knows CSPM, CNAPP.

People had no clue what I'm talking about, like this guy throwing acronyms in there. And CNAPP today is a lot more different than the first definition of CNAPP that came out as well. Now it basically sounds like everything is underneath it. How would you describe CNAPP as well today?

James Berthothy: I really hate what analysts have done to CNAPP.

Like I see some people even include SaaS as part of CNAPP, at which point like it is literally every piece of security you could have. There are too many different users in that one platform for it to fully satisfy any one of them. And so I think there's a couple that have a legitimate chance, like the vision of CNAPP is code, cloud, and runtime.

I actually don't think that best serves the industry or that's how we should really do it. It's sort of consolidation for consolidation's sake, where vendors hear CISO say, Oh, we have 17 different tools. We want less. And so they go, Oh here's the one that does everything. But it creates this problem where it's doing everything really badly.[00:06:00]

And it really frustrates me when I try to suggest people tools that'll actually make their life better. They're too overwhelmed with even the idea of switching because they're so used to a bad user experience from that all in one thing. Instead, I separate it into ASPM as a tool for developers, CSPM as a tool for systems engineers, sys admins, that sort of thing for people who have traditional infrastructure.

And then what I'm calling CADR, which is this runtime thing that covers, it's built for the SOC so that for once they can actually respond to containerized alerts in a way that's not just Oh, this is a container alert. Let me ask the DevOps team. Cause everywhere I've worked, that has been what has happened where the container alerts are too complicated to understand because they involve a lot of application context that SOC teams just don't have familiarity with.

They don't have the telemetry available to research them. And so it turns into a, Oh, let me ask the DevOps team. Let me ask the DevOps team. Let me ask the DevOps team. And so I think that slice of the market is the one that's been the most underserved by CNAPP because of the prevalence of this like agentless, let's get [00:07:00] the posture stuff down.

Ashish Rajan: I'm with you on this as well. Cause I think I definitely see a trend on my side as well, where I think people who go through different levels of maturity for cloud, where initially it was a cloud security engineers started looking at alerts from CSPMs and CNAPPs. And then later on, now we are in this AI world as well.

So AI workload is Oh, great. This needs to be put on cloud. So cloud security engineer, can you secure the AI piece? Let's throw the alerts to the SOC people. Cause that's what they're supposed to do. Yeah. And to what you said, a lot of them don't even have the training to even understand the difference between an on premise alert versus a no, they're experts in on premise.

They've done that for 10 plus years. Now suddenly you throw AWS, Azure, Google Cloud logs at them and they're like going. What is this? Is this a false positive? How do I verify that? And the reason I bring that up is because one conversation that has been coming up quite often for me has been the difference between how a SOC looks at a CVE versus a misconfiguration.

It's an interesting one where although as a cloud security space, we've called out, Hey, every [00:08:00] misconfiguration is a potential vulnerability. And when I talk to SOC people, they're almost like is it a vulnerability or is it just a misconfiguration? And I'm like, have you come across that where people are like trying to toss that?

Because this is where a lot of the bottleneck seems to be as well in getting the actual stuff done.

James Berthothy: I think I learned pretty quickly that the SOC should really not be involved almost at all in CVE and misconfiguration hunting, because all you're asking them to do is get an abstract alert that's tied to some piece of configuration and then find the developer that's responsible to it.

And that's the reason the code to cloud thing that CNAPPs are going after that ASPMs are going after. That's the importance of it. It solves that problem where you have the misconfiguration comes in as an alert. And the only action the SOC person can take is to find the person to go fix it.

And then the SOC theoretically is doing this prioritization, but if they don't know what the underlying technology is, like, how are they supposed to be prioritizing it? Like the entire thing is on the [00:09:00] developer and you're asking them, what is the misconfiguration? Is it really a misconfiguration? How should we prioritize it?

And so the SOC person's not adding a lot of value the way they are if you're responding to a CrowdStrike alert on a Windows endpoint, that's saying Oh, we quarantined a PDF file. Okay, let me go and kill the process that started. There's stuff you can do. That's why I think this code to cloud picture is so important as well as like the standalone vul management providers, which Gartner's got a new acronym every day of the week for like CTEM, ASPM, risk based vulnerability management, unified vulnerability management.

Like. All these different acronyms to just try to say they're wrong management tools that sit on top of this stuff, to try to just get those alerts to the developers in a way that's prioritized, that they can create tickets and fix in an automated way. I think getting the SOC involved in this sort of CNAPP misconfigurations was always a, it's something we did because it fit the existing model, but it never really made a ton of sense.

Ashish Rajan: I didn't realize there were more for vulnerability management. So there are more acronyms.

James Berthothy: Yeah, it's all, that's how I do it. So I'm being myself and redefining some of this stuff in a way [00:10:00] that some people would like or not like. But at the end of the day, there's some of these tools have been along for a very long time.

And Gartner and the analyst firms want to create differentiation from first generation vuln management tools. And they know next generation is like a played out thing to say, because every, Oh, we're next generation. People are tired of hearing it. And so they create all these other acronyms. It's okay here's a vul management tool, but it prioritized basis based on your exposure and attack paths, and we've been seeing attack paths and CNAPPs for over a year, two years at this point, but now if you combine it with vuln management, suddenly that's CTEM and it's like a continuous direct exposure management tool when it's just it's.

It's prioritizing vulns based on attack paths. And then you have ASPM, which I define as like this all in one code scanning thing. Cause I think it should be the developer equivalent of a CSPM. But the Gartner definition is much more of a orchestration of application, a security vulnerability alerts.

And so it's just a vuln management tool, but for application scanning alerts like SAST, SCA, those other scanners. And then risk based [00:11:00] vulnerability management. It's just to try to say those other vuln management tools didn't do prioritization, but we prioritize based on risk. And it's okay that's the kind of thing everyone's going to do in two minutes.

And so I simplify all of that to just vulnerability management.

Ashish Rajan: Which kind of makes sense, but wait, so are people actually branding themselves as risk based vulnerability management?

James Berthothy: Oh, it's why you see that most vendors in this space are very confused about how to go to market. They are vulnerability management, but built for cloud applications.

And so there is a legitimate difference between like vuln management tools that were built for on prem and those that have been built for cloud native environments, like doing the code to cloud correlation, doing remediation steps for code. And they just want a way to differentiate that. And they keep getting thrown all these acronyms and it's unclear, like what people actually want from an acronym standpoint. And so that's why I'm like, look, they're just better vuln management tools.

Ashish Rajan: Because you put the engineering perspective on some of these, how would you say the vuln management? Cause and I'm not gonna name the companies, but there are two really [00:12:00] popular vuln management softwares.

That was basically the default standard for on premise for a very long time. Like it's almost and I'm pretty sure, the two I'm talking about. Yeah. And that was always revolved around the area that I have a Windows, I have Linux, it has an endpoint, there's a, ongoing scan that's being done on a periodic basis for audit or whatever, your patch levels are not updated.

Now, people have believed, and I think I do too, as well, to some extent, the dynamic nature of the cloud kind of fails that whole old model of doing vulnerability management. So how would you describe vulnerability management in the cloud space and how, what is that supposed to be?

James Berthothy: That is a huge issue.

And I think you have to split it between what security would say it should be and what compliance would say it should be. Cause I, when I was at PagerDuty, we're FedRAMP authorized, and that was an extreme challenge to be in the kind of environment where you have a cloud native architecture and you have to hit federal remediation timelines, because the sprawl of CVEs across container images is so [00:13:00] just massive. And I think there are entire vendors that are built around solving this compliance problem. But I think a lot of people mistake that as being a security solve when, if you ever try to build an exploit of any of these vulnerabilities in your actual SaaS environment, and I'm talking mostly about SaaS here. CVEs do, I think, become a little more meaningful when you're deploying actual hardware, when there's something like physically susceptible to attack.

That's a lot of the low level Linux vulnerabilities that come out, but for SaaS, like you are going to be hard pressed to find an actually exploitable vulnerability, and so I think we've, unfortunately, this is why I push the runtime path so much is we've gone down this path as though we can create this perfectly secure cloud environment where if we just fix all the vulnerabilities, there's no attacks.

But fixing all the vulnerabilities is first of all, a waste of time. And it's second of all, like it can't be done because the rate of vulnerability discovery is insane. If anyone is telling you they have solved the vulnerability problem, there are issues with it. This is why I think we've really under [00:14:00] emphasized Just because we have a fear of installing agents, which is okay. Kubernetes has really changed the way we should think about agents and that's what I try to push a lot as far as like the runtime emphasis is, Hey, let's actually respond to attacks in our environment and get visibility into them instead of just looking at this endless patch management cycle as the gold standard.

Ashish Rajan: Interesting. And I love the math on that used to be, and I think it's worthwhile calling on because when cloud became popular, a lot of vulnerability management people like, what does that mean for me? And a lot of vulnerable team management people actually lost their jobs as well. So I love the comparison to SaaS as well, because now that I think about it, I can't remember the last time I did a Linux install on a server, or in fact, and many engineers and architects that I've spoken to, no one does that anymore. Mostly it's SaaS.

James Berthothy: Part of the reason there's a lot of vendor confusion too, is because when we talk about the cloud, we're just talking about a data center. And if someone had come to you two years ago or 10 years ago, whatever, and said, Hey, I have an all in one data center application protection platform.

Like we would have laughed at them because it's too complex [00:15:00] to try to say that, Oh, you cover every possible configuration of a data center. But the cloud is the same way. We're like, depending on the customer base that a vendor is working with, they might be skewed very heavily into thinking like everyone's doing ClickOps with Windows environments versus everyone's doing DevOps with CICD and container environments. And the truth is usually some mix of maturities as people try to learn what's best for their environment. Even the hard truth is that not every company benefits from microservice CICD models.

Like for some of them, running a monolith on a couple of static Linux boxes is a much faster and efficient way to deliver value to their customers than creating Netflix from scratch.

Ashish Rajan: Yeah. And sometimes Kubernetes is not always the answer for every application you find there as well. But yet here we are, the number of times I've heard organizations in a lot of the training that I've been running I've found that a lot of the companies, majority of the companies that I've spoken to, they've all come to the conclusion that moving forward, every new application is going to be hosted on Kubernetes.

It's almost like becoming the default standard. Are you [00:16:00] seeing the same as well?

James Berthothy: Yes, for sure. And I have thought for a long time that's the way things should be. It just depends on the specifics of the industry, but definitely that's the way that things continue to go is the importance of Kubernetes.

I will say I was optimistic for years. I've thought security people would learn Kubernetes, but it's a really hard technology to learn. And if your day to day job is wrapped up in like SOC alerts or windows infrastructure or sysadmin kind of work, it's really hard to break out and try to learn this whole other thing and learn how to secure it really well.

So I just continue to hope that's where more emphasis gets put is on the runtime side of containerized security because even if you're not using Kubernetes, I guarantee you're using Lambda or ECS, which are still just ways of running code on containers.

Ashish Rajan: Yeah. And to your point, the alerts for that, Oh there was a whole misunderstanding of getting alerts from a Kubernetes native way versus Kubernetes alerts, which is literally a misconfiguration of your EKS or ECS as well, there's a long time [00:17:00] that people didn't even understand they were not even looking at Kubernetes vulnerability.

They were looking at the whole Kubernetes misconfiguration of EKS or ECS. And I'm like, what? Oh, but did you see that as well? There was a phase where people didn't understand what the Kubernetes security was supposed to be.

James Berthothy: We all learned together and we're still learning together.

Like when I give advice to vendors on building security products, I usually tell them like the security team is learning how this technology works via your product. That's why the CNAPPs that shows visibility have been the most successful is because they're teaching people how this stuff works in the process of deploying it.

And it's just the, we continue to learn Kubernetes. There are some vendors that have very cool automated solutions and have for a long time on like set comp policies, network policies, but they go unused because it's the complexity of understanding and deploying something like that is just too much for most security teams.

And the product team doesn't have a strong enough. incentive to do it right away.

Ashish Rajan: Actually, yeah, you're right. Also because when say, if I'm putting myself in the shoes of an engineer [00:18:00] day to day, I have so much more to do than just look at cloud all day or look at what the latest acronym is. You and I do that because that's the kind of our job now.

That's necessarily not what the engineer or architect out there is doing, or even the leader out there is doing, consistently following up with, Hey, what's the new acronym that I need to be updated because I have endless budget that I want to spend money on. Why not just spend on the latest acronym?

James Berthothy: There's a reason where I thought, at one of my jobs, we finally got budget to hire like a second James was how we put it. And I thought that was the problem. Once we got budget, we would have a ton of developers like want to come join the security team. But then we basically had to beg one developer who was like open to it to come over to the security side.

And there's a reason we refer to these people who have this skill set as like unicorn kind of hires is because when we think about what a security person is supposed to know, who does DevSecOps, it's like DevOps and deployment methodologies. It's every language basically, if you're responsible for securing Kubernetes, which is its own beast, you have the per language applications that are running in those [00:19:00] containers, so are they also going to be an expert in Java, Python, Go, Rust, JavaScript, every JavaScript framework, like it requires a depth of infrastructure, DevOps and platform engineering and coding. It's impossible to hire for. And that's why we lean on the tools a lot to tell us what's there.

Ashish Rajan: And even the AppSec side as well, like I think the SCA, SASTs of the world.

They're also thrown to the DevSecOS person. They have to not only understand infra from these CSPM, CADR and everything that we just spoke about, but they also have an ASPM for, Hey, okay, what's my SCA, what's my, and do all of that with one person team.

James Berthothy: That's why I've always advocated that like security, theoretically on all of this posture stuff.

Security shouldn't even really be involved. We always will be involved because of the reality of trying to get these things moving and explain and prioritize and all of that. But in theory, this is the whole idea behind shift left is that the developer will get the alert and fix it. The problem with shift left is that people are discovering that that's not how vulnerabilities work.

Developers, when they're implementing a [00:20:00] new package are picking the latest version. They're not intentionally Oh, can I go find like a 10 year old vulnerable version of this before I implement it? Where's where then a shift left tool would actually stop the implementation, but it's always going to be green.

Like I've almost never seen a PR check actually stop something bad from getting into the code. But then your backlog grows and you're like, wait a minute. How is this happening? I thought we were supposed to stop the bleeding, but the backlog keeps growing. It's because you haven't been patching those open source vulnerabilities and new ones get released and then you're vulnerable at that point. And so it's really about creating like a holistic patching strategy. And how are you going to do that at scale? Which is there's like only two vendors that help with that, which is the actual problem.

But the scanning side, there's 30 of them. And that's, what's crazy about the whole industry is it's really hard to sell the solution. And it's a lot easier to sell the visibility into the problem.

Ashish Rajan: Oh, and I think to your point, is that where the ASPM was trying to help where it's showing visibility across the entire code base rather than to your point, the silo of [00:21:00] SCA has one tool, SAST has one tool, DAST has one tool.

Oh, then look at that. There's a secret exposure as well as another one.

James Berthothy: And that's why I made a lot of vendors mad when I included scanning as something an ASPM should do. It's because otherwise it's I've got to make great. Now I get to maintain 12 different tools and I get to maintain something that sits on top of the 12 tools and gives me all the visibility, but over time, like most of the vendors who do both ingest findings from those third party tools.

And have their own offerings that way you can slowly transition to the all in one scanning. Or if you have a point solution, say you use some really weird JavaScript framework that only this open source SaaS supports, vendors don't support it. Like then you should be able to use that and ingest the results.

And so to me, that's why it's the dev focused analogy to CSPM, which was sysadmin, sysengineer focused.

Ashish Rajan: There's already a movement to what you were saying when CISOs and others tell a vendor that, Hey, I have six tools for six different things, whether it's your ASPM, CNAPP, whatever category you want to put in there.

[00:22:00] In a way, I empathize with the vendors as well, because they obviously consistently trying to sell, be the cutting edge and competitive and all of that. So they have to keep chasing their tail on what should they be doing next? Because the moment that feature is released, someone else has already copied it.

And now you're like, Oh my God, I have to think of something else on the differentiator. In terms of, the unification that's going on with all the platforms combined together and all of that, where do you stand on the whole platformization because your point is there a good way to do it?

Cause logically it makes sense. As if I were to put my CISO hat on, it's easier for me to talk to a CFO about budget when it's one app versus I need six different ones to go through. So what is a good way to do platformization or do you even believe platformization should be a thing?

James Berthothy: Yeah, I think it's platformization around end users is what I've decided. Cause I spent a lot of time thinking about this cause I really couldn't make up my mind. Cause I've noticed security technologies get built either on top of technologies. So that's like Kubernetes security, AI security. Every time there's a new technology that evolves, you're going to see like a cluster of [00:23:00] products built around the technology.

Then there's built around like the budget, which is the platform for platform sake, which is Hey, you got money, boy, we have a product for you. And it supports every use case you ever have. And that just leads to an end user experience that's just miserable. And then there's building a product for specific people to actually help them get their job done.

And that's what I prefer. And that's why I think the consolidation should really happen into just three categories. So I take all these point solutions exist because like the idea of an all in one ASPM is like a new thing. And CNAPP finally is expanding to the point where it can cover all the infrastructure cases.

And the CADR thing that I talk about is so new, it like barely exists depending on how much you're willing to wink at it. But I think that's the way that things should consolidate where CADR is built for the SOC, CNAPP, CSPM is built for systems engineers. If you have a traditional infrastructure and then ASPM is built for development teams and DevOps teams.

And so if you're a cloud native organization, I think you should consolidate around CADR and [00:24:00] ASPM and you don't even need CNAPP. But if you are in a bigger organization that has these pieces of bespoke infrastructure, where they're not defined as code, they're not run as containers, then you need something to detect the vulnerabilities and configurations of those different assets.

Ashish Rajan: Where would you put Kubernetes in there, cause to your point, A lot of people and a lot of Analyst companies have started talking about CNAPP including Kubernetes. Should CNAPP still have Kubernetes as well?

James Berthothy: I split everything between the posture and the runtime. And if we're talking about the posture side, it would be pretty embarrassing for a CNAP to not support Kubernetes because that's the majority of cloud infrastructure.

It gets to this. I don't think you actually need it. There is what's counterintuitive to people is if you're an ASPM and you're looking at the Terraform or you're looking at the helm charts and you're looking at the deployment YAMLs, you have the same information that the runtime scanner is picking up.

You're only looking at drift. And so to me, the way that makes the most sense to look at Kubernetes posture is through the lens of [00:25:00] an ASPM that is looking at the cloud in the context of here's your runtime and how it's drifted from what's defined as code. I think Kubernetes should be split between the runtime side.

That's part of CADR. And then the posture side, that's part of the ASPM. But I recognize the reality, which is that it would be rather shocking if you bought a CNAP provider and it was like, Oh, we just don't support Kubernetes. Oops.

Ashish Rajan: Yeah. Yeah it's coming up. It's coming up next release.

When you say DevOps and system engineers, you also include cloud security people in there as

James Berthothy: well, or? It

depends on the organization. This is what makes it all confusing is we've talked about the cloud as though it's like a homogenous thing, when it really depends on what workloads are you putting there?

And that's why I separate everything between a cloud native architecture, where I've had the pleasure of working at organizations that mostly have a cloud native architecture. And so for that, I. When you say DevOps, that really means cloud engineering DevSecOps, CICD, that stuff. But DevOps at a really big enterprise, that's [00:26:00] probably more around specifically like platform engineering kind of stuff or CICD specific stuff.

And then they might not even have like their Kubernetes might be managed by either like a cloud engineering team or platform engineering team. And so that's why it, as a vendor cause now that I work a lot with like marketing folks, it's who do we target? And it's like everybody that is in DevOps, maybe or even I remember specifically when I bought my first DAST tool, which was like a modern API CICD DAST tool, they were shocked that my title was cloud security engineer.

Cause I, we didn't have an app sec team. Like I was the app sec team. And so that's, it's the complexity of it.

Ashish Rajan: But I think you raised a valid point as well, because at an enterprise scale, and it's funny, the reason I asked that question is because my bias has been coming from, I've always primarily worked either in enterprise or large scale companies.

And I've always seen the silos that are there. Initially, I used to be the whole, to your point DevSecOps, hey, everyone should be blah, blah, blah. But then as time has passed and I started becoming a leader, I realized, Oh, wait, I know why there is this silos. There's the scale is just so [00:27:00] huge. It just practically does not even make sense, but it makes sense for an ASPM where I can log in as an app sec person individually and see what the alerts are and to your point, if kubernetes were there as well, because at the end of the day, a security person cares about the overall application security rather than, or my crown jewel as an organization, if it's to basically, I don't know, banking, online banking, I care about the online banking app being secure. It doesn't really matter. Kubernetes cloud, whatever the hell is underneath it. But I think we don't use that first principle way of looking at it. To your point, we create a filter every time.

Oh, my role is app sec. I draw a line, as someone says, Kubernetes, so that is not my cup of tea.

James Berthothy: That's every security person would love to draw that line

Ashish Rajan: and not have to learn. Yeah. You're like, wait but technically we are supposed to be the overall so we work with someone within our team to solve that.

I understand the skillset of a different and say someone who's learned Java or whatever code language and what security looks [00:28:00] like is very different skillset to someone who's doing pentesting and otherwise, or some, maybe you're doing infra as well, but I appreciate, and I think to your point, it's very good to , call that out.

The difference between where you see CNAPP put in and the runtime security put in as well. And. I guess I have to talk about AI because there is unfortunately now we can live in the world of AI. What have you seen in the AI security landscape that's catching your attention? Or actually, how do you define AI security at the moment?

James Berthothy: I do the same thing where I split it into there's three categories. There's posture and development stuff. There's runtime protection and the use case that's selling the most right now is the browser DLP stuff. And man, I hate that. I've never worked somewhere that does DLP. I'm super grateful to not have to deal with it ever, but I get it.

If you've got to worry about it, then you've got to buy it. And that's why it's like an easy use case to sell. To me, it's a short term sale. Cause it's a trust issue where we don't monitor people's Google searches to see if they're Googling like sensitive data. And we just don't trust ChatGPT enough.

That we feel comfortable just sending sensitive data into it. [00:29:00] I think at some point we will, which is why I think that's a short term thing. I care a lot more about the AppSec side and the market's so interesting to me because early on, we didn't know what was going to be the architecture.

Is it going to be third party APIs? Is it going to be using LLAMA, Hugging Face Models, FineTune, Custom Models? It really was the Wild West. And so vendors took big bets on different architectures. And I think this year, what we're seeing play out is a standardization around like agentic open AI usage, primarily sometimes cloud.

Most organizations I talked to you are taking very similar AI approaches, none of which include hosting your own model. And none of which include just like very simple, like chat use cases anymore. And so I think that next year, instead of AI security, I think we'll see agentic AI security and it's okay, great.

And we'll continue to see this shift where the runtime stuff is so hard to sell and it's too early to market. And it's, but it's the thing that I like the most. And so the, what we've called AI firewall, which I think is a bad name for it, but there are [00:30:00] different ways of doing like runtime sensitive data filtering, all that stuff.

I think that should exist as a subset of ADR. And I know that I'm in crazy land here. Cause like people barely know what ADR is or believe it's a real thing. But if you think about, yes, application detection response, and if it's looking at, if this new breed of tool is using an agent or a different instrumentation to look at all of the calls that are coming in and out of your application.

That's exactly what AI Firewall is doing. It's just only doing it for LLMs. And so to me, it's a subset of this ADR. And when we're looking at these third party API calls, it's no different than any other, like your application probably is also calling Microsoft for login or calling GitHub for there are other API calls that these ADR platforms are focused on securing.

And so I think AI just becomes another one of those. And so I think really what we're talking about. What I'm hopeful that AI security does is pushes us more towards application visibility and application security, because it becomes an [00:31:00] increased need for it rather than tracing down vendors to do some of it.

But I will say is that people who are really heavily invested into AI security, I think it's worth going with a specific vendor on it. Cause those guys are all way farther ahead on AI firewalling, ML bombs, AI visibility, like all of those sorts of things. There's really cool stuff that is out there.

Ashish Rajan: And I guess maybe just to add a layer onto it as well, because I think, and a hundred percent agree on, there's definitely a few more use cases than just simply creating a chatbots these days, how would you describe the buckets of what these vendors are doing for AI security?

So that people get a sense. So you mentioned runtime, obviously ADR is still evolving and not many people looked into it because, and let's just say not many thing in production at this point in time. So it's there's that gap as well. But the other two that you mentioned, what is something that people can expect or should look out for in the 2025 roadmap that they're planning?

James Berthothy: I think a lot of it is focused on just application security more holistically. On the one [00:32:00] hand, if you're very concerned about AI security next year, most vendors are focused on in pipeline testing of your models to look for things like biases, prompt injection protections, those sorts of use cases.

That's definitely a consistent vendor category. But to me, again, that's not that different from doing DAST and pipeline or SAST and like different kinds of code analysis that are already happening. And so I think it's either you're using AI enough that you need to look at a specific tool for it because the other vendors are too far behind, or you can afford to just wait and ASPM, ADR and CSPM become that's the AISPM use case.

I'm sure AI just becomes a subset of all of that stuff.

Ashish Rajan: Because I guess to your point, at the end of the day, we're all trying to have the AI workload being protected as well, because if someone was to create their own LLM, that's like a hundred million dollar plus just to spend that happens.

Most of us are either doing third party management with [00:33:00] ChatGPT or Claude. There is that aspect. Then the other aspect is also the fact that I have an AI workload that I have to build and manage on my cloud. Then to your point, you go back onto the CNAPP and the runtime security split. And the other piece, which is the data part where, wait, what data are we feeding this thing?

There is that part as well for, and to your point, funny enough, at least while I was still in the workforce, I definitely did not get a lot of joy from DLP. I genuinely feel data security is also going to be something really important for 2025, just because a lot of conversation I have with a lot of people is floating around the part that they have an AI capable application ready, but the data is not ready.

Cause they're not even sure, is this data clean or is this data what we want to feed this thing? What is going to come? So there's a lot of genuine nervousness around this. Maybe that's why we have not seen a lot of production ready application. Unless it's a, Hey, the data itself is public to begin with.

If you, at least for me personally, that's what I've seen. I don't know if you're seeing something different.

James Berthothy: I have a article about LLM security architectures. And to me, LLM security is like a very low [00:34:00] priority until you start having it do stuff. Whether that's like looking up data or caching data from users, like then we're in extreme risk territory because you have an undeterministic thing with access to sensitive user data.

And you're never going to feel good about that. To me, that's where the risk really increases a lot. I'm open to the idea that there's data security tools that can help with this. I've just never been a big advocate of DSPM as like a standalone category, because you think about what has access to that data, like CNAPPs have had access to that data forever.

And they've just slowly matured it as much as customers have felt like it needed to be mature. And that's why it's always been weird to me that it's I need a whole separate tool to tell me there's PII in this database when any CNAPP can also tell me that unless you're going to get really in the weeds.

There's some cool vendors that like, again, we're back in this like runtime thing where it's easy to do the scanning and look at all the tables. It's really hard to then say what services have access to what tables and what data are they accessing? That is super hard data, which is [00:35:00] why I think it comes back to my excitement for ADR and the application runtime stuff.

Cause that's to me where the value is really at.

Ashish Rajan: Maybe then my final question for you then is 2025 coming up. And obviously we've been talking about the, all the different acronyms. What would be an acronym that you feel people should completely drop? Moving forward in 2025,

James Berthothy: I'm always ready for the what's the next big acronym?

Ashish Rajan: I would

James Berthothy: love if, we the ones that drop are all,

Ashish Rajan: You can say that as well. Sorry, I'm going to say you can actually give me that afterward, but is that an acronym that you want to just completely get rid of from the, yeah, it's

James Berthothy: I hate that crap so much. Like it's just so steep.

Every CNAPP has an attack path. And that is what a CTEM is like drawing an attack path to your assets and tying vulnerabilities to it. Tha t is not a new thing. We don't need a whole new category for it. I think it's so stupid. And it's the same. I get, we don't want to say next gen vuln management because it's like next gen is not a cool thing to say, but just that's what it is.

Like it's Vuln management tools, but they work for cloud. And it's a better Data Lake.

Ashish Rajan: What would be an acronym that you think would be created or you're excited bout [00:36:00] for 2025?

James Berthothy: What I'm doing with ADR and CADR is very confusing for people because on the one hand ADR is like a brand new thing that is very unique and exciting and cool and providing much needed runtime visibility to a layer of the stack that just hasn't had it in forever because Raspi was just really hard to instrument and wasn't worth the lift for most people.

So I would say ADR. But because of how quickly some of this Linux stuff is advancing, like CADR is a combination of cloud and application detection response. And it's a little weird because ADR is not quite a full category yet. And so it's weird to already be going to CADR, but because of how quickly the underlying technologies are advancing, I think on the one hand, there's this universal truth, that's the more excited I am about a product, the less likely it will be to sell because it's like way too far ahead and in the weeds of what most people want to like just buy, but if we ignore that caveat, I would love to see ADR, like really get its legs and take off as far as interest in runtime [00:37:00] application security, and then interest in CADR. And we start seeing the early generations of what that product looks like. That is a tool built for the SOC to respond to cloud native alerts, no matter where they happen, whether it's at the application layer, the container layer, the cloud layer.

Just single tools to put all of that attack story together and make it so a SOC analyst can go I'm going to kill that pod. And I feel okay that when I do it, I'm not going to take down the production application. That is the ultimate goal.

Ashish Rajan: I love that. I've got three fun questions for you as well, man.

First one being, what do you spend most of your time on when you're not working on latio. tech or analyzing different softwares from an engineering landscape? What's your favorite activity?

James Berthothy: I have three kids. So if there is any free time, it's that plus time with my wife. But outside of that, it's a gaming stuff.

Ashish Rajan: Oh, fair. Awesome. Second question. What is something that you're proud of that is not on your social media?

James Berthothy: I guess the, that family that I mentioned, it's probably the main thing. I'm sure I have a copy of this to them as well.

Ashish Rajan: Number three, what is your [00:38:00] favorite cuisine or restaurant that you can share?

James Berthothy: We just got back from New York two days ago, so it's all very fresh. You're hitting me very fresh. I think I've always been a bacon cheeseburger guy, so I'll just stick with that. That's always the Actually, I've been asking this question to others as well. I'm curious what your answer is. If you were stuck on an island and you had a choice of food or cuisine, what would it be?

That's so easy. That's so you can't, you won't get anything else. It's that is it forever. Oh, just, that's the =only, oh gosh. So cuisine or food. I feel like I'm trying to cheat. Like I want to pick like a steak salad. That way I have access to a little bit of everything to keep it diverse for a long time.

I

Ashish Rajan: had someone who said Asian fusion and I'm like, I guess that's the cuisine. I, but

James Berthothy: what would yours be? No, that's, I don't know how to not answer that question trying to cheat it, where it's like a steak and salad, or

Ashish Rajan: Totally fine, steak and salad. It's up to you. Yeah, because this genie takes any, it doesn't really, there's no cheating in the game, so you can see whatever you want.

James Berthothy: Yeah, then probably something like that, so that I have diverse options available to make it like a diverse experience on the daily fair. Also I [00:39:00] know I

Ashish Rajan: appreciate that, by the way, where can people find you on the internet of the world for the work you're doing with the newsletter and all of that?

Where can people find and connect with you, man?

James Berthothy: I am mostly available on LinkedIn is an easy way to connect and do that. But latio. tech is the website. The list. latio. tech is the conglomeration of all of these tools. And you can get James's little two second hot take on all of them. And then pulse. latio. tech is the newsletter.

Ashish Rajan: I will share those links over there as well. But dude thank you so much for coming on the show, man. I really appreciate this. This was a great conversation. I look forward to having more of this in 2025 as well. Thank you so much for coming in. Of course. Thanks for having me.

Thank you so much for listening and watching this episode of Cloud Security Podcast. If you've been enjoying content like this, you can find more episodes like these on www.cloudsecuritypodcast.tv. We are also publishing these episodes on social media as well. So you can definitely find these episodes there.

Oh, by the way, just in case there was interest in learning about AI cybersecurity, we also have a sister podcast called AI Cybersecurity Podcast, which may be of interest as well. I'll leave the links in the description for you to check them out. And also for our weekly newsletter, where we do an in depth analysis of different topics within cloud [00:40:00] security, ranging from identity, endpoint, all the way up to what is the CNAPP or whatever a new acronym that comes out tomorrow.

Thank you so much for supporting, listening and watching. I'll see you next time.

‍