RunAs Radio · 2026-07-01 · 37 min
Key moments - from our scoring
Substance score
63 / 100
Five dimensions, 20 points each
Mackenzie Jackson, field CTO at Aikido Security, discusses how large language models are fundamentally changing the threat landscape for software supply chains. While malware creation historically required high technical skill and resources, LLMs like DeepSeek and White Rabbit Neo have eliminated that barrier - leaving only malicious intent as the requirement. Jackson walks through real-world attacks: Josh Junon's phishing compromise affecting packages downloaded 2.6 billion times weekly, the Trivy breach exploiting GitHub Actions' mutable tags, self-propagating NPM worms using LLMs for reconnaissance, and malicious skills appearing in Claw Hub repositories. He emphasizes how developers - living with long-lived credentials, little MFA, and tools scattered across personal and work machines - have become the primary target, especially after cloud infrastructure hardening. The conversation covers why litigation against open-source maintainers is unfair, how CI/CD pipelines amplify risk, and one surprisingly effective defense: a 48-hour cooldown before adopting new package versions. For IT leaders managing developer access and supply chain risk, this episode clarifies the structural vulnerabilities enabling modern attacks and offers concrete steps beyond purchasing tools.
AI has made malware creation trivial - the technical ability and resources required to build effective malware are now essentially zero, leaving only malicious intent as the remaining barrier. Tools like DeepSeek and White Rabbit Neo can generate functional malware without guardrails stopping such use.
Josh Junon, a maintainer of several massive open-source projects collectively downloaded 2.6 billion times per week, was phished during a visit to the doctor via a fake two-factor authentication credential update email. The vulnerability was the perfect timing - he was stressed, in a medical setting, and received the message in a narrow window when his guard was down.
Trivy, a tool designed to secure software supply chains, was compromised. The attack targeted CI/CD pipelines in GitHub Actions, where attackers could steal credentials and access secrets stored in the pipeline environment. The unique danger came from GitHub Actions' mutable tags - allowing version tags to be retroactively changed with malicious code after users had already incorporated them.
Skills are extensions for LLM agents, hosted in Claw Hub (similar to NPM for LLM packages). When Claw Hub launched, five of the top ten downloaded skills were malicious, enabling attackers to compromise AI agents the same way they compromise software dependencies, potentially giving them insider-like access.
Enforce a 48-hour cooldown period before installing any new package version - if a package was updated less than 48 hours ago, do not install it. This simple policy stops 99% of malware because most malicious packages are quickly detected and removed within that window.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains several genuinely non-obvious technical insights - mutable GitHub Actions tags as a retroactive attack vector, Shahlud worms leveraging on-device LLMs for reconnaissance, and Claw Hub skill poisoning - but is diluted by stretches of general security culture commentary and arms-race platitudes.
the first version of that actually compromised uh, the package called nx. Uh, this is last year. And uh, how the malware operated, uh, is that when the malware ran, it actually looked for an LLM on the victim's machine and used it to do the reconnaissance
in GitHub Actions there's something called immutable tags...I can't go back and release version 1.9 again...GitHub Actions. You can. Oh, you can change the tag
The framing of 'malicious intent is the only remaining barrier' and the 48-hour cooldown as a concrete, free mitigation are fresh and useful; the fog-of-war theory around publishing stolen credentials is genuinely interesting, but the episode also leans on standard 'arms race' and 'assume breach' framing that is well-worn in security podcasts.
The resources and the technical ability are basically zero now. And you just are left with malicious intent
enforce a 48 hour cooldown period before installing any new package...If you do that, 99% of malware won't touch you
Mackenzie Jackson is an active practitioner at an operational appsec company that detects thousands of malicious packages monthly and ships real tooling (Safe Chain), giving him genuine ground-level authority; he is not a pure thought-leader, though his role is more field evangelist than deeply technical researcher at scale.
at Akita, we obviously have a big research team where we detect a lot of malware. We find thousands of packages every month
we still use rule based detection to find indicators of malware...and then use an LLM to make a final classification
The episode is well-stocked with named artifacts, specific timelines, and concrete mechanisms - the Trivy breach, Shahlud worm variants, Josh Junon's 2.6 billion weekly downloads, the sub-30-minute VS Code extension window, and Claw Hub's top-10 contamination rate - though a few quantitative claims like '99%' are asserted without sourcing.
he is the maintainer of, uh, several massive projects collectively downloaded 2.6 billion times a week
it was compromised for less than half an hour. But just in that time...one, in that window someone from GitHub installed it and then all of their code was stolen
Richard Campbell is a capable host who steers toward actionable advice and makes useful analogical connections (conditional access scoring paralleling malware heuristics), but he rarely challenges the guest's assertions, sometimes talks at equal length to the guest, and the conversation stays collegial rather than probing.
I'm hoping we get to a place here, McKenzie, where it's like, here's some things you can do. Because so far we've outlined all the things you should be afraid of
That Sounds like something GitHub could fix or at least set a parameter around. Like this is all exotic behavior
Computed from the transcript - who did the talking, and the words that came up most.
How are supply-chain attacks evolving? Richard chats with Mackenzie Jackson about his work helping companies protect their software supply chains from malware attacks. Mackenzie discusses the vulnerability of developers to attacks, since their accounts are often highly privileged and invariably contain access to exploitable secrets. The conversation digs into the challenges of securing various code distribution mechanisms like npm and how you can protect your organization - starting with, don't install packages as soon as they are released! There are effective tools for detecting malware in code, but they take time. Waiting 48 hours can eliminate a lot of risk! Links Aikido Software Trivy Claude Mythos OpenClaw Shai-Hulud Guidance ClawHub Open Source Malware Windows Update Management Recorded June 15, 2026
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign mhm.
Speaker B: From um. Runasradio.com you're listening to Run As Radio, the Internet audio talk show for IT professionals with Richard Campbel. This is Brandon wen announcing show 1043 AI accelerated supply chain Attacks with guest Mackenzie Jackson. Recorded Monday, June 15, 2026. Run as radio is produced each week by Sound Thoughts LLC. For more information, visit soundthoughtsllc.com youm can follow us on x@x.com runasradio.
Speaker C: Hi, this is Richard Campbell. Thanks for listening to Run As Radio today. My guest is Mackenzie Duncan, who is a field CTO at Aikido Security, helping tech leaders understand application security through an attacker's lens. He's the co founder of the health tech startup Compago McKinsey, has spoken in over 30 countries, hosts a disclosure podcast and contributes to publications including Dark Reading, Financial Times and Fast Company Mutual, uh, podcast Buddies. This is going to be too easy for us, right?
Speaker A: Yeah, absolutely. Thanks for having me, Richard.
Speaker C: And we got, we all got good gear, so it's going to sound nice and crisp and knock it out. That being said, this, this issue, I mean, supply chain attacks, full on, big deal. But the role of LLMs in this is freaking me out. Like what we've seen happen to NPM the past few weeks is shocking.
Speaker A: Yeah. One thing that I say about this when talking about it, uh, and there's so many graphs that you can pull up that are just kind of like show a vertical increase in malware creation since, you know, the kind of wide adoption of AI. But one thing I always say is it used to be if you wanted to write malware, uh, and particularly effective malware.
Speaker C: Yeah, right.
Speaker A: Something that actually did something, you needed to have a high level of technical ability and malicious intent. You needed both of those things together and also resources to be able to do it. The resources and the technical ability are basically zero now. And you just are left with malicious intent.
Speaker C: Right.
Speaker A: And there's an awful lot of people with malicious intent or financially, you know, financial driven malicious intent, whatever you want to, to call it. Um, and so basically we get to this point where the, the system was put under huge pressure and I think it's pretty safe to say it didn't cope.
Speaker C: No, it broke well. And even before these tools showed up a few years ago, the whole concept of supply chain attacks was really stressful because, you know, used to be ransomware made perfect sense to me. Right. It's the bad guys trying to push software into my system. Once they get in there, it's an Extortion attempt. Da da da da da da. Now we have multiple entities involved where it's software you depended on that has been manipulated in some way that's led to a breach of you or further up the chain. Or you're not breached at all, but you were the conduit to a breach further up the chain. Like now there's litigation involved. And that's the one that gets me is suddenly company suing companies because there's nobody to go after. From the black hat perspective. Like, good luck with that.
Speaker A: Yeah. And also companies suing open source maintainers.
Speaker C: Right.
Speaker A: Um, for, you know, being exploited. Which is so crazy because it's kind of. You have these people that are building free software, putting it out there to the world and actually now potentially have some kind of, uh, you know, litigation risk.
Speaker C: Yeah. Liabilities in just.
Speaker A: Liabilities. Yeah. Been just being a legend out there because they're, they're under so much pressure. And you see, um, just happens. There's a story of, of one of these maintainers goes by the name of Josh Junon or Quick Q I X. He's a legend. Um, I had a big long chat to him on my podcast, but he got compromised in this, in a phishing campaign. Uh, unfortunately, he is the maintainer of, uh, several massive projects collectively downloaded 2.6 billion times a week. So just gigantic.
Speaker C: Wow.
Speaker A: And he got subject to a phishing campaign. And when you learn how it all happened, he was at the doctors the day that he got this in. He was stressed about work or something else. The email come in that said, hey, you need to update your two FA credentials. And he just thought, oh, this is something that I can do whilst waiting at doctors. Something that I can do. Wouldn't have worked an hour before, wouldn't have worked an hour after.
Speaker C: Right, right.
Speaker A: He got that email in a, in a window of time that. And I think that's like the scary thing is where that the house of cards is reliant on these people building free software being perfect.
Speaker C: Right.
Speaker A: Which they're not.
Speaker C: Which nobody is. Right. I mean we talk about this all the time that we, we cannot guarantee no phishing attacks going to work. It's always what happens next that.
Speaker A: Yeah.
Speaker C: So why would we put anything, uh, other expectations on anybody else? It's like sooner or later you're going to have a moment and you're going to be fished now. What?
Speaker A: Yeah, yeah, exactly. I think that's exactly, uh, exactly right. And it's one of those areas where, you know, the posture needs to change. From we've kind of talked about this a lot in security over the past few years. I don't think this is new. But you know, go from building walls around your system to understanding, okay, what happens when someone is inside.
Speaker C: Right.
Speaker A: How do we limit, how do we limit their kind of directions? Most attackers are after things like secrets. How do we make sure that they're protected? What is the risk? What uh, are the backups that we have? And go through the scenario of let's say that our most critical system is compromised because the dependency it relies on is compromised.
Speaker C: Mhm.
Speaker A: What's the worst case scenario from here? How do we mitigate it?
Speaker C: So I mean, I find, you know, most listeners here are system administrators. We've been pretty good locking up our own accounts because we've been targeted for some time now. Like why go after domain users when you can go after super users? And more and more I have conversations with folks where it's like, listen, I live as a domain user, I elevate my privileges only briefly to do something at mini and then de escalate immediately so that when I make my mistake and click on the phishing attack, I don't have privileges. At that moment I'm no different than anybody else. But this is another factor. This is the same old problem. The software maintainer has too many privileges and probably lives in them most of the time.
Speaker A: Yeah, there's been a real change in direction with supply chain attacks because as you said, system administrators have been targeted. Then it kind of switched into if we can target these dependencies, we can target the cloud accounts that they live within and, and, and go for there. The problem with that from the attacker's point of view is that that's more or less, I mean it's, I think in reality it's a little bit more complicated. But for this argument here, that's one account that I need to lock down the cloud accounts, you know, I need to secure this one thing that's central, my application. It's central. I can enforce policies around that about update times and all of that. So it becomes harder and harder to attack this one thing as it gets more and more secure. And then what was left? Old developers, they, they have these long lived credentials living on their computers.
Speaker C: Yes.
Speaker A: You know, things like the AWS credentials that, that, that they are just kind of in, in their system.
Speaker C: Yeah.
Speaker A: Uh, so then it was, oh, I could target this one thing or I could target the thousand things that have similar access, which are the developers.
Speaker C: Right.
Speaker A: And we saw this play out with GitHub where one developer installed a compromised VS code extension crazily. It was compromised for less than half an hour. But just in that time. But in that window one, in that window someone from GitHub installed it and then all of their code was stolen uh, subsequently. So you know, you just kind of see that. And when you're talking about developers too, it's kind of. Even the best companies struggle with monitoring developers access and the machines that they're using. And are they on their personal computers? Are uh, they on company computers? I know everyone here is going to say no, we don't let them use their personal computer computers. You may not let them um,
Speaker C: like it was up to you in the first place. Yeah, I mean I've worked with organizations that are so locked down that the devs are uh, accessing a vm uh to do the dev environment. They have no locally installed dev environments. Like you can go that crazy but most people haven't. I also think the problem with software developers is there's still that hobbyist origin. You know, when you're an administrator it's a job. Right. You may love your job but you're not going out in the evenings and having pizza with friends talking about it per se. Like we may mutter to each other but it's not the same dynamic. But developers have this hobbyist origin. They are doing it at home for fun. They are uh, contributing to open source projects and so forth. And so they tend to have tools everywhere on multiple machines and they have way too many credentials. Like I just think from me from, from a security administrator point of view to say yeah, I really only want you to do this on this machine. I'm going to make you jump through extra hoops on this stuff. Like you're just not, you're going to have a tough time trying to do it anywhere else. Just do it here please. Because we're just trying to reduce the surface area. Like I just don't think they think of their vulnerability.
Speaker A: No, absolutely. And it is one of those things of developers. It's always someone else.
Speaker C: Yeah.
Speaker A: It's like it's never. And I have this arrogance too. Sure. Um, of like, you know, ah, perhaps even worse because I'm like in the sea. I'm like a dead.
Speaker C: Oh, you're in the business.
Speaker A: Like I would like obviously I'm not going to get. Yes, clearly. Like, but you know, it happens. I don't know if I should admit this. I'll go into anyway the, the um, the day I joined Aikido Security The Aikido does this really nasty thing where they do your, like, they do a whole bunch of phishing test, uh, phishing campaigns the day that you join.
Speaker C: Right.
Speaker A: So what happens the day that you join is you get a thousand emails to sign up for stuff.
Speaker C: Right. You know, and some of them are real and some of them are fishing,
Speaker A: some of them are real and some of them are fake. And so I, you know, so even, you know, so then your arrogance quickly gets kind of wiped away when you, at our company, we have, uh, a big, uh, singing fish that gets put
Speaker C: on your desk that's both evil and smart, right? Evil and smart.
Speaker A: Yeah, yeah, yeah.
Speaker C: I mean, how many people get through their, their, their onboarding without ending up with the fish?
Speaker A: I, I, I don't know the numbers, but it's less than 20%.
Speaker C: Sure.
Speaker A: I mean, sorry, less than, like, like 20. Around about 20% gets fished.
Speaker C: Yeah.
Speaker A: From it.
Speaker C: Yeah.
Speaker A: And so 80%, like, survive. So around about, like, around about that. So it's not a great statistic to put myself in, but I mean, you
Speaker C: were in the 20.
Speaker A: It is. We have. I was in the 20 that one time. I'm, But I can tell you what, I don't want that fish anymore. I'm very vigilant on fishing campaigns now.
Speaker C: Well, I also push on, like, humility helps a lot in this too. Right. Like, it can happen to anybody. It's happened to me. Like, all of that is good.
Speaker A: Yeah, yeah, yeah. The other thing, too, I don't know why I'm admitting it all. I was making a video about what happens when you leak, uh, AWS keys, uh, on GitHub, and I made a honey token. And in order to make a honey token, you had to. I had to have access to an AWS account to create basically a nothing account that I could just monitor the logs. Who's trying to access this, this credential that does, did nothing, had no access.
Speaker C: Like I said, it was a honey token.
Speaker A: I got the two, got the two confused and then published the rules.
Speaker C: No.
Speaker A: Which was, which was on just my account. It wasn't a account, but it's still like, these things happen, right.
Speaker C: So, uh, and it doesn't. And it happens fast. Like, there you go, there you are. That's amazing. And it's, again, it's all very reasonable, vulnerable kind of stuff. Uh, I think you pushed on this whole CICD pipeline side of this too, which is again, devs have so much privilege when they're pushing builds. You know, we've been on the dev Side, we've been pushed to checking code every day, several times a day.
Speaker A: Yeah.
Speaker C: And often they're immediate. That's kicking off an automated pipeline that has tremendous amount of privilege.
Speaker A: Yeah, Pipelines are like a very interesting one and there's a, there's a lot of attention on it right now. There's a couple of very interesting things about pipelines. And if we, I think like a recent uh, attack that we can kind of talk about is Trivi, which was a. It's a tool designed to help secure the software supply chain was compromised.
Speaker C: Wow, brilliant.
Speaker A: So it was an SEA tool. Yeah. And um, and it was compromised. Um, and, and the, the attack vulnerability for people using it was in the CI CD pipeline, like was mainly in GitHub actions where people were, people were using that. And that is because, you know, there's so many actions running in various different environments that when you get in there, you have the opportunity to steal credentials in various ways. But you also have the secrets that live inside the CI CD pipelines.
Speaker C: Right.
Speaker A: That, that, that live there. That. And one of the tricky things about the trivia tag in particular that really uh, was nasty, uh, was the fact that in GitHub Actions there's something called immutable tags. So uh, if you think about a GitHub action as. Just think about it like a package, like an NPM package, For example, the GitHub actions have versions as well. Where the difference lies is that I can't, I can't change. Like if I've released version 2.0 on npm, I can't go back and release version 1.9 again.
Speaker C: Right.
Speaker A: With malware. Right. I can only go forward. I can do weird like numbers, but I can't replace something, uh, GitHub Actions. You can. Oh, you can change the tag of it so that someone that is using a GitHub action that is pointed to a tag, that tag can be updated, meaning that the version that I'm using wasn't malicious, but now is.
Speaker C: Right.
Speaker A: So like that's that and these types of mechanisms are terrifying when it comes to the supply chains.
Speaker C: And that Sounds like something GitHub could fix or at least set a parameter around. Like this is all exotic behavior.
Speaker A: Yeah. They are getting rid of mutable tags from the trivia breach. They are now talking about getting rid of mutable tags. But it's still, uh, it's still a, uh, uh, like. Yeah, it's still a scary thought.
Speaker C: Sure. No, and it's all things I want to think about. You know, we've Been so incented to go quickly with software and to you know, again you end up with these high privilege pipelines here. What it really does is propagate vulnerabilities quickly. So you know, yeah, the thinking through like I don't want to slow development down, obviously that's a feature modern development but I also need to keep it secure and I can't do multi factor authentication on each step because it's automated. That's all part of the problem.
Speaker A: No, exactly. Right, yeah. And I mean there has been some good changes around this but that was also why we saw so many self propagating worms in NPM is because all developers had these long lived tokens that could publish software that could publish the package to NPM and just they never expired. So you know, you, you issue one to a developer, he puts it, he or she puts it on their machine and uh, you know, and then you know, four months later that machine gets compromised and that, that uh, API still works.
Speaker C: The token's still there.
Speaker A: Yeah.
Speaker C: And off it goes. Yeah, fair enough. Mackenzie, I'm going to interrupt for one moment for these very important messages. If you've ever built something with Power Platform or wished you understood it better, then you need to know about the Power Platform Community Conference at the MGM Grant in Las Vegas, Nevada October 25, 30th, 2026. This is the one event every year where the global power platform community comes together in one place. Microsoft leadership and engineers, makers, developers, IT pros, architects and business leaders all learning how to get real results with Power, BI, PowerApps, Power Power Automate and Copilot. The sessions go beyond slides. You'll see real customer stories, practical demos, hands on learning and deep dives you can actually use when you get back to work. And just as important, you'll meet the people behind the tools, the Microsoft product team leaders, MVPs and community experts who live and breathe this stuff every day. Whether you're just getting started or running Power Platform at scale, this conference will level up how you think and m what you build. Listeners to run as radio can get a discount on registration by using the code runas at Power Platform Configuration. The Power Platform Community Conference is at the MGM grand in Las Vegas, Nevada October 25th to 30th, 2026. And we're back. It's run as Radio. Um, I'm Richard Campbell, that's Mackenzie Jackson and we're talking a little bit about, well, just the vulnerability that developers are dealing with as a whole. But let's throw the large language models into the mix here. So yeah, far less talented people or more skilled, less skilled evil people are able to use these tools. Like we're in the midst of. Around the time this is being published, this whole debate around Mythos where somehow Anthropic has made an LLM M. They've decided it seemed awful marketing, this is too dangerous to let out in the wild. So we've given it, we've only made it available to these biggest companies who are clearly using it. Like the rate of patches going on these days is astonishing. But meantime, for all the rest of us that aren't in that 50 companies or so, they went for like, what about us? Like we got the same problems. How much vulnerability do we have?
Speaker A: Yeah, it is a scary time kind of to be, to be around. And uh, I guess one of the scariest things about malware is that whilst it is technically challenging to write malware from scratch, this isn't particularly a gigantic issue for LLMs. As in we don't need Methos, right To write malware. Right. We need, we can use Deep Seq. We can use this kind of tools that are designed more for pen testing like White Rabbit Neo, which uh, which have. None of these guardrails are going to stop you from doing right for writing malware. And I think that is, it's like there is very sophisticated malware out there, but the majority of what you see and a lot of that works is quite simple. It's obfuscated code, it calls to a C2, it looks at your environment for secrets, it sends them to someone. Now we can add in self propagation mechanisms that make it a little bit more complex, but none of which is going to be too difficult for an older LLM model to write. So we're there in that problem, um, of ah, going of discover of writing malware. And one of the challenges with detecting malware. So at Akita, we obviously have a big research team where we detect a lot of malware. We find thousands of packages every month. But one of the challenges in detecting malware is that every single indicator of malware has a legitimate use case. So if we just look at a random package, it's heavily obfuscated, it's wrapped in base 64, it's calling uh, an external payload. All of these things are indicated, but all of them could be perfectly legitimate.
Speaker C: Sure.
Speaker A: So, and when you look at the scale of that, you know, there you. It's very difficult to kind of discover uh, this, which is why they slip through the cracks and it's why you Know they, they do last, they may only last for a few hours, but in a big package, you know, that's all you need.
Speaker C: Yeah.
Speaker A: So the LLMs are creating, you know, a big, a big issue for you. But there's another interesting change to this which is actually using LLMs on people's, on developers in particular on their machines. So we know about you know, uh, claudebot which kind of came out this agent, there was a very interesting supply chain attack. So you may remember or you may know about the Shahlud variants of kind of there was these self propagating worms called Shahlud. It's named after Dune and there's been hundreds of them. Maybe that's a bit hyperbolic, but there's been m, many of them and many different variants where they would steal developer tokens, um, and publish the secrets in public on GitHub and then steal more secrets and kind of continue this, compromising more and more NPM packages. But the first version of that actually compromised uh, the package called nx. Uh, this is last year. And uh, how the malware operated, uh, is that when the malware ran, it actually looked for an LLM on the victim's machine and used it to do the reconnaissance or look um, for kind of secrets inside the system. So actually in there.
Speaker C: Wow. Hoping that it had additional privileges.
Speaker A: Yeah. And so, and it had a prompt in there that was hey, recursively look through this, numerate all the files, pull out any secrets, go through the. And whilst that proved that did work, it proved to be a little bit ineffective.
Speaker C: Right.
Speaker A: There's better ways to do that. However, that concept is pretty terrifying as we putting these things on our system,
Speaker C: LLMs attacking LLMs and then if you.
Speaker A: Yeah, and now we have these things called skills.
Speaker C: Mhm.
Speaker A: Uh, so going back to this Clawbot agent, there's something called Claw Hub which you can just think of as NPM or pypy for LLM skills which are basically just readme files. When that was published, uh, I think five out of the top 10 skills downloaded were malware or malicious skills. So now the dynamic change. Okay, we've got people compromising NPM packages, these dependencies that we use. But now I also have to worry about someone compromising these skills that I'm using for my AI agent which you know, potentially could, could almost act like a, as a bad insider. Um, so the, the risk of LLMs in the supply chain is kind of multifaceted and it's uh, it's not a cheery.
Speaker C: No, it's Expanding, like, I'm hoping we get to a place here, McKenzie, where it's like, here's some things you can do. Because so far we've outlined all the things you should be afraid of.
Speaker A: Well, I can, I can say one thing. If people are looking for like, what can I do that's not buy an expensive tool, that's just something that I can do. Um, and that is there is one thing that was very effective, especially when it comes to dependencies, and that is enforce a 48 hour cooldown period before installing any new package.
Speaker C: So, right.
Speaker A: If a package has been updated less than 48 hours, do not install that version. If you do that, 99% of malware won't touch you.
Speaker C: Right.
Speaker A: Because most of it only lives for
Speaker C: a few hours because the detectors work. They catch up with it.
Speaker A: Yeah, yeah, they do. Yeah, they do. And by the time that. And usually. And there's multiple companies out there, so I work for a keto security. There's also great companies. It's open source malware. There is socket. Um, yeah. And there are multiple other companies as well that are looking in this space. So we're, we're, we're. And we all find it and we all have a bit of a, it's a bit of an unhealthy contest of.
Speaker C: Right.
Speaker A: It's not even who discovered it first. It's like, who could tweet first, you know, but we're all going to discover it. Um, and, and so it will be brought down. But if you want to prevent it, then that's actually a concrete thing.
Speaker C: Just.
Speaker A: You can do. Just wait. Yeah. And you can enforce it by policy. Um, you can do it. There's some hilarious screenshots of Claude, uh, Claude code, like bypassing that because it's like, oh, I can't install this latest version of dependency. Let me find a workaround to these policies that you've put in place. Um, but yeah, that is something that you can.
Speaker C: Well, because often, especially when you kick off these pipelines and things, they have in their scripts, go get the latest versions. So just including the policies, get the latest version that's at least 48 hours old, a whole class of problem just goes away. I like how mundane that is, Mackenzie. Like, it's just like, yeah, you know, if you just wait.
Speaker A: Yeah, yeah. And like it is a frustrating point too because you know that it's not going to happen. Like, you know that some people will implement this. Right. But you know, as a general and as a global policy for all developers, it's actually not, you know, it's, it's frustrating because it's, it's something that you could do that could potentially solve an issue. If we could at least take a huge chunk of the effectiveness of these supply chain attacks, they potentially would stop
Speaker C: because like why bad guys only want to do stuff that's effective, so as soon as it's ineffective, they'll move on.
Speaker A: Exactly right. So this is something that we could do if collectively we all did this would actually be pretty great. Uh, but unfortunately, you know, it's not going to happen.
Speaker C: Well, now we get into this bigger picture idea of instead of installing from the source repositories, you maintain an internal repository. Now lots of organizations do that. And so then that policy is about maintaining that everybody, everything in the organization goes against our internal repository. And then our internal repository has the policies for when it picks up new packages, whether that process does its own testing for malware and, or just waits the magic 48 hours so that you decrease risk. Like all of those things would work. Like it's a justification for a big piece of infrastructure. From a, uh, from a system ins perspective, this is mostly configuration. It's not like it's a lot of disk space or anything, but to get to that position of we control what we install into our applications.
Speaker A: Yeah, yeah, exactly. And you don't even need to do the malware detection yourself.
Speaker C: Yeah.
Speaker A: We um, have open source tools. Other companies have open source tools. Our one's called Safe Chain and it's just, it's a like, like it's a very mundane tool. Nothing much exciting. It just checks before it installs. Is there's this known malware and checks it against. Is it 48, is it less than 48 hours old? Is it known nowhere? Right. And then if we just did that pretty, um, it'd be pretty effective.
Speaker C: You knocked down a lot of problems.
Speaker A: So the good news of that is as an organization. Yes. There are things that you can do that aren't buy an expensive tool.
Speaker C: Yes.
Speaker A: Uh, you know, which is, uh, always nice.
Speaker C: Yeah.
Speaker A: So you can do it. But as a, as a kind of ecosystem, as a community, the problem's not going to go away just because we can do that.
Speaker C: Unfortunately. Well, and it does sound like we're in an arms race where the LLMs are also serving us to help fight back against these attacks too.
Speaker A: Yes.
Speaker C: So it, you know, kind of goes back and forth and, and in my experience, the white hats tend to win because the best and brightest tend to be good guys.
Speaker A: Yeah, yeah, absolutely. And it's actually a great use case for LLMs because like I talked about how the malware, the indicators of malware, you know, uh, aren't always because it's malware, it's just because you want to obfuscate your code for whatever reason. Right. But what we are actually doing and just to kind of show you how our detection works is we still use rule based detection to find indicators of malware. We just cast a really wide net. Now the majority of them aren't actual malware, but we narrow it down so that we only have things that have indicators of malware and then use an LLM to make a final classification. So we're not scanning everything with AI, which would be like enormously expensive.
Speaker C: Yeah, uh, tokens versus tokens.
Speaker A: Just a waste of resource. Yeah. But we are able to kind of narrow it down so we just get what are the potential malware candidates and then use AI, which is a great use case because AI is non deterministic, which means security is kind of bad. But in this case it's actually kind of good.
Speaker C: You're leaving a Gianca. But this reminds me of conditional access too. Like when do I ask for additional authentication prompts? Right. It's like, hey, they're normally in this geography. They're in a different geography. Geography that add a couple of points to potential. Uh. And you sort of get to a point where it's like, okay, we should do additional authentication. You're running down that same thing. It's like, is the code obfuscated? That's not an automatic fail, but it is a thing. And then we get three or four of those. It's like, okay, let's go do more analysis on this. This is worrying.
Speaker A: Totally that.
Speaker C: So, yeah, you've got a set of conditional policies. I appreciate that.
Speaker A: Yeah, yeah. So the LLMs are giving us, uh. And I think we will win in the long run, but right now there's a lot of growing pain.
Speaker C: Yeah. Well, about it. You know this. The other side of this is that when well architected and carefully controlled, the LLMs provide a substantial productivity boost, especially to software development. So you're not going to talk organizations out of using these. Like they. I hope nobody comes away from this show going, we should just not use these tools because that's not going to protect us. Like we're in it. But while we're in this arms race and the tools aren't that clear, you're going to have to jump through extra hoops. But that reminds me of CICD pipelines. Fifteen, 20 years ago, where you kind of had to roll your own. Like, the tools weren't that good and you had to put it together, but the advantages were substantial. Like, it was worth the pain. And I think we're seeing the same thing here. The pain is real, but it's worth it. But you got to do the work. And I don't. You know, again, administrators always have to come with the bad news, so maybe we're just arming them to go, all right, guys, I know we're using these things, but let's talk about the security of all of it. And one of them would be, we just have to treat packages differently now. Like, whether you're using these tools or not, you have to treat external packages differently now because they're dangerous.
Speaker A: Absolutely. Yeah. Absolutely. Yeah. Yeah, you absolutely do. And luckily, we're not alone fighting this. Um, a lot of people kind of ask me, you know, like, uh, I guess, what's the responsibility of places like npm, and NPM in particular, because it has had the least amount of security calls.
Speaker C: Yeah.
Speaker A: And kind of like, to put it into perspective, NPM was built. Their core methodology of building it is we want to make it as easy as possible for anyone to release their thing on the Internet. We want to make. And that's why it grew so big. And. And you could argue that that's why the JavaScript ecosystem is so massive today is because there was this availability of tools and things.
Speaker C: Sure.
Speaker A: That is why it is the least secure ecosystem now. And they're doing things to, um. They're actually making some great decisions now. They've just recently announced that they're no longer going to, um, allow by default, post, uh, install scripts and some other things. But the point is, they're doing this all against their core belief of what they built the company with at the start.
Speaker C: Right.
Speaker A: So it is. It's a challenge for them. No, they're doing it because they need to do it.
Speaker C: It hurts them, I'm sure.
Speaker A: But it's not like NPM are just irresponsible. It was just that what they want set out to build has now turned against them and they have to neuter it a bit.
Speaker C: Well, and realistically, the line is, this is why we can't have nice things. Right. Like.
Speaker A: Yeah, exactly.
Speaker C: Here we are, the world a grimmer place than expected.
Speaker A: Yeah. Yeah. And these packages have various levels of friction to upload them. There's a reason why we don't talk about malicious iPhone apps all the time. That's because the amount of Friction to publish an iPhone act is gigantic. Ah. In terms of anyone that's tried to do that and, um, hopefully NPM won't turn into that. But that is adding friction is effective for creating security, which, I mean, it doesn't sound nice to talk about it like that, but that's where we're at.
Speaker C: Well, uh, I didn't say you couldn't deploy several times a day. I just said you couldn't deploy with packages younger than 48 hours. Several.
Speaker A: Yeah.
Speaker C: Let's be clear. Right.
Speaker A: Exactly. Yeah.
Speaker C: And we could, we can polish those rules more when it comes to internal packages and things like that, but every bit of this is about accepting more risk.
Speaker A: Yeah.
Speaker C: So.
Speaker A: Yeah. And being aware of it. I think there's a lot of people that now unfortunately are very aware of the risk of uh, of supply chain compromises that perhaps a year ago weren't.
Speaker C: Yeah. Um, it's certainly. It's a, uh.
Speaker A: Yeah.
Speaker C: It is definitely this, the new emergence. Like it's overwhelmed ransomware now. It is the thing you're the most frightened of and uh, and. And has such serious consequences when it happens.
Speaker A: Yeah. And I also can't quite figure out the threat actors behind this too. It's. At least with ransomware it's so, so easy to understand the motivation and that helps understand the attackers. But some of these attacks are just chaotic. Like, like the first Shahlud worm stole secrets and then published them all publicly to GitHub.
Speaker C: Right.
Speaker A: And it's kind of.
Speaker C: Why was it, was it a proof of concept?
Speaker A: Like I get these. It wasn't. Uh, there was some initial proof of concepts, but this, this one, when they've done several iterations like this, and the best that we could kind of come up with because about a thousand. And one of them, about a thousand repositories were created all because all. Each repository is containing all the secrets of one developer's machine.
Speaker C: Right.
Speaker A: So huge amounts of repositories created with huge amounts of secrets. And I guess it's. Well, one is either you're just trying to create chaos, which is probably legitimate. Two is you're trying to cover your tracks in a fog of war in the sense that, uh, now everyone has access to the secrets, so you don't know if it's the same threat actor that's.
Speaker C: Well. And which set of secrets was important to you. I remember with the Hafnium exploit, which was an Exchange server exploit that it had definitely, you know, it had been a state actor, Red China, uh, that had figured out the zero day and had been using it to steal email information for some time. But then again to cover their tracks, they published it. So it got used everywhere and now you could no longer figure out where they were looking because it was. You just buried it in chaos. Uh, and now you have to do date filters and things like that, which is way harder. So. No, I appreciate the thinking. It's like you get the credentials you want, you don't want to let them know you got their credentials. So now you let this thing off. So it's absolutely everywhere and you're just one of the many victims.
Speaker A: Yeah, yeah. No, I think, I think that that's exactly right. But it still feels counterintuitive. Like, you know, like you get all these things and you're giving them away. Yeah.
Speaker C: I mean it speaks well of you to not think evilly. There seems weird.
Speaker A: There's been some moments in my life where I'm kind of like m. I get that.
Speaker C: Yeah, I appreciate that. But uh, it's great advice. It's great advice to think. To just think about what the pipeline looks like and the fact that we are in an arms race. And while that arms race is going on, give time for the defenders to defend. And that just means waiting a little bit or join the arms race, be part of finding and fixing. It depends on what I got budget and cycles for. But I can, I can make a pitch either way. Mackenzie M. Jackson, thank you so much for coming on Run As Radio.
Speaker A: Thanks for having me, Richard. It's been uh, it's been a pleasure. And yeah, it's a shame we didn't quite cross paths in Copenhagen. Glad that we could do it.
Speaker C: You had a heck of a journey. So I, uh.
Speaker A: Yeah, I spent less time in Copenhagen than I did at the airport.
Speaker C: Right.
Speaker A: Because uh, I like of trying.
Speaker C: That is not the way I want to go to a conference. Yes. In our original plan we would have sat together in a back room at the conference and just chatted in person. But that's not how this went down. But I'm glad that.
Speaker A: I'm glad that we were able to do it still.
Speaker C: Yeah, me too. Glad to get it done. Thanks so much for coming on.
Speaker A: Thanks Richard.
Speaker C: And we'll talk to you next time on M. Run Ass Radio.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Lay of the Land: How Attackers Move in '26mnemonic security podcast · on supply chain attacks94 / 100
Amazon Q CVEs, Hijacked npm and Go Packages, AWS WAF HTTP/2 Issues, Lambda MicroVMs, and Why Execution Is the Boundary NowShip It Weekly · on npm packages88 / 100
Why Agents Are Forcing Enterprises to Finally Fix Their Dev ProcessThe AI Native Dev · on CI/CD pipelines85 / 100
How to build a monolith the right wayAdventures in DevOps · on GitHub Actions84 / 100
How MLOps and LLMOps Drive Consistent Results (Kristen Kehrer)What’s the BUZZ? - AI in Business · on CI/CD pipelines82 / 100
Stories from an Expert Threat Hunter with Taz WakeCyber Leaders · on supply chain attacks82 / 100
Securing Developers with Tanya Janca
47 Day Certificates with Todd Gardner
How Machine Learning Fails with Megan Robertson
Data API Builder and SQL MCP with Jerry Nixon
Team Productivity using Loop with Karinne Bessette