Loading summary
A
The build out of AI systems in companies in enterprises creates a much broader attack surface. And that's because there is a lot more development going on than there was three years ago. And some of that is increased speed in designed development shops where they are pushing an update every day because the AI is writing code and doing that, and they're able to do that, if not every two weeks. And the other big part of that is now Jim from accounting is a developer because he's got Claude code on his desktop and he's okay, I'm going to make this little app that works for me and that's great and can unlock lots of productivity and creativity, but also means he may not be doing it in the same constraints as your production dev shop.
B
Welcome to another episode of Mandance Defenders Advantage podcast. I'm your host Luke McNamara. Joining me today, I have the pleasure of welcoming on, I think for the first time, although Ben, you can tell me maybe you've been on here before. Ben Reed, the head of Strategic Threat Intelligence at Wiz, formerly I should say, of Mandiant. But he's here to talk about supply chain compromises and probably more. Ben, great to have you here today.
A
Great to be here. First time, long time as they say. So this is my first time here and it is great to be here with you, Luke. For those who don't know, Luke is the person who got me my first job as an intern at Eyesight was instrumental there. So you can blame him for any mistakes I make because he's really the originator there. But it's great to be here and excited to talk about this stuff.
B
Yeah. Glad to finally make this happen. I think this is a topic certainly we could cover in any previous know, five or six years, but I think has become especially more relevant this year around supply chain compromises, particularly with what we're seeing in the open source. We were both at FireEye when the SolarWinds event happened and I think that sort of kind of kicked off a lot of the, I guess call it modern focus on supply chain attacks, supply chain threats. But that's a very different dynamic than I think what we've been seeing certainly the last couple years, but even in this year particular. So maybe diving into that, what have you been observing with supply chain compromises?
A
There's been a lot of them, so there's been plenty to observe. But as you hinted at, there's the difference between sort of you're going back to whether it's CCleaner or SolarWinds or those things that were closed source. They were software products that got trojanized with because the company that made them was compromised. There's malicious code injected and we've seen started to see a different dynamic. Definitely started last fall with a lot of the Shai Hulud stuff, the various worms there and has really continued this spring. The two main players are the team PCP folks and also a few of them sprinkled in from North Korea as well as others. But these are targeting open source projects and sort of libraries. And what's different about that is those are pieces of code that perform a specific function where everybody can read it. They're freely distributed and that makes them very attractive targets because they're so widely used and it is quicker to discover them that has that benefit because they are used everywhere, everyone can read the code. So these things are getting detected relatively quicker, much quicker than the SolarWinds one which was a year or whatever it was. But these are usually a matter of hours. But they're deployed so widely and as I think we'll get into the way they're used in modern software development architectures makes them very impactful.
B
Yeah, let's touch on that for a second because I think that is one of the differences when you're talking about the open source supply chain ecosystem compared to a closed source company and products that they produce. Maybe kind of touch on when we're talking about things like GitHub or Pypi or Docker, some of these places where packages are being uploaded and maintained and those are being pulled down into developer environments that could exist all over the world in enterprises where they're maybe producing their own software, there's this continuous development pipeline where as those packages are being updated, those sort of like latest iterations are also being incorporated and whatever downstream software is occurring. So maybe kind of at a high level touch on you know, why, how this is how this open source ecosystem is used, especially amongst enterprise organizations.
A
Yeah, happy to do that. And so there are, there are two in a modern enterprise organization, sort of like big company government, things like that. When they're making software they're obvious point but they're not writing everything kind of from the kernel up themselves. They're standing on the shoulders of a lot of these libraries. And so if you want to create something that's going to take a PDF and OCR it, you're not necessarily going to write that from scratch. There are a lot of libraries, sort of pre written bits of code that can do sometimes all of something, sometimes a part of it. And Then you need to write something around it. And when you're developing so you're sort of creating this new software for your company, there's two main places that happens. There's developer laptops which are. Can be valuable, can have a lot of. They have a lot of their logins, the personal laptop. They're going to say, okay, I'm going to make my local version of this, going to build it, and potentially pull down the latest version of whether this. It's a npm, it's the big one for. It's one of the big ones, as well as PYPY for Python ones. Then there are various other smaller ones for different software programming languages. And you say, okay, I want to grab the latest version, pull that down, things like that. And if that version is malicious, you've all of a sudden downloaded something and that one is definitely see that. But it's not that where these things really get supercharged because developers are people, they click on links, they do other stuff like those things get compromised. The other place that these things have been that has really sort of made these types of attacks much broader and much more impactful has been the modern, what's called cicd, continuous improvement, continuous deployment pipeline, which is a lot of how modern software development works. It's not just that you're pushing, okay, it's been two weeks, everybody's reviewed this code. We're going to do one big push here. You're doing daily, more than daily updates. Every time there's a new sort of like small change that's happening essentially in a virtual machine. And these virtual machines can live a bunch of places and they're not kind of a traditional computer, but they may be something that's on GitHub Runner or other things. And what they do is when there's, when a new work stream is kicked off, like a new build, say, hey, I've got this thing, you commit it to your internal GitHub. It then kicks off this GitHub runner to try to build the new version that's going out to production. In doing that, if you have it programmed to, which is fairly common, to pull the latest version of all of the dependencies. So you've built this thing, it's dependent on 5, 10, 50 different libraries to do individual parts that you've then orchestrated into your software, it pulls down the latest version of them to make the new version of your software. And that is very much kind of what we had. What not we, but what has been in a lot of ways viewed as a Best practice, because you're getting the latest version, it's not vulnerable to anything. There's been from a lot of the sort of Volmageddon from. There's a lot of pressure. Use the latest version patch right away. And this is doing that. But it's also then downloading these fresh packages that are not in your control. You're downloading them from these public repositories, you're implicitly trusting that they are not malicious. So when they are malicious, that's a problem for you. It's also a problem because these environments are doing. Because these CICD environments are not just sort of running an isolated thing where just one person is sitting, but they then need to push this new code out to a lot of places they need to deploy it. And that means they have a lot of secrets. And for your kind of integrated cloud environment, they may have AWS secrets, they may have Azure stuff, they may have secrets to your production environment. All of those things may be built into there so that, so that it can work properly, but makes them a very attractive target. So as soon as you get a supply chain, so that makes them a really attractive target and very powerful in terms of what it let somebody who compromised that do in a lot of that.
B
Especially when you're talking about the CICD pipeline, that's happening automatically, correct? So if there is a new NPM package that has been compromised or tampered with or altered in some way by an adversary, if they've been able to affect that, and that's being pulled down into that environment, that CI CD pipeline, there's typically not a human that may be reviewing those changes, looking through the code, assessing, okay, there's something malicious here, something that shouldn't be, that's happening in a lot of cases just automatically where that's being rolled into the downstream software.
A
So there's two pieces there. It is generally happening automatically. There is sort of an implicit trust like, hey, this library, it does this, I'm pulling that down to bundle it in there. When malicious software, when malicious, the majority of the supply chain attacks that we've seen have targeted the development environment itself. Where, hey, I pulled down this library that does xyz and when that library executes or sort of gets bundled or installed within the CI CD pipeline, malware executes in that virtual machine. It doesn't affect if I'm building a software that then sort of your secondary software that sudden getting pushed somewhere to my website, to otherware. We haven't seen the malware go into that as much or introduce something there. It's been more affecting the CI CD pipeline, that virtual machine that is running the CI CD stuff itself. And that is because that's a fairly standardized place to execute. So the malware can kind of write knowing it's there. The way the library is packaged within the other software is very individual dependent. So it's much harder for an attacker to try to like affect that. You would really have to have specialized knowledge of how an individual company was bundling their stuff. And once you already have you to get that knowledge, you would already have had to compromise it and then you have a kind of different way in. So it's really targeting the people who are downloading the initial download of the software. There is a secondary effect, but it's generally when one package has a dependency of another. If you have sort of modern libraries or packages can be quite large and then have themselves have dependencies on other packages. So what we've seen is when one package gets compromised, it'll have, you know, x 10,000 downloads and that'll be a big deal. But sort of the total blast radius of that, maybe a multiple of that based on the packages that have that package as a dependence and kind of your retro nesting doll version of that.
B
And I guess there's even more complex, more actor directed cascading effects. I'm thinking of like the 3Cx incident where I think it was an open source piece of software. Initially it was some trading platform that had been installed by someone who had access to the 3Cx production environment. And then that resulted in further downstream access that attacker was able to achieve. I think they were doing more manually. It wasn't as automated as I think some of the stuff that we're seeing.
A
Yeah, and I've just been speaking about kind of like the automated like initial thing, blast radius there is def. Then the kind of actor feedback. Oh, we did this compromise. We got either additional access or additional secrets or other stuff. And we did some stuff on the back end and then continued on. We've definitely seen that where one organization will get their secrets stolen in a malicious package, the attackers will get all those, compromise that organization and then go downstream from there. We've seen that two or three times. But in terms of the automated ones, that's where it's kind of the first one and steal stuff there.
B
Maybe zooming out for a second. Why is it that you think we are finding more of this? Is it because more is occurring? I think historically, obviously supply chain attacks, broadly speaking, have been some of the more difficult intrusions to detect at times maybe that's less so for to one of your earlier points with open source software, but it does seem like it's increasing. And I think to another point you made earlier for a lot of the open source stuff, historically, the last several years, a lot of that had been linked to North Korean threat actors. It seems like now with actors like Team pcp, we're starting to see this infection vector broaden out to other areas of motivation.
A
Yes, I think you're describing it accurately and I'll try to give my perspective on why that is. I think so to answer those different questions in terms of the detection, the open source stuff is much easier to detect and that is because it's open source so everybody can see it and it is freely available where anybody can look at it. Like we wiz has a program where we are looking at all of the packages published to multiple different repos and running them through various scanners to try to find them right away. And whether it's us or some of the other folks, these are generally getting identified within under 15 minutes. Sometimes it's longer, sometimes it's a couple hours. But sort of like initial identification is very quick at this point because there's a lot of people looking at it. Then you need to find, okay, how did it get compromised? You need to notify them, it needs to get taken down. So you, you do end up having a window where if somebody installs the latest version, they can be compromised. And that's better than it was sort of a year ago because of all the attention here. But it's much easier because these are freely available, because it does need to live in. It can be obfuscated, but it needs to live in relatively readable code or relatively open code. It's identifiable. So that's sort of like the detection part. Whereas if you have something like SolarWinds, it is compiled code and is obfuscated because they want to protect their trade secrets and things like that. And so there being a different obfuscated thing in there that in that case waits two weeks before it does an initial call out to a masquerading domain. But the open source is more identifiable, so that's kind of where it is. And that has. We saw last year with the shailulu stuff, with some of the worm stuff, that this was a way to get a ton of credentials. And I think North Korea has definitely been doing this for a while and been doing it for their own reasons and sort of especially targeted towards the crypto industry and sort of a lot of stuff there. But there was a way, but I think the cybercrime folks saw that there was an opportunity here. This may have been theoretically possible two years ago, but a lot of this stuff is kind of socially generated and sort of goes into like okay, well we now see this happened and see it was very successful. So they're going to pour more energy into it and pour more and you'll. And we'll see more of it. So I don't think we were missing a lot of these attacks before. I think it has been the combination of some of the accelerations in terms of AI and I'm sure we'll get into that some of some sort of social like figuring out like oh this is a thing you can do. And then also increasingly a trend across a bunch of things as more stuff is hosted in the clouds and stuff like that is if you steal secrets it is accessible and you can sort of do follow on things as opposed to everything being on prem and needing to get a, you know, to hold back door and move laterally and yada yada.
B
I think that certainly makes sense of why cybercriminals and threat actors that are much more target agnostic, you know, if they're just selling initial access or they're at, you know, some part of the larger extortion ecosystem where they're not necessarily focused on a particular industry or sector, something like this, where you can cast a very, very, very wide net and have many, many different organizations impacted that you could leverage those downstream credential access. I think it makes a lot of sense that those actors would find this an attractive infection vector. And I think also just the larger shift to more and more identity based intrusions that we've seen in various forms, whether it's infostealers, whether it's the rise in phishing, this seems to just be kind of another aspect of it because that being one of the major things that we see downstream is the credential theft component.
A
Yeah, and that's what the major point of definitely all of the team PCP ones but increase but North Korean ones have been a little bit more mixed but it has been this automated credential theft. And that is, I think that is. There's a couple of reasons there. There's one where we talked about these, especially the CI CD runners being credential rich environments is part of it. And the other thing is that these are detected relatively quickly. So you really need to build in some autonomous action. If you just put a backdoor and you get installed 10,000 places in an hour. It is very hard to manually log into all of them and do your discovery and lateral movement and things like that. And you're going to get remediated at the majority of them before you can do anything. But if you can steal a bunch of credentials immediately in an automated fashion with your built in sort of programming there, you then have all these credentials and you can, maybe some people will rotate them, but what we've seen is that that's often done imperfectly and so you have the ability to maintain persistence via stolen credentials rather than via an implant. So it's just, it's a response to the way that these things have played out.
B
Let's talk a little bit about the actual targets from a package standpoint. I think with, as you mentioned with a lot of the North Korean activity, they're focused on targeting aspects in the fintech crypto space. And so, you know, impacting packages and software that's going to be used specifically in those sorts of environments is going to be attractive to them. I imagine a lot of this is also if you're a threat actor who is more agnostic as to your targets, things that are just popular packages that people are downloading and installing are also going to be of interest. But then there's also the AI angle I think, which you teased and we've seen infrastructure and things like Light LLM be targeted in some of these operations. So maybe kind of talk through what you've seen in terms of the actual types of packages and software that is being targeted or where the actors seem to have maybe more of an interest into starting this sort of cascading attack.
A
So folks on Team pcp, they've had, they have compromised hundreds of packages and haven't always been as discriminating. So I think it's worth leaving to the side sort of like what they're most interested in. It's been a little bit of kind of catch as catch can. The most effective ones have been the ones that, and we're sort of where they started have been libraries that are used for development. And so this is. They started with some, the check mark stuff, some things there that do essentially trying to make sure code is secure and code doesn't have things it shouldn't have in it when it's compiled. And so then every time you run kind of one of these CICD workflows you're importing the latest version. And so it is not just a library that is like tell me what time it is, but it's a library that is running, intended to run popular and running in development environments. And so there's a long tail of stuff they've compromised that had three installs. I think they at one point compromised a package that primarily was a Nintendo Switch emulator. So like they've done a bunch of stuff, but the things that have been most impactful, it's a combination of like general overall install base, but also install bases in places that do get run often if you have a package that is relatively stable, that's just a utility that people run on their desktops that they're not updating all the time. Your two hour window, you're going to get much fewer downloads in that two hour window than someplace where, oh, this is run. In these pipelines that companies are running once an hour, once a day, things like that, you're going to get a lot more hits. So that's been really a lot of the big change in terms of the big differentiator, in terms of the impact for what each package means.
B
Maybe from like the AI angle. This is I think an interesting one where you're having obviously a lot of work at the enterprise level to integrate AI agents, AI infrastructure, things that people are building, some of which is open source, some of which is internal tooling wrappers, other sorts of AI infrastructure. And so they're pulling from some of this open source software ecosystem to do these sorts of things.
A
Thank you for the refresher on the Light LLM stuff. Light LLM is a very powerful utility that people use to try to route queries to various things. And that means it's another thing where it is, it is always on and it is running as part of the infrastructure. And as companies sort of build out their AI infrastructure, we've seen Light LLM targeted forth for exploitation and for the supply chain incident where obviously it's running a lot of places. And if it's having to route different AI queries, it's going to have credentials for the particular services that that company's using. And so it is an attractive target for that reason. But even more broadly, the build out of AI systems in companies, in enterprises creates a much broader attack surface. And that's because there is a lot more development going on than there was three years ago. And some of that is increased speed in designed development shops where they are pushing an update every day because the AI is writing code and doing that and they're able to do that, it's not every two weeks. And the other big part of that Is now Jim from accounting is a developer because he's got Claude code on his desktop and he's okay, I'm going to make this little app that works for me and that's great and can unlock lots of productivity and creativity. But also means he may not be doing it in the same constraints as your production dev shop that is sort of like that has pinned dependencies or has a development environment that you're monitoring closely and you know what's going on. So the adoption of AI and the increase in the coding that's been done there really has expanded the developer surface at a lot of places.
B
And to reference to what you mentioned earlier about downstream, the targeting of developers because they have access in those production environments to various secrets and credentials. Same thing. Also true for a lot of this AI infrastructure where if you're building agents to empower those agents to actually do things, for them to be useful, you need to empower them with accesses to different data sets and tooling and provision of credentials. So there seems to be kind of a similar aspect to where that becomes an attractive target for kind of downstream actions. If you're targeting those sorts of types of infrastructure.
A
Absolutely. It's an accelerating piece.
B
So, I mean, from, from everything that you've seen this year so far, I mean, I think as we've been talking about, there's been more focus on this. There certainly been more in the security community that have also been looking for these sort of malicious packages once they're uploaded or once some of these accounts are compromised and malicious activities occurring. Is there anything that you think within the larger focus or discussion is maybe still underappreciated about this as a trend or set of activity? Even with renewed focus around open source supply chain security, with the way this
A
stuff happened, this ring and the way we've gotten as an industry have gotten good at recognizing Team PCP's MO in terms of the fairly loud smash and grab, steal a bunch of stuff, kind of make taunting threats way of doing things. And I think that's important. It's good to stop that and things there. I think we don't know exactly if that'll continue to be the dominant paradigm of these types of attacks over the next 6, 12, 18 months. There may be actors out there who are doing increased emphasis on stealth, increased sort of like trying to sort of like slowly do stuff. And I think the important part, it's not sort of a novel insight, but that this is a problem that we need to attack from a lot of angles. And I think There is stuff that sort of end users can do. There is stuff that individual package maintainers who may or may not be this maybe is often a labor of love for them. They may not. It's not always big companies or things like that. So there is a limit to what you can ask those folks to do. And then there is also platform level stuff that the people who are maintaining these package repositories, NPM is doing this where they're starting in August. They're starting to enforce two factor that you need to have two factor enabled for any token that is publishing to NPM. And that'll put another sort of like sort of grant sand in the gears of these these types of attacks and slow them down still be as with anything it's ways to get around it. But it is but there, there's just lots of different pieces of how this solution needs to come about in terms
B
of steps individual organizations can do to increase their security around this. What are your thoughts on that? I think the most common thing that I've seen is sort of maybe in some cases delaying the automatic installation of packages. Maybe you know, waiting some period of time which will catch a lot of these. I think as you noted, a lot of these are getting caught earlier on. But whether it's that or other things, anything that you think organizations should be mindful of in approaching security in this area.
A
So yeah, as you mentioned sort of the. One of the more the easy to explain one but hard to implement or more difficult to implement is aging your packages saying like we're not going to install anything that's newer than a day. And that would have kept you out of almost all of the ones we've seen so far this year. They were all. Some of them lasted a little bit longer but they all certainly caught removed within a day. So if you're not installing anything that's newer than a day, you're in pretty good shape. There are difficulties in terms of doing that as we mentioned with like you've then got to enforce that throughout your Org and that takes visibility and some of that is visibility into your sort of like production development environment and the ability to make sure everybody is in compliance with the way you do things. And also if there is something that slips through, you then know where we have that malicious package running. So you can say okay, the secrets on boxes A, B and C, we got to rotate them, they're gone. Burn it down. D, E and F, we don't have anything, we don't need to do that. You can prioritize can't always rotate everything. But then the other piece of that is trying to understand as we kind of referenced before your shadow development stuff that's happening throughout your org now with the LLM coding assistance. And again that's a tricky policy problem. There's not like an easy technical solution to that. But it is definitely something that you can do and I think will pay dividends whatever happens. And I think that that's where sort of like making sure you are set up to have the visibility into what's going on in your org is always helpful.
B
Yeah, I think especially again I'm thinking back to SolarWinds and how one of the big difficulties early on for a lot of organizations was determining are we using the software, are we using this specific version of the software? Which you would think would actually be easier to figure out from, from like an enterprise software usage perspective than this sort of environment we have now like Jim and accounting, building things on their own using who knows what. The governance issue for the open source software supply chain is a little bit more difficult to imagine I think especially for a large organization that has development occurring in many, many different places.
A
Yeah, no, it's definitely a challenge and it's definitely. There's a user education piece, there is a sort of controls these like where do you. Yeah, it's caught between trying to allow creativity and allow people to do stuff and find, find their ways to way with, with these things and also trying to not create vulnerabilities, create vulnerable software or download these malicious packages and sort of try to keep an eye on all that stuff. So it's a, it's a challenge, but it is something that is definitely doable.
B
So tying this all together, wrapping this up, you know, as you look out ahead at this space, I think you noted there's some things where this will hopefully become a harder threat vector for adversaries to use, but it's certainly one that's been incredibly useful. How do you see it evolving? Do you see the expansion of this to other categories of actors? We noted, for example, outside of North Korea, maybe we haven't seen as many espionage threat actors employ this in the same way. Do you think we'll start to see more of that what we see kind of going forward?
A
So I think if state backed actors are going to do it, it's going to be in niche supply chains because something that has 150,000 downloads in a week is just like that's a ton of noise and you can maybe get a. Because then you've Got to both you've got to set up not only sort of do we have to get in these places, you then have to identify who the victims are that you're interested in to select down select for your follow in activity. And like we all remember the complex mechanism that SolarWinds operation had for that. But that's really even harder when you have less control and even more, less control over where it's running and even more victims. So I think if we see it it'll be regional like hey, this is. One could definitely see, hey, this is a Korean language to use an obvious one or like a Japanese language sort of specific library that is used in like Japanese power plants or something that you could see somebody like the PRC targeting and just using hypothetical. I'm not even sure if that exists. So I think you could see some of the stuff there and we started to see some of that with the Russia's targeting of Ukraine specific software certainly going back years. So I think see some of that. It'll definitely be an option but I don't think these wide scale, I think that'll continue to be financially related folks because they can extort, they're happy to extort whoever. And we haven't, we've really seen, we have definitely seen the downstream lead to sort of stealing some data and then sort of the data leak, extortion. Haven't seen it lead to ransomware as much. But you can get, if you get keys, get secrets, you can then steal data and then say okay, we're going to leak this to everybody so you don't pay us as easy as anything. And you can also take that data at once and then leak it over the next six months as you have the bandwidth to do your extortions. And so it is kind of an evergreen. Once you have the data, you can use it and extort when you on your own schedule. So I think we'll continue to see stuff that sets up those types of information, those types of operations. I do wonder if certainly given the heat and the attention that the team PCP stuff if the other ones are likely to have more obfuscation or try to try and delay a little bit delay detection. I think there's another campaign that is generally tracked as Iron Worm because it's written in rust that has put maybe too much effort into obfuscation. It's one where they have like five different fallback C2 mechanisms that it's kind of like, well you're probably using an LLM because you can just like tell it to do another one rather than actually spending the time. So I think as it becomes easier with LLMs to create this code, we're going to continue to see attempts at this. And I think we'll have to see what those attackers kind of optimize for in terms of stealth or in terms of speed or breath or worm ability or different things. But I don't think we've seen the last of it.
B
It makes me think of when we kind of categorize or think about the main areas of risk from threat actors, leveraging AI scale, speed and sophistication. I think especially the scale and speed component of this, whether it's sort of managing all the different downstream victims that you've infected and the difficulty we've seen threat actors, especially in extortion, have with that in the past, being able to use AI to address some of that. And then obviously the speed component of this, given that there's now so many eyes on these packages, how do you do this in a way that maybe the intent is to delay, or maybe you're trying to kind of weaponize that access as rapidly as you can before this is more broadly determined. But how actors will leverage AI in these operations, I think is an interesting thing to track going forward.
A
Definitely. And the AI is. Its relative strength is writing code. And so manipulating things that are plainly written code is something it is good at. So I think we're definitely going to continue to see more attempts as we go on.
B
For people who want to stay on top of the research that Wiz is putting out around this, I can include a link in the blog, any other sort of resources you would highlight for people that are interested in delving further.
A
Yeah, we go through the Wiz research tag on the Wiz blog is where we're putting out all our stuff. And yeah, try to be quick, try to get that out there. But that's where our research is, so go read it.
B
Excellent. Ben Reed, thank you for your time today and a chance to delve into this topic.
A
It has been a pleasure. Have a good one.
B
Take care.
A
Sa.
Episode: The New Frontline of Supply Chain Attacks
Host: Luke McNamara (Google Threat Intelligence Group)
Guest: Ben Reed (Head of Strategic Threat Intelligence, Wiz; former Mandiant)
Date: August 10, 2026
In this episode, host Luke McNamara and guest Ben Reed dive deep into the evolving landscape of supply chain attacks, focusing especially on the new frontlines created by open source software ecosystems, the impact of AI-driven development, and recent threat actor trends. The conversation offers both high-level perspectives and tactical insights, bringing in notable examples, threat actors like Team PCP and North Korea, and practical advice for defenders.
[02:27–03:48]
Past high-profile supply chain events (e.g., SolarWinds, CCleaner) targeted closed source software, involving trojanized updates from compromised companies.
Modern threats now increasingly focus on open source libraries and packages (e.g., on GitHub, PyPI, npm, Docker).
Open source is attractive to attackers because these libraries are widely used; however, malicious code is often detected much faster (within hours rather than months).
“These are pieces of code that perform a specific function…they're so widely used and it is quicker to discover them…But they're deployed so widely…and makes them very impactful.” — Ben Reed [02:27]
[04:41–08:39]
Enterprises build new software atop a stack of open source libraries (e.g., npm for JavaScript, PyPI for Python).
Vulnerabilities emerge when CI/CD pipelines (continuous improvement/continuous deployment) automatically fetch the latest dependency versions.
Malicious updates can compromise virtual machines running these development/build pipelines and exfiltrate secrets (e.g., AWS/Azure keys).
“If that version is malicious, you've all of a sudden downloaded something…But where these things really get supercharged…has been the modern…CI/CD pipeline…” — Ben Reed [04:41]
[08:39–11:09]
In CI/CD environments, updates are pulled automatically, usually without human review.
Most attacks target the build environment itself, extracting secrets and credentials, rather than altering downstream software.
The “blast radius” of an attack can extend to all packages that depend on a compromised dependency.
“There is sort of an implicit trust…when malicious software…the majority of the supply chain attacks that we've seen have targeted the development environment itself.” — Ben Reed [09:12]
[11:09–12:48]
Some incidents (e.g., 3Cx) involved more targeted, hands-on compromise leading to downstream attacks.
Automated attacks focus on initial mass compromise and automated credential theft due to short detection windows.
Shift from nation-state (e.g., North Korean) focus on crypto/fintech to more cybercriminal engagement — wide net, credential harvesting.
“For a lot of the open source stuff…historically…linked to North Korean threat actors…it seems like now…we're starting to see this infection vector broaden out to other areas of motivation.” — Luke McNamara [12:08]
[12:48–15:35]
Open source attacks are often found quickly due to broad community scrutiny.
Sophisticated scanners (e.g., used by Wiz) catch most packages within 15 minutes to a few hours.
Rapid credential theft is necessary for attackers before remediation occurs.
“These are generally getting identified within under 15 minutes…So you, you do end up having a window where if somebody installs the latest version, they can be compromised.” — Ben Reed [12:48]
[17:34–20:14]
North Korean actors still focus on crypto/fintech.
Cybercriminals target popular libraries and those run frequently in CI/CD pipelines for greater impact.
Packages running constantly (e.g., dev tools, infrastructure like Light LLM) offer rich, persistent environments with valuable credentials.
"The most effective ones… have been libraries that are used for development…where, every time you run kind of one of these CICD workflows, you're importing the latest version." — Ben Reed [18:30]
[20:14–22:21]
Rapid growth in enterprise AI usage expands the attack surface.
Surge in non-traditional developers (“Jim from accounting”) creating in-house apps with AI-generated code, often outside traditional IT/dev controls.
AI infrastructure, especially systems like Light LLM, becomes highly attractive for attackers due to the sensitive data and persistent credentials involved.
"Now Jim from accounting is a developer because he's got Claude code on his desktop...can unlock lots of productivity and creativity, but also means he may not be doing it in the same constraints as your production dev shop." — Ben Reed [00:01 / 20:41]
[23:31–27:07]
Multi-layered defense needed:
"Aging" packages (delaying installation of new versions for 24 hours) effective for blocking fast-moving attacks, though tough to enforce organizationally.
Importance of visibility into all development activity, including shadow/AI-generated projects.
"One of the more…easy to explain one but hard to implement…is aging your packages—saying we're not going to install anything that's newer than a day. And that would have kept you out of almost all of the ones we've seen so far this year." — Ben Reed [25:34]
"Making sure you are set up to have the visibility into what's going on in your org is always helpful." — Ben Reed [26:30]
[27:07–27:44]
Unlike SolarWinds, open source package use is far more granular and decentralized — harder for large enterprises to maintain inventory and governance.
User education and effective controls must balance enabling innovation with preventing new vulnerabilities.
"The governance issue for the open source software supply chain is a little bit more difficult to imagine, I think, especially for a large organization..." — Luke McNamara [27:07]
[28:12–32:22]
Nation-state actors may move towards niche supply-chain attacks (region/language/sector-specific) rather than broad campaigns.
Cybercriminals will persist due to the utility of extortion, with credential theft leading to data leaks, not just ransomware.
Increased use of code obfuscation and AI to speed attacks, complicate detection, or scale extortion.
The adaptability and code-writing capability of AI make it a powerful tool for attackers — defenders must plan for continual evolution.
"We're going to continue to see attempts at this. And I think…we'll have to see what those attackers kind of optimize for in terms of stealth or in terms of speed…But I don't think we've seen the last of it." — Ben Reed [30:39]
“The AI is…its relative strength is writing code. And so manipulating things that are plainly written code is something it is good at.” — Ben Reed [32:22]
On the changing developer landscape due to AI:
"Now Jim from accounting is a developer because he's got Claude code on his desktop and…can unlock lots of productivity and creativity, but also means he may not be doing it in the same constraints as your production dev shop." — Ben Reed [00:01 / 20:41]
On why attackers love open source:
“They're so widely used and it is quicker to discover them…But they're deployed so widely and…makes them very impactful.” — Ben Reed [02:27]
On rapid detection vs. attacker speed:
“These are generally getting identified within under 15 minutes…You do end up having a window where if somebody installs the latest version, they can be compromised.” — Ben Reed [12:48]
On layered responsibility for defense:
"There is stuff that sort of end users can do…individual package maintainers…platform level stuff…so there's just lots of different pieces of how this solution needs to come about." — Ben Reed [23:31]
Future threat evolution and use of AI:
“Its [AI's] relative strength is writing code. And so manipulating things that are plainly written code is something it is good at.” — Ben Reed [32:22]
Summary prepared for listeners seeking a comprehensive understanding of trends, risks, and defenses in modern software supply chain attacks, as well as practical steps for organizational resilience.