How to survive supply chain attacks

Hey everyone, I'm James Wilson and welcome to this CISO-focused episode of Risky Business Features. Over the past few weeks, it has been seemingly a never-ending deluge of supply chain attacks. We've also seen interesting developments like the Shy Hallowed Worm being open sourced in a bounty placed on who can create the larger supply chain attack. Brad and I sat down to record this interview. We wanted to first talk about how do we get here? It's felt like package ecosystems like NPM and PyPy have been like, we've known these things were a disaster waiting to happen in terms of a supply chain attack for so long that now it seems, well, those hands have really come home to roost. But this is a great example of where AI has actually changed the problem both in terms of it's now clearly easier for attackers to mount supply chain attacks. But the surface area of those supply chain attacks, the people who are potentially vulnerable to them, is now absolutely massive because all these folks doing vibe coding and using AI agents, even for simple things as Brad points out, like giving it some medical records, getting it to create some charts, all of that in the background is pulling in packages that are coming from that same supply chain. So we talked through this and then we got to some practical advice about, okay, so what can you as a defender do now that the rules of the game have changed significantly and that the threat is the velocity of the threat is much faster, but also the attack surface is so much more massive. I'm going to drop you here into the chat where Brad starts off with a bit of a history lesson, but we quickly get into talking about the present day realities, how AI has changed things and then some real practical tangible advice for what we all need to do. This is not just a security team's responsibility anymore to try to keep us all safe in this area of daily supply chain attacks. I hope you enjoy it. I want to start with some absolute ancient history. So in 2012, there was a malicious binary that was signed by an Adobe code signing key and this led to a lot of excitement because I was just also resurred to Adobe back then and I spent a lot of time thinking about what could have made this much worse and how can we as defenders learn from this and not have to wait for the bad thing to happen before we can defend against it. And basically the idea of a supply chain attack that would lead to compromised binaries being pushed through the legitimate software update mechanism, that was the thing that I was so very worried about. And I spent a lot of time with my team at Adobe studying how other supply chain attacks have unfolded in the past, what this might look like, what are the best defenses we can put in place to catch it. And we spent a lot of time studying where these attacks were happening in other places. It was limited largely to open source ecosystem and they're quite rare. There'd be updaters that got compromised and would push down compromise code. But we're talking like less than one a year situation. And I spent a lot of time and money of Adobe's money to defend against these scenarios from happening at Adobe. Because we had multiple different updaters that were updating billion plus nodes per month. And so we felt like we're in a tractor target. And so all I got for this was bureaucratic complaints and pushback that I was wasting money on stuff that never happened. And then I left in March 2020 and then solar ones happened in December 2020. And so if I'd only stayed a little longer and I said, well, it wasn't us because of all the hard work we put into this. And so basically supply chain attacks were theoretically feasible but extremely rare. And a few notable examples, but we're talking less than once a year situation. I think the thing that's changed is the truth is if someone got into a big complicated commercial code-producing environment and they got code-comitter credentials that allowed them to push code into the build pipeline, the only thing they would accomplish is break in the build. And so getting code to commit and the build to push kick off and succeed requires quite a bit of knowledge and know how that I think would be beyond most people, even very credible attackers. So it takes a lot of care and thought on how to achieve this. Yeah, because I was thinking that if I put myself in the shoes of when I was in Apple with code commit access, if those credentials were compromised and someone had that, it's not going to do them any good unless they also had a couple of years of working on iOS or Mac OS so that they understood what are the even, what even are the components? How is code written so that it looks like it fits in? What are the, like we had automated build checks in the pipeline that would be catching all sorts of different paradigms and stuff. So there's just endless number of things that could trip you up, not least of which you'd have to have the domain knowledge of how the system works if you wanted to truly implant something deep enough to be, I guess, impactful but also stealthily, stealthily enough. And so I'm guessing those are the sorts of things that you're saying there of the other things. Yeah, and this is an environment that's not even trying to be defensive, right? Like this is just the build environment trying to protect against screw ups. And so then as you start to put in other things to stop the bad guy from being successful, it gets even more complicated. And so I think the big thing that's changed here is AI tooling has enabled anybody to give a prompt to say, I'm evil, I want to do evil things with these commit rights, make it so. And then the AI tool figured out and you might not be able to get Cloud Code to do this, but any, you know, like non-guard railed open source model, it's very straightforward for them to be able to do this. And so what some of the stats that I've heard on this is that when people started studying at scale, and again, this is through AI enablement, that in the old days, a backdoor had to succeed, deployed somewhere where somebody wouldn't hair split and notice the weirdo behavior and then follow up on it. And so the XC bug that got caught by the Microsoft engineer who was investigating some weird latency or the bad guys using SolarWinds compromise in order to do a second factor enrollment for compromise to CalT. And when they pulled the thread on what was happening there, eventually they found and traced it back to the compromise SolarWinds binary. And so it used to be you had to wait for them to succeed, wait for it to achieve the effect, and then someone investigate that to go back to what happened. What in the open source ecosystem is happening now is people are using AI tools to inspect every single code commit to every single open source package across the internet. And they're just burning a lot of electricity looking through all of this and saying, with prompts, not much more subtle than does this look like a backdoor to you? And then you get back, yes, no. And then if it's yes, you might have a human look at it and figured out. And in the beginning, this was catching hundreds of week of backdoors. And these were projects that were cared about. They weren't necessarily that important. But once you started looking at scale, there's a lot of this stuff happening. And that number, the last I heard was that some companies are now catching 10,000 malicious commits a week in the open door ecosystem, sorry, open source ecosystem for these types of backdoors. And a lot of these are of no import and the user base is not at risk because nobody uses it anymore. But then you get a lot of these, like basically since the Axios bug, which is around March 30th of this year, it feels like it's been non-stop role of cost ever since. And so I think the AI supercharged attacker has been able to convert any type of credential compromise into immediate backdoor commit success. And then what we're seeing now is it's not only simple credential compromise attacks, but incredibly elaborate multi-month social engineering attacks that involve entire fake companies, lots of humans involved, like really, really things where I cannot fault the human who fell for the scam because it's so involved and so intricate. And I can understand why these folks are falling victim to these types of attacks when you've been targeted that carefully. That was the interesting thing also about the 10 stack one, right? Was that I wonder if even AI was involved in finding that initial attack vector of using the cache poisoning within the GitHub action with a malicious. Well, yeah. And actually, so the 10 stack one was a GitHub oddity and they took advantage of that. And I guess you guys talked about that on the show. Yeah. But you could imagine it was a prompt like, yeah, does this program, you know, this is my open source project and we use GitHub actions. Are there any flaws that I should be aware of in the way we use GitHub action? And I could totally imagine a model coming back and saying, ah, that pull request target action that you've got. It's actually using the shared global cache, which is a problem and then just attackers go, okay, there we go. Thank you very much. Yep. And they're often running. And so now the motivations of what these attackers are after is incredibly varied. And so you have crypto like theft schemes. You have other, you know, crypto redirection type attacks and draining wallets and things like that. You've got just more credential theft, which could be used for anything, you know, so you just have expanding blast radius of what could happen. And then you've got like in this most recent one, it's a self propagating. And so it is spreading itself and sealing more credentials. And then I think you guys talked about in the show that if you reset the API keys that have been stolen, it'll RMRF your environment, which is like a real, real social. And so you're a behavior of the boy. Man, that I dropped my head and dismay when I heard that little tidbit. And so basically the, you know, it has been revealed and is now widely understood by a wide variety of bad guys that this is one of the most effective scale opportunities. to get your code running in places that otherwise might be difficult. And so this is here to state, there's nothing that's going to change to fix this. And as long as you have code flowing around, this is a valuable attack. Now, the other thing on the other side of the coin is that the amount of code being written is rocketing up exponentially. And so I heard that for the first three or four months of this year, the amount of code committed to GitHub was up 20X from the same rate last year. But it's accelerating exponentially. And that's just the code making it to GitHub. Right. I think you may be an interesting point of like, there is a whole new set of people out there that have become software developers, but they don't even realize they're software developers. And there's a ton of code being written and executed locally on devices that isn't making it to GitHub. Yep. And what does that code bring in and run on the machine? Yep. That's exactly right. And so I was thinking about this. Like I uploaded a bunch of medical records and was trying to do some longitudinal analysis about some body metrics and stuff like that. And so me and Claude are having a conversation. I'm getting lots of pretty graphs and charts and numerical analysis. And I wasn't asking for any code to be written. But on the back end, deep, deep, deep somewhere inside of Anthropic, there is a bunch of ephemeral Python code being created in order to analyze the data, create the charts, show it to me. And they're probably spinning up and tearing down these ephemeral development environments and containers all day long. And so but every time they do it, they're downloading the packages they need in order to run whatever it is they're doing. And the velocity of code writing across all of these different endpoints is just going through the roof. And so the GitHub volume was 20X and exponentially growing. So who knows what it is now. If you were to magically understand all code production everywhere, I mean, who knows 100X, 1000X from two years prior. And so all of that code now creates a tempting target for bad guys. And the blast radius is now really expanding. And it's things like Cloud Code Work, because you want the graphic for your slide. Well, that's going to pull down code in order to do the right imports and order to do the analysis for what it is you want to create. So basically, you've got the offensive tools have never been sharper. And the enabled bad guy with AI superset is able to go in and carry out the attack. On the receiving end, the number of victims of the amount of code being produced is dramatically increasing. So two, three orders of magnitude more code than ever before. And so that's created the fertile ground for the staff. Yeah, I had a similar reflection this week when I'm relatively intelligent software engineer. And I've always felt like when one of these supply chain attacks pop off, it doesn't bother me in the slightest from a personal impact perspective. Because I know that I know when I've run NPM install NPM update, I know I've got all my packages pinned to certain versions. So I've never felt worried. And then this week, it really, really hit me. And I felt quite a bit of a panic because I suddenly thought, I know when I last ran NPM update and NPM install, I do not know. Hand on my heart, do not know what my agents are doing. How often have they, he didn't, he had a problem or a bug and just gone, oh, that's a slightly out of date update. I need to pull the new one in. Plus now the codecs and Cloud Code run in, that they prefer to use work trees and VMs, they're constantly pulling in a completely new package tree. And it's only because I told it that I'm super concerned about supply chain attacks that it went through and pinned all those versions. It doesn't do it by default. So it almost feels like we gone from, there used to be two classes of potential victims here. There were people that knew this was a problem, and then they had the budget for it and they spent the money on a artifact tree or some sort of artifact of package store that would, you know, slow this down and hold just the vetted versions. But then there were otherwise folks that didn't have access to that, but just knew to your point how to be careful. But we've now got the problem of a whole, potentially even larger set of people that unbeknownst to them are actually running code and pulling in packages, and they are a supply chain victim ready to happen, combined with the fact that as you said, never been easier to exploit this, both from the perspective of finding the initial compromise, as well as writing the malicious code. So yeah, look, I think this is kind of the week where it suddenly made sense to me that this is massive problem for, literally everyone at this point in time. Yeah. And so let's shift gears now and put on our defender hat and talk about what to do about this. So I think historically, the most that most teams would do is they might do some kind of reputation project assessment before they would choose to ingest a new project. And this would be done once years earlier, and then you would just assume it's they good forever more. And so you would say, we want to use EngineX, and so let's study it and see, do we like their rules and the way they govern the project? And so then, okay, fine, that looks healthy. Let's just use it. And then once you've made that decision, you just keep using it forever. And so that is a way to protect against something that's just a flagrant scam from the beginning. You know, this mask rating is like a valid project. But other than that, it's not really going to do much or catch much. I think most of the effective tools that people had until recently weren't meant for supply chain compromise, but they were meant for, I call it like, auditor defense. And so if you're doing vulnerability management well, you need to have quite a bit of insight into exactly what you're using and what versions. And then if there ever was some kind of supply chain compromise, you can use the information you're collecting for volume management in order to also do the supply chain like after action, clean up, you know, do the forensics response, the things like that. Those systems were designed to answer the question of, where have we been using this compromise package, not necessarily prevent that compromise package from ever entering into your ecosystem? Right, and the question they're trying to answer was, you know, library version nine is just been published. We're using something older than nine. Right, right. And so then the dual use capability of that insight is that on the rare occasion, there's a supply chain compromise. You could then figure out who's using it and clean it up. And then, you know, and you do that once over three years and then move on through life. And so when you're now getting these, you know, very rapid attacks and you have like a six hour window and who was using it and where did this code potentially run, it's pushing teams way outside what their current instrumentation is able to help them with. And so what I think about the natural defense points here, if you have an environment where all code from the internet has to come in through a proxy and it'll land in some kind of artifact or something else, then the internal people can pull from it. Then you can put some kind of control gate on what's allowed to come into your bit bucket or your artifact or environment. So that's the first governance control point. A lot of companies aspire to this, but don't have it. And so the reality is every build pipeline is pulling fresh raw from the internet, whatever it is they think they need. And so now instead of solving it in one place, you need to solve it across all your build pipelines. And whatever number you think you have, it's always like double a triple that number in reality. And so you think there's the 300 we know about and then there's the dark gravity, you know, anti-matter of like how many more that are out there that we're not sure, like exactly how many others exist. And so then you can do DNS tricks and things like that to see who's actually pulling down code from the internet. And so the if you have a single interest point at the proxy, that's one place to do a governance control point, doing it at each of your build pipelines is another natural place to do it. And then now we have all the vibe coders. And so I've heard all these euphemisms. So builders, citizen developers, you know, there's all these different like cute labels we give to the non-technical vibe coding population inside of these companies now. And then things like CloudCowork, OpenClaw, you know, these are now also entities that you need to govern and figure out. And so getting this solved endpoint by endpoint anywhere that you're pulling code down. And so we're now no longer talking about just the build pipelines, but we're talking about all the human endpoints. And so this would be like laptops and workstations and things like that. And then if you have scratch environments for, you know, a femoral server space that people can spin up do an experiment, tear it down again, you know. These are now all things that you want to govern because you don't know what kind of secrets are being put in there. And you know, the perfect world you'd be managing those secrets well, but like we don't live in a perfect world. And so for each of these control points, there are different tools than themselves, the different forms of solution here. And so one of the real naive obvious opportunities is let's just put it delay. Like don't ingest anything that's older than, or newer than X hours or X days. And so you can say three days, seven days, four days, whatever. And so if you look back historically at say the seven day cooldown window, then pretty much every single supply chain attack doesn't get discovered. It has been discovered and cleaned up within seven days. Now the problem though is that if you did a seven day cooldown and that was the only control you had, if you are working on mainline, well governed open source projects, you'll probably be fine. But if your open claw is pulling down really weirdo exotic, like packages that are like from the dark fringes of the internet and like some weirdo corners of open source ecosystem, these things may get compromised and then never cleaned up because they're abandoned where they go for source projects they're just sitting out there. And so the cooldown I think is a compelling thing to consider. But it is not the one and only control that I think people can hang their hat on and feel comfortable with. Just to push back on that being useful, I mean I had an interesting conversation this week with the folks from theory that the ones that released and disclosed or found and disclosed the copyfailed bug. When I pressed them on, "Hey, guys, why did you disclose this the way you did?" They found themselves in a pretty tricky situation where the patches were already released in terms of the kernel patches, not the distro patches, and that's where everything really went wrong. But the patches were available, and they were watching and tracking the trajectory of other projects. They said, "We can see evidence that within two hours of a patch being available in a branch, an exploit will be found by a third party and disclosed." And so they felt like they had nothing to do but to keep the velocity going and announce this thing. Someone else was going to anyway. So to push back on that idea of the seven day cooldown being good, yes, it'll prevent just a supply chain attack. But you were opening up a whole other set of vulnerabilities, which is the moment a patch comes out for a package that you are already using in production. Yep. So you're hoesed from the other perspective, right? Your production environment's gone. So it just feels like an impossible balance to walk of package already out there, deployed in production. Vulnerability is found for that, or even not even disclosed, but just a patch becomes available on a branch. Someone did that, works out how to make an exploit out of it, and then you're hoesed in production unless you start bringing patches rapidly. So they wouldn't be. Do you have to have a separate mindset for developers and laptops versus production to try to close that gap? Or what would you do to sort of walk that right? Yeah. So basically, so I think the cooldown period is a popular home remedy for all the reasons that we just talked through. I don't think it's a stable and sustainable winning strategy, and like that alone. And because this is getting so much attention, there's tremendous frantic investment in the ecosystem of defenders trying to figure out like what's the best way to solve this. And what I'm seeing happening is there's a lot of different companies that are standing up threat feeds where they're trying to identify and catch these supply chain compromises as they're being staged before they've even been fully weaponized. And so they all run together at this point, but there was an exploit. Actually, I think the Axios one where they positioned the malicious package and then half an hour later, they made a code update to the mainline Axios project that imported that malicious package. And so companies, at least one company detected the malicious weirdo package, like popped into existence and said, hey, this looks sus. You know, like let's let's not trust this thing. And then when it got and so it was labeled as like dangerous and bad. And then when it got imported into another project, we said, well, hang on a second, this is important and known bad thing. That's how for at least the set of customers there that were taking that threat and tell feed, they got the tip off that this thing was not to be trusted. And interestingly, that would have worked for the 10 stack compromise that in a different way, right? Because although it was very fast, there was still some pre positioning of that malicious pull request that got raised, ran the GitHub action. Then there was some shenanigans around like, well, actually, I'm trying to think of all the signals that would have made this detectable. And there are quite a few there. First of all, the pull request was raised against something that had been clearly renamed to avoid fork detection. So there's like signal one signal to the pull request suddenly was like made to disappear after it had done its thing. That's unusual. So I could imagine that, you know, there's probably threat and tell companies out there or whatever they're calling themselves that are saying, oh, yeah, this is a new detection we could have. So pull request looks as though it's been renamed to hide the fact that it's a fork. If pull request suddenly disappears, raise the alarm, right? And maybe that could have happened fast enough for then the maintainer of the project before they did the legitimate push to prod, but then actually, you know, detonated this supply chain, right? So that's interesting. So I think the people that are trying to enable defenders to catch this stuff, they're not trying to create like real time within seconds, you know, a tan stack quick don't accept that pull request. You know, they're not trying to solve that problem. They are trying to solve the problem of people who have an import of what is now a known bad version of tan stack. And so then you either, um, and so now on the ingest side. So if you're running one of these tools on your laptop, uh, and you're about to pull down just the freshest version, which is now known compromised, either you proxy that and say it doesn't exist and it'll give you, when you ask for the freshest, it'll give you the last known good as opposed to the last, which is known bad. So it'll pretend it doesn't exist. So that's one thing. The other thing is, um, you can, you just fail the build and say you can't have this anymore because you're ingesting a project that has a current compromise. Yeah. And so that's like another, like, and these are UI choices of how you want to have your developer experience unfold. Um, I like the idea for, cause particularly if you have this like a femoral AI generated code to do some Python chart or something like that, like you just want it to work and using last weeks known good build as opposed to the freshest like last minute known bad build. Like, I don't want that to fail. I just want to work and use the thing from before and then probably AI can like figure it out and make it all work. There is a little subtlety here that that I think is worth calling out, which is, um, we talk about known good and the known good is based on a particular version or pinning it to some sort of identifier. We have seen examples though where if a particular package or the way it's being published doesn't support immutability, it is possible for an attacker to produce a new version of the known good old version, right? So if I've got my, if I've got my package docked, uh, Jason and producing a package lock that it says only pull 10 stack of this exact version. It didn't happen in the 10 stack version. And I'm trying to think of which of the recent supply chain attacks it did, but it just triggers a memory of it's super important to just double check that if you're pinning it to a version that you actually are relying on that version from a package maintainer that is, is probably exercising immutability. Otherwise, it's all kind of moot. Uh, yeah. Yeah. Yeah. And so the bad guys are doing like, um, name confusion and like typo squatting and things like that. And so you're exactly right. And so it's a, a previously like known good version can become bad later, uh, you know, through some of these tricks. And so, and then what happens is when your intelligence feed has now labeled something as bad, then you just can't happen anymore. Um, and so would you try to download the next time it'll fail and, and, and then whatever failure mode you've enabled can handle that. But I guess I was calling it out as an example of that's why that intelligence feed is so important. Because even if you think you're running your local cash packages, even if you think you've pinned them to the versions, that state of the world can change. And, and the only way you're going to really find out about that is some sort of intelligence feed because it's not scalable to roll your own detections for these things. Yeah. So basically, I, I feel like the, the threat intelligence feed about supply chain compromise is, is now a must have. And then the way that this gets expressed within your environment is an area of active experimentation and exploration. And so you've got different types of solutions embedding it into your, uh, depot, repo, uh, like caching environment within the build pipeline. You have things that are downstream of that inside the build pipeline itself. You have other things that install in the developer endpoint environment. And then the way it behaves when it catches something that is not good is evolving rapidly. And then what the defenders are doing is they're studying all the commits that are looking for bad things. They're downloading all the projects and then running them looking for heuristics of evidence of bad behavior. And you can understand the cat mouse game here because yeah, if in the beginning, these things were unbelievably clumsy. And so then the bad guys are making them less clumsy, more subtle, time delays, things like that. And so all, all of this is leading the defenders to have to catch up and do better, better, better and identifying these things. But ultimately, the idea that you need a threat intel feed that is expressed as a control within your code pipelines and environment. And that is defined very broadly to include in federal code, cloud code, like things like that. Um, and it just feels like it's a new must have control that every environment needs to have. And I've heard about a huge number of companies that were really, this is a blind spot for them. And so in the past, you know, 90 days, they've frantically been looking for, you know, what are the options out there? Let's get something deployed right away and get it rolled out. Um, at a level that is not normal for procurement at these big companies, uh, because it's such a pressing need. And speaking of blind spots there, the, like I, this sounds comical to say, but I literally had the thought this week of, should I be running an antivirus piece of software? Right? Because you go through the, when I was reading, when I had that moment of panic of like, oh my god, I don't know if an agent's got a picked up tan stack and, and I'm, am I already hosed? I went looking through the documentation of like, okay, what's the indication of compromise? What's the remediation steps? And to my horror, it was just like, oh, go and look to see if you've got these launch agents running on your Mac in this library directory. I'm like, I don't want that. I want, where's the button I can click that says you system is safe or we've, we've found it and remediated it. So, um, that, you know, the thread until feed, I get that that's a gap, but also just like, it was not clear to me how I could get myself back into a state of feeling comfortable and safe, which, uh, gosh, that was not a good, not a good feeling. Yeah. So I think like the typical corporate environment these days, you're going to be running something like cross-track Sentinel one, Microsoft Defender across all your endpoints, um, particularly on the, the human end point side. So this would be your laptops and workstations. And so you, as a defender without that level and spectability, um, in the corporate environment, like it's really tough as a civilian. Like in-- home life, you know, the idea that you'd have a like personal license for CrowdStrike for like that still feels a little weird to me, particularly on a like a Mac ecosystem. That's what I mean. There's just there's a huge gap here and again to your point earlier, everyone's vibe coding everything and so they're all software developers but they're not running that enterprise-grade safety and tooling here. So it's yeah, pretty frightening gap. Yep, yep. So so in terms of like real actionable advice, you know, one of the companies that's a big name in the space right now is socket disclosure. I'm working with socket as a strategic advisor to their CEO and so I've learned a lot about this from the inside working with the team and so they have a socket firewall that's meant to be deployed on your endpoint. And so if you're doing vibe coding or like hardcore, you know, artisanal, you know, handcrafted human coding, any kind of coding, you'd run this on your own. I love that that's that's emerging as a term on to use. Exactly. Yeah, yeah. And so it's so basically, socket firewall is something I think it's free for personal use and so, you know, their API volume has gone up 100x in the past, you know, six weeks just because there's such an incredible need for this. And so that's something that people can do, you know, for their home projects. And then on the corporate side, there's a number of companies that are active in this space and they each kind of have different opinions about what's the right way to solve it and what to do. But at the end of the day, it all takes the form of some level of insight and threat intelligence into what might be bad. And then some actionable moment of intervention that would translate that intelligence into a block of some sort that would then keep you safe. And the goal is to keep the code from getting into your environment before it can execute. And so stopping it at the download phase or maybe you've downloaded it to disk, but you're not going to run it or include it when you're building your Docker container or whatever it is. And so they all take those shapes. And so, you know, companies that are out there trying to decide what they should go do. It's pretty easy to find out, you know, the half dozen complainers in the market and do the the bake off and figure out what's best for your environment. And it really does feel like this is something at an enterprise control level that just everyone has to have because the old the old ways of managing these risks more than anything else relied on the fact that it was so rare, you could just let it happen and then clean it up later and it probably wouldn't get you anyway. Yeah. It's not not a great feeling. But I think that's that that was like the state of play a couple of years ago. And then the last thing the question for the audience is that if we're seeing 10,000 backdoors a week in the open source ecosystem, where are all the commercial backdoors? Yes. Are they happening? And just they're a little bit subtle enough and because no one can see the commits like we don't know about it. Or is it too much fun in the open source ecosystem? And so they're not happening because that's where all the action is for the bad guys. I don't know. I don't know. Well, that'd be interesting to find out. What's what's your bet? Where if you if you would have put 50 on this? Yeah. So I mean, I think the idea that it's more than zero and more than we publicly know about like that seems quite believable. And it would be very interesting to say is it justice prevalent or is it dramatically different in close source? So I don't know, like I don't know. But I would imagine this sort of like a little bit of a background noise sort of thing where it'll be happening. If it is happening, it's going to be happening in smaller scale, closed source less impactful. And that'll be both why we're not hearing about it and also why the impact is minimal. But I think it's I think there is definitely a non-zero probability of the near term. We see some major closed source compromise along these lines. And we've seen like commercial open source. So Trivi was a project with Aqua checkmarks had some problems. There's lots of other companies. I mean, OpenAI had to like cancel and resign like their different desktop apps for codex because they had fallen victim to that axiom somebody had to do that again. They had to roll the map because yeah, they go they go 10 stacked. So I miss that. Yeah, they get some work to do then. Yeah, so I think I think that's the the thing that I'm interested to see what's happening. And then the team PCP stuff is is quite interesting because they seem to be more motivated by chaos than any like clear, easy to understand financial motivation. Yeah. And so like like what's motivated in driving them? I've heard some speculation in research that I'm really eager to see come out in public because it's quite interesting. It's a huge question mark, right? It's like are they technically capable but haven't worked out what to do with these creds yet? Or is there actually a darker reason why there's no clear purpose for the creds? I have a feeling I know the research you're talking about and also very eager to see where that lands. And I think I mean maybe they just were too successful. So they don't know what to do. I was hearing some numbers of hundreds of gigabytes of compressed just credentials. Like my god, what do you even do with that as a calculator? Well, I tell you one thread that I think could be connected pretty soon on this is how many of those credentials give access to some form of a frontier LLM and how much is that driving the massive scale of distillation happening? Because we know distillation is a problem and we know that it's getting executed in a handful of queries that are mixing into other legitimate uses. And to do that you've got to have a mountain of credentials so that you can spray those attacks around and I do. It's just you've been in the back of my mind that it's not clear what they're doing with all those creds but are they powering that ecosystem of distillation and scale? And that could be just one vector of monetization and then there's lots and lots of others as well and who knows. So yeah, exciting times, man. This is just one tiny little sliver of how the world has changed to a point where it's simply unrecognizable to the thread environment we had one year ago. So it's pretty exciting time to be alive as a defender. It feels like that's how we wrap up every episode. It's a great time to be alive. But you know, even that line you just said about the threat landscape being different a year ago, you know, again, I come back to just my personal feeling that my own threat exposure changed dramatically this week alone and that is a unsettling feeling. Shock. Yeah, I am. I am shocked and I think I've got to touch some grass. Man, it's been great to catch off with you. Thanks so much for sharing these insights and look forward to chatting with you next week. Yeah, it's been fun. Thank you. (upbeat music)