Mackenzie Jackson: Hello and welcome to the show where we bring you the latest and greatest in cybersecurity news, research, and leaders. My name is Mackenzie Jackson, and you are listening to The Secure Disclosure. We have an incredible show lined up for you today. We're going to kick things off by talking about the NX breach. To talk about this, I'm bringing on to the show our resident malware expert, Charlie Ericson, and Guillaume Valadon from GitGuardian to talk about the impact that this has had and some very unique insights that GitGuardian were able to get. Next, we're getting a very exclusive sneak peek into the cloud security report that Laciot Tech is bringing out in October. We're joined by James Berthoty, who's one of, if not the leading, security analyst right now, to talk about what is happening in the cloud security space and give us some of those exclusive insights. And then we're finishing it all off with our Cyber & Saki segment, where I get to sit down with Ashish Rajan during Cyber & Saki and continue our cloud theme and talk about the future of cloud security from his perspective. It's going to be awesome, so stay tuned. All right, let's get into our first segment. We're going to be talking about the NX breach. So, NX was a very popular package on npm. It was compromised and malware was installed. This happens quite a lot with projects, but this one is particularly bad. I brought on two guests to explain why we're going to be feeling the reaches of this for a very long time. So to start with, let's bring on Charlie Ericson, malware researcher, to explain exactly what happened in this case.
Charlie Ericson: NX is a package that is an AI-first built platform. It's kind of how they describe themselves. They call themselves smart repos, fast builds. So I've never really used it before, but yeah, it's clearly very popular, right? AI is all the buzz these days. That also is interesting to see in terms of how the attackers actually went about doing their attack, and the techniques they used actually were seemingly influenced by the target that they were able to compromise.
Mackenzie Jackson: Let's get into it then. So, the package was compromised. Let's start off with how it seems the package was compromised. Same old story with the developer token, it feels like.
Charlie Ericson: Yeah. What they're saying in the advisory that they posted was that they believe that an npm token was compromised, which had the publish rights to affect the package.
Mackenzie Jackson: Malware was injected into it. Talk us through what this malware did, how it was being used.
Charlie Ericson: Yeah, so this one is actually quite interesting because initially when I saw the top of the file, I was like, "Wait, this must be a false positive," because what I saw at the top was a variable called prompt, and it had this prompt about going and basically enumerating sensitive files in the file system. I was like, "Okay, well, maybe our classification engine kind of made a mistake here, right?" It's believing it a little bit too literally because it doesn't seem to, right? That's not a thing on its own. But then I looked further down and I saw code related to actually running LLM clients, and then I saw something about publishing a repository on GitHub. I was like, "Huh, how does this make any sense?" It's with a hard-coded repository name and no credentials, right? It will actually try to fetch the credentials from the environment. And what it actually does first, it goes and collects some of the basic system information, right? It will try to get your GitHub token, npm token. It will get just basic system information, but then it has this prompt at the top that says, "Hey, go and iterate the file system to a level of eight in depth and collect all sensitive files and put it into a temporary file." And what it will then do is, assuming you have a GitHub token configured, it's going to go and publish a repository with this specific name, and it's going to Base64 encode all of the things it has taken twice and put that into the repository. This is a public repository.
Mackenzie Jackson: Yeah.
Charlie Ericson: And this is where it gets crazy, right? So let's, like it's worth noting here, right, the fact that somebody's using an LLM as a way of enumerating your system, right? That's pretty novel, right? We haven't seen that before, which makes sense given what NX is. Right, that's a tiny story now compared to the fact that these guys decided that they were just going to, instead of sending it to a remote server that they control, they just publish it on GitHub, all of the data.
Mackenzie Jackson: So, let me just, let's just go over it just to make sure. Package was compromised. They inject some malware, and basically what this malware does was using an LLM, enumerates through all of your system files. So once you install this updated version of this package, it enumerates through all your system files on your machine, on your cloud server, for example, and finds secrets, in particular things like your GitHub tokens, but also your ENV files. And then it publishes all of that not to a command and control – well, I guess GitHub is the command and control server at this point – like it's just publishing it into a public repository for the world to see.
Charlie Ericson: Yeah. So I guess you call it very open-source command and control, which, sure, let's call it that. Yeah, so there's a catch there with the LLM part, right? Even if that doesn't actually do anything, it still collects your environment variables, GitHub token, npm token, right? It has specific logic for fetching those. So when I looked at GitHub and searched for repositories with this name, I saw like 1.4K, 4K, and a lot of those had npm tokens, and of course they had a GitHub token because they could publish that repository.
Mackenzie Jackson: This here is crazy for so many reasons. I cannot wrap my head around why an attacker would do it this way and why they would put secrets in a public GitHub repository as opposed to a private C2 server, but they did. So, what I wanted to do is I wanted to bring on someone to help explain why this is such a big deal having these secrets in public space. And there's no better company to talk about secrets in public Git repositories than GitGuardian. GitGuardian does wide-scale scanning on all public repositories. They found last year 22 million secrets. And we're lucky to have Guillaume Valadon, a security researcher at GitGuardian, to explain to us some of the impacts of why this is going to have a long-lasting effect. Guillaume, welcome to the show. Thanks so much for joining us.
Guillaume Valadon: Thank you. Thank you for having me.
Mackenzie Jackson: So, as we kind of just recapped, the secrets were put in a public GitHub repository. Why on earth do you think an attacker would do this? Is there any kind of logical reason behind it?
Guillaume Valadon: Okay, yeah, my answer will be, I would say, a lucky guess, but first thing, I think it's simple. I mean, the guy did a nice piece of work like stealing GitHub tokens, and valid ones, because that's the way NX works: he needs valid GitHub token to be able to help developers to do that job. So for him it was easy to use the GitHub token to actually upload some stuff to GitHub under the developer account. So, simplicity and also for him it's also a good way to not be traced. So usually when you are trying to trace attackers, you are looking for IOCs, you are looking for IP addresses. So for him it's better to push it on a GitHub public account or public service than to actually push it on a private server. There's no need to buy a specific server, trying to hide it and so on. So I will say simplicity and deniability, and so that for the exfiltration, it seemed also, in the first place, we don't really know how the NX package was actually backdoored in the first place. For the attacker, it looked like a perfect operation; we don't know much about him.
Mackenzie Jackson: In total, how many repositories did you actually find from this? How many repositories that were exposing secrets did you actually kind of uncover?
Guillaume Valadon: I didn't check just before the recording, but when I published the blog post yesterday, there were more and more repositories being published. So when we did the extraction, we found 1,346 repositories, a bit less with actual content, close to only 1,000. But yesterday night there were more and more, not that much, but if you do the query, the singularity repository query on GitHub, you will find a few, or at least yesterday it was a few, and inside it was also possible to find secrets, and some of them were valid. So for me, I don't know why, but it seemed that some systems are still using the backdoor package and are still publishing secrets to GitHub. So it's likely that GitHub will react really fast and try to block all of these patterns. Singularity repositories, the pattern is quite simple. The name is singularity with one instead of I, and then dash with a number. And then inside the repository, you have only one commit with always the same name. And then the file, which is Base64 encoded, the content was one really fun story. So every time you do this kind of experiment, getting data publicly in the wild, you will write your own code to actually get the commits, do the Base64 decoding, and at some point my code broke. So I didn't know why, I tried to debug that, and what I got back was not indeed JSON, it was a YouTube link. And the YouTube link, if you click on it, you would get a Rickroll video. It was really fun. So someone actually pushed some content for like researchers like us at GitGuardian to actually break their stuff or make fun of us, but it was fun. So twice, two people actually uploaded the link to the Rickroll video.
Mackenzie Jackson: So that's a pretty good indication that thousands of applications, of developers, of organizations have had their secrets just exposed in public. And why, why is it so much worse having these secrets exposed in public than it is for like the attackers to get them?
Guillaume Valadon: We say worse than not. So it's worse because anyone can grab the secret: GitGuardian, anyone, governments, other bad actors. And I will bet that other bad actors actually did get the secrets because what we found, that the exposure ranges from like single developers trying to play with NX to big companies, and also we found internal Artifactory instances who have big names there. So it seemed that it's not only the guy that did the supply chain attack in the first place that had access to the secrets. And yeah, publishing this stuff publicly is worse, but it's worse as a pure defensive story and side of the story because it means that you don't know actually who got your secret. If you are trying to, on the other end, to understand the full story, trying to, as a developer, trying to understand if you were targeted, I mean in that case you know because the repository was created under your GitHub account, to actually know, it's really easy for me to check if I was targeted. I can just go to github.com/myname/singularity-repository-0-1 and so on. So for me, it's easy to check. So this is, what do you use in English? Double-sided coins. There's the public exposure, which is really bad and that will make the blast radius bigger than for the single attacker. But on the other side of the coin, you have also an opportunity for people and developers to actually check and quickly check if they were targeted, and that's really good for what we call a blue team, especially in big companies, to be able to check if their developers were targeted by this attack. And that's part of what we do at GitGuardian. We're able to map usernames to companies and that's a product that we sell. And for us, it's really interesting because we can actually warn customers that their developer was targeted. In the case of secrets, there's also in secret and security, there is also people trying to avoid the reality. They will say, "Yeah, maybe the attack did not work, or maybe the attacker did not actually look at my secret, or maybe the upload did not work." So in that case, we know, so the data was uploaded and contains secrets, so it's not possible to deny and say, "I don't care, I will not act, I will not do revoke." So you need to revoke because you know.
Mackenzie Jackson: Let's get into some of the juicier stuff now. What type of secrets did you actually kind of uncover in these public repositories? What were the main secrets and what were kind of some of the outliers that you saw? Did you find anything really terrifying?
Guillaume Valadon: So I, we call them the usual suspects. Usual suspects in the sense that's what I do at GitGuardian, security research. I come from a background of doing offensive security for pentesting companies, for French governments. And what I could call suspects is that secrets, valid secrets that can be, let's say, weaponized or VCS. In the case of this data set, that's only in many GitHub, I think I found few GitLab tokens. Cloud, we have AWS, DigitalOcean, so it means that it's likely that an attacker will be able to pivot into some cloud infrastructure, which is unfortunate. We have databases. Some of them are related to production because you can see the product keyword in the name. And something again, big suspect, Artifactory. We have valid Artifactory tokens in the data set that are valid for really, really big companies. So what, it's not a big surprise because it's the kind that developers will use on a daily basis to do their job, to push code, to actually modify the infrastructure, to put data in a database, and finally to upload or download artifacts. So nothing is really standing out. But I guess that for developers, it means that they will need to take big care of checking what is loaded in their environment variable, or what was loaded is targeted, and try to remediate and to do so in the next few hours or minutes. We'll publish the secrets that we found, and something that we call "My Secret Leak," which is a database of secrets that we found that's leak secrets that will help people to check if they actually, they were actually targeted. There's a command-line tool, which is called GGC, that you can use to actually check if the secrets are in our database. You don't need to, and you will not actually send the secret in clear, that's protected with a hash, and you send the hash and we say, "Okay, we actually seen this leak or not."
Mackenzie Jackson: When we first started looking into this, we looked on GitHub for repositories named singularity repositories, but one, and we found thousands. Shortly after that, they had all been wiped. And then throughout the day, more ones kept coming up. They would keep getting deleted, more ones would come up, they keep being deleted, etcetera, etcetera. What was actually going on here? Who was deleting these repositories?
Guillaume Valadon: Yeah. I don't know if GitHub is doing anything about it. I mean, I know, I don't have any precise information, so it's just again guessing. I've seen two different things going on. First one, some repositories are deleted. So if you go and try to access them, you'll get a 404 page. So for me, it's likely that the developers that were actually targeted by the attack decided to just delete the repositories. So that's my first guess. And the other one, I think that GitHub is doing something about it, because from time to time, when I try to access a repository, you will see that it's deactivated. And in that case, you don't get the 404 message, you have a formal and a proper message from GitHub stating that the repository was deactivated. And I think that's a good move from GitHub if they're doing that, because it allows developers to actually check if someone created a repository name Singularity Repository under their name and then trying to get the secrets in the blob in the Base64 blob and then trying to remediate.
Mackenzie Jackson: Okay, so GitHub or someone was deleting these repositories. Does this actually help? Does this like resolve the issue? Are the secrets now gone?
Guillaume Valadon: Basically, what we see at GitGuardian since day one, it's deleting a leak is not helping at all. I mean it helps not the leak to be seen, but the secrets are still blankly available to people that downloaded them in the first place, and also they're still valid. So the first thing you need to do when you actually leak, or actually in that case, you didn't leak anything, but someone took your secret, put them on GitHub, you need to have a look and do some kind of inventory and revoke and rotate everything. That's the only way to actually protect yourself from what happened yesterday. Identify the leaks and rotate the secrets.
Mackenzie Jackson: I want to put you in the position of a black hat hacker now, but I want to ask you the question, what would you do to kind of take advantage of this? How would you find and use these secrets?
Guillaume Valadon: Going back to the usual suspects category for the VCS one, the first thing would be to actually check what can be accessed and download more code. And what we know at GitGuardian, if you have more code, you have more secrets, hardcoded secrets, because that's the way people do hardcode secrets. And then using these other secrets, you can pivot for the cloud. You can spawn instances in the first place and trying to, so some people will do cryptomining, but it doesn't get you much money, but some attackers do that, or they can just destroy your cloud infrastructure, that would be the nightmare scenario for cloud. And for databases, they can just get your data and try to actually leak or ask you for money. Obviously, they can also go for the ransomware stuff, trying to encrypt your data and ask you money to get it back. And for the artifact, it could be the same thing that started the NX attack, it could be a supply chain attack, taking your artifact, putting bad code in there, and then trying to pivot and do lateral movement into your architecture.
Mackenzie Jackson: Well, Guillaume, it's been an absolute pleasure to have you on the show. I hope to have you back again, hopefully in less crazy situations, but really I really enjoyed it and thank you so much for coming on and sharing your knowledge today.
Guillaume Valadon: And thanks for your time, and I hope that all of your listeners will like the content, and again, if you have any question, reach out to us. We are here to help.
Mackenzie Jackson: And now it's time to quickly mention the sponsor of this show, Aikido Security. Aikido Security is your complete code-to-cloud security solution. Aikido secures everything from the first lines of code that you write all the way to your cloud environments. Aikido's superpower is noise reduction, getting rid of those pesky false positives. I would love to tell you about all of its amazing features like its reachability analysis on dependencies, breaking changes, AI autofixes for your code, containers, and cloud, and even AI-powered human-written code quality checks. But I just don't have time, and I want to get back to the show. But thank you, Aikido, for sponsoring this podcast, and make sure you check them out at aikido.dev and sign up for free and check it out today. Next, we're getting a very exclusive sneak peek into the cloud security report that Laciot Tech is bringing out in October. We're joined by James Berthoty, who's one of, if not the leading, security analyst right now, to talk about what is happening in the cloud security space and give us some of those exclusive insights. James, thanks so much for joining me here today. It's great to have you on the show.
James Berthoty: Of course, I appreciate to have been interviewed by Mac multiple times. It's a treat and a pleasure for me.
Mackenzie Jackson: Well, one of the reasons why I love to have you on all of my shows is that you're someone who is definitely not afraid to share honest opinions, which is great.
James Berthoty: Yeah, it's a fun dichotomy because I generally just try to be pretty nice. I don't know, but I know people get very intimidated by it when I do analyst interviews with people. It's very weird.
Mackenzie Jackson: Well, let's get into the topic at hand. You have a report coming out from Laciot Tech, which is looking at the cloud security landscape as a whole and kind of the trends and the leaders in this space. It's coming out in October, but I've coerced you to give us a sneak peek into some of the findings that you've discovered. Let's start off there. What are kind of the trends that you're seeing in the cloud security space right now that are kind of driving your findings from this report?
James Berthoty: Yeah, I think, you know, I did a big piece last year on CNAPP, and I think it was called like The Past and Future of CNAPP, and it ended up being mostly historical on how CNAPP developed because it was always really interesting to me how the first out the gate people were focusing on the things that I think mattered the most from a security perspective, which is like workload protection, very nerdy runtime stuff. But then really what the market wanted was high-level overviews into your assets. Like it was people learning how the cloud worked and doing security as part of that learning process, more than it was like, "Let me buy the thing that's going to give me the most block active attacks crazy security development." And the main goal for this report is, "What is the future of cloud security in light of we're sort of past that posture stage?" And the CNAPP acronym, I think, has really underserved what cloud security is for a very long time. And so the goal of the report is to break CNAPP into major categories that I think will continue to last longer and let us be a little more honest about what they're doing, right? Because every CNAPP has every feature on paper, and the analyst confusion is, you know, it's easy to check the box and say, "Oh, I do CSPM," "Oh, I have a SAST scanner," "Oh, I do SCA scanning." But what it really means to make that a usable product is very different, and I'm hoping that in the report we can focus on bringing out the things that vendors are doing that make them genuinely helpful or unique within those categories and bring out what they're really focusing on.
Mackenzie Jackson: You talked about kind of the categories of CNAPP. So I guess a year ago, maybe two years ago, it was just kind of like CNAPP, and it was like people were just kind of discovering it. So like, what are kind of the categories within that that you're seeing emerge and what do they kind of cater for in different areas?
James Berthoty: Yeah, I think that I have always drawn a strict line between the vulnerability management and scanning aspects of CNAPP and the runtime active threat detection, responding to security incidents, there's a hacker in my system, elements of CNAPP. Because generally providers have not been super good at both at the same time. They tend to be one or the other. And I think we're just seeing that get more and more exacerbated. When it comes to acronyms like CEM, which, you know, Gartner has a whole thing about how continuous threat exposure management isn't a category, it's a process, whatever. But at the end of the day, you have all these tools that essentially just do vulnerability management, and they build attack paths by looking at relationships between assets and then ingest vulnerability data attached to those assets and allow you to do prioritization, ticketing, incident or vulnerability response. And really that's how that whole system works. And I think we've seen those turn into multicloud plus on-prem systems. Like it's no longer a cloud protection thing in isolation. It's more, "We're going to take your, maybe you've got Qualys somewhere, Tenable, you've got Wiz, you've got Orca, like you've got all these tools. We want to suck up all that data and create a vendor agnostic vulnerability prioritization platform." That's one development. And then on the other, on the runtime development, you have this wave of application detection response providers who are bringing a level of application visibility that just didn't exist before with eBPF, and the runtime potential is just massive. And so that market, I think, is like, I just think of it as, "What's the best runtime, what's the best workload security tool I can buy to run and do incident detection, detect hackers getting into my stuff?" And then, "What's the best vulnerability management tool that I can have?" And really that's the separation that I see happening. And then at the end of the day, I think providers are finally starting to realize like, I don't know, it depends on the provider how much they're willing to admit that their AppSec offering is sort of a joke. And that's, some of them are more honest than others. And every time I've been doing this long enough now that like marketing people will leave companies and go to other places and then they can admit that it wasn't a real offering, but, you know, that's fine.
Mackenzie Jackson: Marketing people in security kind of stretching the truth. I never would have thought, James, I never would have thought.
James Berthoty: It's a tough position. Honestly, it's not usually them. Like, people internally have good senses of what's real and what's not, and usually they're complaining about it. It's really driven so much of the security industry is driven by investor pressure, which is why you see everyone is now AI whatever, no matter what they were doing before, when no one's asking, like, it's just, 0% of my practitioner calls are like, "What AI tool can I use?" Like, that's not, it's not a relevant answer to a problem they're having.
Mackenzie Jackson: Okay. So, strap in because we're going to go down a path that I know you've got opinions about. But you're talking about kind of things that are real, things that are kind of marketing, let's call it marketing BS, and AI. So we can kind of bring this together with what you're seeing out there. Black Hat was fairly recent. You walk through the vendor hall as you said. Every single person has AI front and center. What is actually in the cloud security space? What is working with AI? How is it, how is it being used? And what are you seeing out there that you can kind of look at and you analyze and think, "That's BS"?
James Berthoty: Mostly it's just the framing of it that's BS. It's like this, you know, you add an incident summary capability and suddenly you are like an AI leader in cloud security or something. That's the part that doesn't make a lot of sense, is it's not that it's useless, like there are, it is useful to have, especially if you have these complex multi-step incidents that are happening. And the level of technical depth that a security engineer needs to have in the cloud is pretty crazy because if you think about like an incident can start in a web application, pivot to a container, and then pivot to cloud resources. From a developer perspective, those are usually like three different development teams that are touching it, but a SOC analyst is expected to be able to respond to that incident in real time. And that's where like the AI is genuinely helpful in saying like, "Here's what happened first, here's what happened second, here's like general information on the environment." Like it's summarizing and giving actually helpful data to that. I just don't view that as like, "We're reinventing everything with AI," whatever. Like it's a better incident summary, which is great and that's useful. I distinguish between AI-native companies and people who are buying into AI after the fact. AI-native is like you're a startup that tried to tackle this existing problem from AI from the ground up. And there's a couple of those in the vulnerability management space who are doing everything when it comes to a vulnerability and a reachability analysis where for most tools it's like, "Here's all the data of a vulnerability, like the asset context, is it network facing, is it loaded?" And that's how you create like, "Is this exploitable? Guess?" But an AI-native approach, there's a couple of vendors who are looking at like, "How can I give an agent access to like the AWS CLI and have them try to investigate on a CVE by CVE basis?" "Here's the CVE, let me read about that. Now let me go and see if this instance is accessible. Now let me try to check what is running on the instance." And whether or not that approach is actually helpful, I think is up in the air. Like, it makes some really cool demos, but I think that's a genuine AI innovation. That is an AI-first approach more than like, you know, "X vendor is now AI-native because they have a summary capability."
Mackenzie Jackson: With the AI-first approach. You know, you kind of mentioned in there, and I'm sure you'll probably expand on this in reporting, that it's unproven yet that it's going to be super, super useful. Do you think there is a lot of room to grow in there? Is there kind of, is it up in the air, or do you think that kind of the traditional approach to cloud security that we've been doing for the last couple years is potentially going to be the way that we secure things into the future?
James Berthoty: Yeah, that's a great question, and I think it, it, I separate, it goes back to that separation between the posture and the runtime side. On the runtime side, I think AI is way less useful because the volume of log data you're dealing with. It's not like you can take, you know, if you're streaming multiple logs per second from an endpoint across thousands of endpoints, you can't just ask an AI like every five logs, "Is an attack happening? Is an attack happening?" Like it's just not a scalable or helpful detection methodology. But it is really interesting on the vulnerability side. The challenge with vulnerability management is that every vulnerability is so unique. Like even, I, you know, you were posting about the latest, is it NX malware today? That's a really unique malware vulnerability, and every single one of these is like such a unique, how do you exploit it? How do you, what configuration has to be in place to do it? And I think that's where AI can really do some good investigative work. I mean, even the malware detection that you guys are doing being heavily AI based. Like that's, it, it's great at that. It's great at static analysis. It's great at detecting fishy-looking things, which is what SAST scanners have always been trying to do is like, "Hey, this looks bad." And that's sort of what AI is really strong at. And so to me, it just really depends on, I think there's a lot more potential for AI on the vulnerability management and like static analysis front than there is in anything to do with like runtime detection pieces.
Mackenzie Jackson: No, that makes total sense, and it's definitely with like the computational requirements of AI at the moment. What you talked about the logs is like totally true. And that, and I do worry in this kind of AI-first world that we're getting AI to do tasks that's beneath it, that static rules would be so much more performant, and, you know, I imagine, but you do it with AI so that you can say that you do it with AI and then you're an AI-first company even though the value isn't there. In fact, it's probably worse.
James Berthoty: There, I mean, there's a ton of this with, there's a lot of like open source like GUIs and report dashboard stuff with AI that I see a lot of people running towards. And I don't know, like on-the-fly report generation, like it's always okay, but it's never as good as like a tunable search that I can turn into a graph. And that's where I think, yeah, the AI revolution is not as big or immediate as a lot of people sort of want it to be, where I'd rather just have the AI translation interface between, you know, proprietary vendor query language and natural language. Like that's more interesting to me and helpful than, "We've re-envisioned everything from the ground up, like the new product is a text box and now type whatever you want." And then you're like, "Okay, I don't know what I want. Like I want to browse the assets and figure out stuff."
Mackenzie Jackson: So, secure my app.
James Berthoty: Yeah, that's what I want. Honestly, yesterday I did a demo. That was, that was literally the demo was typing "secure my app." And then...
Mackenzie Jackson: James, I'm conscious of your time, but I do want to ask kind of a final, a final question to you, and I want to go forward. From what you've seen in putting together this report, we're four years down the track. What feature or what capability has won a company the, like the race? What do you think in four years is going to be something that will be very significant and will kind of create leaders emerge from or change leaders around?
James Berthoty: Yeah, this is really hard. I always have to split out like the James opinion and what I think is really cool from the market-winning opinion, and those are unfortunately very different things. But my hope for, for both the technology that's unavoidably relevant and cool, it's just, it's hard to market and it's hard to position well, is the application detection response stuff. And how that fits into what I call CADR, which is just doing every like cloud threat detection, but you're including the application layer. Like there are so few vendors doing it because it's so technically challenging to do, and the results are so meaningful that it's, it's hard to describe until you use one of these tools and like see, "Oh shoot, like every vulnerability finding is interesting because I, I can see the functions of code that are executing on these vulnerabilities." That really the runtime application context, because RASP was so difficult and time-consuming to implement as a solution, has been just so overlooked. And so that's the technology that even if it doesn't create some multi-billion dollar, you know, thing, which I think CADR could, but by itself, I think ADR is in a tough position to do that. The value that practitioners get out of it and the technological difficulty of doing it is unquestionable. So it's the thing that I'm just consistently the most excited about, impressed by, and all of that.
Mackenzie Jackson: No, that's awesome. Well, James, thanks so much for taking the time. Really valuable. If people want to find the report when it comes out in October, how can they kind of get on the waitlist or be notified, or where can they see it when it comes out?
James Berthoty: You can either go to the existing Substack, which is pulse.laciot.com, but I should be plugging the brand new and improved laciot.com that I just turned on a couple of days ago. So it's sort of, you know, it's in soft launch mode. I haven't posted about it or anything yet, but that will be the premier location to find the report.
Mackenzie Jackson: The premier location. I love it. Exclusive here. That's, you heard it here first on The Secure Disclosure. Thanks so much, James. I can't wait to have you back on the show, and I really appreciate all your insights.
James Berthoty: Thank you so much for having me.
Mackenzie Jackson: Now, it wouldn't be an episode of The Secure Disclosure without Cyber & Saki. This is where we take a key security leader, and we take them down to the Cyber & Saki bar. This is our last Cyber & Saki segment from our makeshift Saki bar, but it was a really good one if I don't say so myself. Ashish Rajan needs little introduction. He's the host of The Cloud Security Podcast and The AI Security Podcast. He is a big influencer in security, but he is also a practitioner, which makes him pretty unique for his insights. So, I got to sit down with him, drink some saki just before he got on a flight back home to the UK to talk all about cloud security and the future of cloud security. It's an amazing segment, so make sure you stay tuned.
Ashish Rajan: Thank you for having me.
Mackenzie Jackson: Oh, welcome. You're kind of like a bit of a celebrity, so thank you for coming on to the show, but maybe for someone doesn't know who you are, maybe have a quick introduction of yourself.
Ashish Rajan: For the two people on the internet...
Mackenzie Jackson: My mom hasn't met you yet.
Ashish Rajan: Okay, we need to change that for sure. So for, my name is Ashish. I've been in cybersecurity for a little over 14 years. I've been a, well, I've done, I started my career in identity, worked through AppSec, operation security, architecture, cloud, did a lot. These days I primarily talk about cloud and AI security. So last couple of roles for a CISO. Left that, now I'm a co-founder of a company called Techri.io, which is this AI and security advisory company. And outside of that, I run two podcasts called Cloud Security Podcast, and then I co-host AI Security Podcast with Caleb Sima.
Mackenzie Jackson: They're fantastic podcasts. I'm not going to lie, they were definitely the inspirations behind this. So, I'm glad to have the goat onto the, onto the show.
Ashish Rajan: I appreciate that. Thank you.
Mackenzie Jackson: But we're going to start off, we're going to have some saki here. Now, we are, we've gone for the 0% saki option. Now, saki, as everyone knows, is from Japan.
Ashish Rajan: Mhm.
Mackenzie Jackson: Brewed in different regions in Japan. This saki is from Arkansas.
Ashish Rajan: To make an American, I'm like Arkansas in Japan.
Mackenzie Jackson: The great brewing state in Arkansas.
Ashish Rajan: I mean, of course.
Mackenzie Jackson: But do you know what? Is that kampai? The Japanese saying cheers. Are we doing kampai?
Ashish Rajan: I, I should know this, but I have zero idea.
Mackenzie Jackson: It's kampai.
Ashish Rajan: Oh, I think you were right. It is very fruity.
Mackenzie Jackson: Yeah, it is fruity.
Ashish Rajan: It's in a nice way.
Mackenzie Jackson: I think I quite like it. I quite like it 'cause it's refreshing.
Ashish Rajan: Yeah. Yeah. And I think especially if you don't want alcohol, but you want that similar refreshing taste, that's a good one.
Mackenzie Jackson: Oh yeah. Yeah. Everyone's kind of surprised when they have it. I got to say, everyone kind of likes it. But let, let's get into the, let's get into the topics. So you've been kind of dealing in cloud security for a really long time. From your take of the market, what's happening right now? What is the biggest threat that we're seeing currently with cloud security?
Ashish Rajan: I would start with maybe a better way to explain this is cloud security as a space over the last couple, I want to say last decade, has evolved quite a bit. There, there's a problem statement we started with, which was visibility to begin with.
Mackenzie Jackson: Mhm.
Ashish Rajan: And around that time, the biggest quote unquote threat people had was misconfiguration, S3 bucket open to the internet. That was used to be the very common theme.
Mackenzie Jackson: Like endless S3 buckets being pinged. Yeah.
Ashish Rajan: Yeah. But now I, I say 2025, most of the organizations that I speak to, they have kind of figured out that, figured out that part of S3 bucket. Like the S3 buckets that are open to the internet now are intentionally open to the internet. So that, that kind of problem has gone away. So now it's a lot more about the complexity of, "Hey, I have a resource that has a vulnerability because it's using an OS that is perhaps using open source library which is not patched, and then that is also given permission to an S3 bucket." So because that resource is facing the internet with a vulnerable OS or application, with an access to an S3 bucket, it almost has to be a kill chain for lack of a better word. It's not as simple as, "My S3 bucket is open to the internet."
Mackenzie Jackson: Yeah.
Ashish Rajan: It's almost like you need a, you need awareness of cloud security to, or at least cloud resources, to know that, "Oh, okay, these one, two, and three resources, if you interconnect this, this is how you would form a kill chain today." So the threats are a lot more complex, they're not as simple anymore. But in terms of, we can't talk about anything without talking about AI in 2025. So the people who are at least SAAS providers, who have a lot of domains that they manage, they have seen an increased traffic of AI bots coming in. Now AI bots, not just your direct AI bots, are different from your regular bots because they are smarter, quote unquote. The, the point being, and I was, the first time I heard like, "What do you mean smarter BS as well?" So they're using AI bots for doing SMS frauds. They're using AI bots to doing DoS in a much smarter way. They have coordinated attacks, there's nation state. There's, it's taking many forms, but AI hasn't gotten to a point, and we talk about this all day on AI Security Podcast. We haven't gotten to the doomsday part yet, where it's automatically going and doing something in the cloud environment or in any other environment for that matter. Someone has to still trigger and validate and get to the bottom of a zero day before you can actually get to something.
Mackenzie Jackson: 'Cause that seems to be like the next step. There's a lot of talk around AI pentesting, which is kind of like this buzzword. It's got agentic models kind of being able to go in and attack things. Do you think we will get there, like, and, and this, and I, I guess from this point of view, maybe not looking at it from a pen testing side, but from an attack side, will there be agentic, do you think there will be?
Ashish Rajan: So actually, funny enough, because we are recording this as Black Hat and Def Con. Def Con had DARPA's competition, I think it's called AI CC, which is basically a competition where you enter, you win a million dollars for producing a fully autonomous agentic AI attack and remediation AI agent. And I may be butchering up the description completely, but essentially the idea is that every team would create a piece of AI software or agent or whatever that turns out to be. They'll hand it over to DARPA, which is the Defense and Something Something of America. They run that every year. They, they'll give it to you in an airtight airbox environment and basically DARPA would go ahead and trigger it and it would just let loose on an environment and it needs to find out zero days, identify what they are, and fix them as well with a certain amount of accuracy. So the top two teams, I made it, I think it was Team Atlanta and the Trail of Bits. The interesting part here is that to your point about how much of AI can do this, the team that won was heavy on AI usage, and I think, I don't know if the rumor is true, but essentially they ended up spending about $100,000 on the inference of it, which kind of works out if you're getting a million back for 100,000, it's a...
Mackenzie Jackson: You want to be pretty confident that it's going to work.
Ashish Rajan: Plus, in, in, in Vegas terms, that's a good gamble. Okay, yeah. Well, we're not going to, I mean maybe, but in this scenario, the team that won, I believe the accuracy was quite high, over 50% accuracy. It found zero days and patched them as well.
Mackenzie Jackson: Wow.
Ashish Rajan: So, and obviously this is, I did not go into the details of it. This is me hearing it from multiple people because I was asking the same question as you are, because I was curious from an AI Security Podcast perspective as well. Like, I say how far are we from this thing? Like can this actually happen? And then the follow-up question to that was people who are experienced, like people like you and I and others who are in this field probably watching or listening to this.
Mackenzie Jackson: That's, I felt pretty like you and me and you. We've got a few grades to prove that we have certain time on this.
Ashish Rajan: But so there is, there is going to be no console of script kiddie after a while.
Mackenzie Jackson: Yeah. This, yeah, it's the, the AI power is going to completely revolutionize.
Ashish Rajan: Yeah. Like we don't have to be a Metasploit expert. Yeah. We don't have to be a Ncat or whatever the command line used to be. I don't have to, like the script kiddie concept would just go away after a certain point. Where it would become interesting is that is it a combination, and this is what the whole debate we had was, is it a combination of an experienced person with an LLM having higher productivity to be able to find more interesting things, or is it the fact that I just have basic information and I've never done a pen test, but I have a great LLM provider or LLM service that I just go, you know, "Go attack" and it just goes and does it with, with and obviously the question is about accuracy and all of that, but keeping that aside, your modern script kiddie is just going to basically subscribe to a service of this LLM and go, "I want to find all the SQL injections in the world."
Mackenzie Jackson: So, I mean, this is kind of like terrifying for me in two very different ways. So the first way that this is terrifying is like, "Oh my God, we're going to essentially have extremely high production, high-value attackers just roaming around everywhere in the form of these bots." All right. But then you kind of look at it at the other side of things and it's also kind of terrifying because it's like we're also going to have something similar on the defensive side, presumably. Yeah. So what, what's the role of cloud security engineers in the future? Like, how does, like, how, you know, it's, it's kind of like at one place we're going to have like super engineers and we're going to have super attack and like it's that, what, what happens when an unmovable object meets an unstoppable force, right? I feel like I feel like we're going to, is everything going to explode?
Ashish Rajan: I, I didn't share the even more scarier part: the DARPA thing that I spoke about, that thing is going to be open source.
Mackenzie Jackson: Okay. Fun.
Ashish Rajan: So, so that, that was a condition of going into the competition as well, that it has to be made open source. So that means is both defense and offense have equal opportunity.
Mackenzie Jackson: Yes. Yeah.
Ashish Rajan: But the challenge is the, the defense obviously would have a lot of red tape around them for how far can they go with it, where the offense team would not.
Mackenzie Jackson: No. Yeah. I think that's fair to your point about like unstoppable objects, like, you know, that's kind of where that, and I think it is true to an extent. But bringing it back to your AppSec people, cloud sec people, GRC people, SOC for that matter as well. It would definitely, and it is already enabling quite a bit of productivity for a lot of people. The percentage of it is different for a lot of people. In terms of, if you are a really large organization, you maybe as a SOC level one, you are looking at a mountain of cloud security logs, whether it's on AWS, Azure, Google Cloud, and now maybe AI worker in there as well. Maybe if you're an AppSec person, you're also going through a lot of SAST results, which used to be a pain in the ass as well for a lot of people, with the number of false positives. So you, the level is getting abstracted quite a bit in terms of how far you can get with it. But I still feel because we have a lot of red tape, we would still be slower. So there is a lot of opportunity.
Mackenzie Jackson: Yeah.
Ashish Rajan: But whether the opportunity can be achieved within an organization is where the big question mark is. So I'm still optimistic that it would happen. It's an open source thing, and we've always been very open source friendly.
Mackenzie Jackson: Yeah.
Ashish Rajan: And at least as engineers, we have been. So I'm, I'm hopeful.
Mackenzie Jackson: If we stop kind of looking too far into the future and have a look at where we are right now. In your work with lots of, like you have knowledge of lots of different vendors, you're pretty aware of all the tools and everything that's happening in the space. Where are you seeing the biggest implementation of AI? What's having the biggest impact in cloud security at the moment where people are kind of, because as I think it's a little bit different now, but I think even just a year ago, when people were implementing AI, it was mostly still gimmicks. Like we all could understand the power behind it. We could all see that it was going somewhere, but it was mostly like, "We're providing more context on alerts," and it's kind of like, you know, like, you know, it's like, "All right, but you could have written documentation to provide that context too, right?" You know, that's fine. But do you really need AI for that?
Ashish Rajan: Yeah. Yeah. But, but we are at a point now where I think it's fair to say that there are some pretty substantial AI tools in the market or features, and that what are you seeing that's hitting it hard? I think the ones I would say hitting hard from a cloud security perspective would be like we got to a, to a point, the, if I go back to the visibility examples I gave earlier, you got to a point where now you are able to see what resources are on the internet or misconfigured, whatever. You can even see the kill chain as well to a large extent. Where as an industry, cloud security was coming short was we had 10,000 of those.
Mackenzie Jackson: It wasn't just I had one of those kill chains, I had 10,000 kill chains to go through to figure out which one should I focus on today.
Ashish Rajan: Now we're at that stage two what you said. We have the context for what resources are publicly available and misconfigured. What is the kill chain that is basically impacting this and could potentially be exploited? But the, the, the complexity comes into the fact that we have 10,000 of these.
Mackenzie Jackson: If you're a large enterprise, you have 100,000 of these.
Ashish Rajan: Yeah. You still need to narrow it down. And the, I guess the icing on the cake is even if a vendor was giving you all these, um, kill chains in a list, even if it's 100,000, you still had to apply your own risk matrix on top of it to know that yes, my so-and-so vendor has called out that my S3 bucket, which is linked to an EC2 instance, which is linked to blah, blah, blah, is vulnerable. But it turns out that EC2 is actually private and the website is having that broader context. So what a lot of people are doing with AI is they're using AI to enrich that information, which is what AI is good at. It has, it has the ability to consume a lot of data, give you something sensible. So they're using AI for that, where you're able to reduce that to identify what is my top priority out of the 100,000, if I only have a hundred to look at. That's a much more reasonable perhaps to look at. Maybe we have the right team for it. People have had with cloud security is that you find a vulnerability. You know now which one you want to fix. You somehow are stuck in this loop with your development team for, "Hey, development team, can you give me some time in your next sprint or this sprint?" That's where most of, but that's not a tool problem as well. That's more of a process problem. And so realizing this, what a lot of people have started doing is now they're having the ability to go shift left, which means they can allow you to have a pull request being created with that information that was generated by AI for, "Hey, potentially if you do this change on your Terraform template, that would resolve it. Let me just create a pull request for you, which you can review and attach the pull request."
Mackenzie Jackson: Yeah.
Ashish Rajan: So now you're more in line with where they are. So I think that's where the AI power is coming from, where it's increasing the amount of integration people are having. It's also enriching the information that perhaps you had to create your own matrix for. The third one, which is another set of, um, I guess organizations, where they had migrated a lot of the cloud security alerts to security operation teams. Security operation teams are figuring out that, "Hey, I've, I've done an amazing job at being a data center security operation person. I can find a zero day with my eyes closed. But when it comes to cloud, I don't know what S3 is. I don't know what EC2 is. All these acronyms do not make any sense to me. But now you're telling me I need to look at Amazon, Microsoft, Google, Oracle Cloud and every, make sense of all of it together as well." I think that's where AI is helping quite a bit as well. So a lot of people who are doing the SOC automation with AI, a lot of them are focusing on the fact that actually we can provide you that context.
Mackenzie Jackson: Yeah. And I mean, even though you still as a security operation person would still need to know a bit about the cloud just to where the logs are, what logs are important, all that, but beyond that, you don't need to understand. You can ask the question, "What is an S3 bucket? Why do I care? And why is it important for it to not be public?"
Ashish Rajan: Yeah. And I remember like, and it's these cloud systems are so complex and so big now. I remember, and this is years ago, so before, but I had to move from GCP to AWS, and it was like, "I've never felt more stupid in my entire life."
Mackenzie Jackson: Then trying to do.
Ashish Rajan: Yeah. The funniest thing is it, it feels like it's just a different, like if you know how to drive on the left hand side with the left hand steering wheel, you feel, "Oh, I can do the right hand wheel." 'Cause I mean, this is obviously a European example as well. Like if you go to UK or Australia, we're all driving with the left hand side. Yeah. But in everywhere else in Europe and in America, you're driving with the right hand side. Yeah. You, you, I mean, as a European, sorry, as an, as an Australian or British person, I come into America, I can drive this car. You get on the road, I'm like, "Oh my God." Like this is completely different. And it's not like it's not on the highway that you get in trouble. It's when you're trying to turn down some back alley.
Mackenzie Jackson: Oh, yeah. Or the roundabouts.
Ashish Rajan: Yeah. Yeah. It's like the exact opposite of your roundabout. It's like you're looking the opposite way. And then I mean, and there I mean, but I use that analogy because a lot of times a lot of managers have asked their team for, "I mean, you know AWS, right? How difficult can GCP be? You can be on, I mean, the same compute, same storage."
Mackenzie Jackson: Yeah.
Ashish Rajan: "Yeah, whole different story."
Mackenzie Jackson: Yeah. Yeah, you know, Python, just look at JavaScript. Yeah. That's right. Yeah. Yeah. Yeah. We're coming to the end. But I, it's been a fascinating topic. It's been a little bit terrifying. I'm, I'm not going to lie. But I do always like to play a game with people. We need some more saki for this. We'll, we'll do a refill.
Ashish Rajan: Kampai.
Mackenzie Jackson: Yeah. The game is pretty simple. It's called Would You Rather, and I'm going to give you two options. You have to pick one. Okay. Would you rather have an AI system at the most advanced capabilities of where we are right now, manage all your cloud infrastructure, or you can never use not only AI but also security tools in your cloud infrastructure. You have to make sure that you set everything up manually perfectly. What would you rather?
Ashish Rajan: Well, I would rather have the AI take over.
Mackenzie Jackson: Really? Okay. All right. Bold move. Futuristic.
Ashish Rajan: Yeah. I, and I definitely feel, and I know I spoke about some of the scarier parts as well, but in reality I think the plus definitely outweighs the negatives around it.
Mackenzie Jackson: Yeah.
Ashish Rajan: And I think that's where I'm like, "Well, 'cause I can then try and solve better problems than the monotonous ones I may have with 100,000 alerts."
Mackenzie Jackson: Would you rather have your application be running, running out there in the internet with absolutely no firewall, so completely open?
Ashish Rajan: Mhm.
Mackenzie Jackson: Or, but you're able to use security tools whilst building your application? Right. Okay. Right. Or no security tools? You're just going to trust everyone's coding perfectly. No CI/CD pipeline. Just straight out there, but you have a firewall. What would you rather?
Ashish Rajan: Oh, you know what? Even though I, I lean on the A option, but just to be controversial so people have some hate comments, I'm going to go, I'm going to go for the B option. I'm like, "No, no, leave it. Just leave, put a firewall on. Everything should be fine."
Mackenzie Jackson: I mean, you can't get in, right? What, what's the problem there?
Ashish Rajan: Totally. Totally.
Mackenzie Jackson: Well, I do want to give a quick another shout out to your podcast, The Cloud Security Podcast and also The AI Security Podcast. So there'll be links for that in the, in the description for everyone that wants to check that out. And I thank you so much for coming here, spending this time whilst we're at Vegas to come in here. You've got a flight to catch, so I won't keep you too long, but it's been brilliant, and I really appreciate you coming.
Ashish Rajan: Thank you so much for having me. I really appreciate that. Thank you.
