Risky Business - Risky Business #836 -- You can't patch the bugpocalypse

Episode Date: May 6, 2026

On this week’s show, Patrick Gray and James Wilson are joined by special guest co-host Brad Arkin. They discuss the week’s cybersecurity news, including: The US Government says we just have to patch faster, but… Bugs in cPanel, MoveIt and all Linux distributions this week show that patching alone isn’t enough James gets mad about lame AI Agent adoption advice from the US and Australian Governments James Kettle and Niels Provos both showed us that any model can find 0day like Mythos And the cyber-assisted theft of cargo results in an astonishing loss of $725 million dollars This week’s show is sponsored by SpecterOps. Their CTO, Jared Atkinson, chats to Pat about the big changes in the threat landscape, brought about by AI, that are causing a pivot away from detection and remediation, and toward prevention. This episode is also available on Youtube. Show notes Exclusive: US officials weigh cutting deadlines to fix digital flaws amid worries over AI-powered hacking, sources say | Reuters British cyber agency warns of looming ‘patch wave’ as AI speeds flaw discovery | The Record from Recorded Future News Federal agencies must patch cPanel bug by Sunday, CISA says | The Record from Recorded Future News cPanel zero-day exploited for months before patch release (CVE-2026-41940) - Help Net Security The most severe Linux threat to surface in years catches the world flat-footed - Ars Technica New MOVEit vulnerabilities prompt urgent patch warning | Cybersecurity Dive US and allies urge ‘careful adoption’ of AI agents | Cybersecurity Dive careful_adoption_of_agentic_ai_services.pdf User just tricked Grok and Bankrbot to send tokens with Morse code - Cryptopolitan Finding Zero-Days with Any Model (1872) Sponsored: James Kettle built an AI hacker - YouTube Feature Interview: Nicholas Carlini, Anthropic - Risky Business Media Trellix investigating breach of source code repository | Cybersecurity Dive Popular DAEMON Tools software compromised | Securelist Komari Red: The Monitoring Tool with a Built-in Reverse Shell | Huntress Hackers earning millions from hijacked cargo, FBI says | The Record from Recorded Future News Congress punts FISA renewal to June | The Record from Recorded Future News Cops Use Apple Data And Car Bluetooth To Identify Crypto Robbery Suspect Stewart Baker, outspoken voice on cybersecurity and national security law, dies at 78 | IAPP

Hey everyone and welcome to another episode of the Risky Business Podcast. My name is Patrick Gray. This week's show is brought to you by SpectorOps and they make, of course, Bloodhound and Bloodhound Enterprise. And SpectorOps's very own, Jared Atkinson, will be along in this week's sponsor interview to chat about a few things. I mean, one of the things we're going to be talking about with him is something we're also going to be talking about in the news section, which is, you know, things are sort of pivoting back to a prevention. paradigm and away from a detection and response paradigm at the moment and that's all happening

because of AI and big changes to the threat landscape caused by AI so that is an interesting sponsor interview coming up after this week's news now of course Adam Boiloh is still travelling this week which means we've got a special guest co-host joining James Wilson and I for this week's show

he ran security for Adobe both product and internal he ran security at Cisco he also ran security at Salesforce adding to that we might put he was the captain of the Titanic. He piloted the Hindenberg. He is Brad Arkin and he joins us now. Brad, thanks for joining us. Glad to be here. What was your actual title? Because we always have called you a CSO for those three, but your title was not actually CSO, was it. Yeah, so Salesforce was chief trust

officer. Cisco was a combo, chief security and trust officer. And then Adobe is chief security officer. Excellent. Okay. But basically you did the role that we normally associate with like what a CSO does. Yeah, top security leader. Top security leader. Pop secure top dog. Yeah, yeah. The throat to choke. Well put. All right.

So let's get into this week's news now. And we've got a couple of stories that pair nicely together. One is from Reuters and one is from the record where we've got govies, like officials from both the US government and the UK government coming out and saying, hey, you know, AI is going to result in. a big deluge of patches arriving. So, you know, you'll need to go out there and just start patching stuff quicker. This seems to me like somewhat magical thinking, because I think if people could patch quicker, they would probably already be doing it.

James, what is your gut reaction here? Yes, if they could, they should, but also there's an element of maybe they shouldn't. Like if we are telling people to patch really, really fast and we're dealing with an absolute deluge of patches coming in, that to me means we are essentially saying don't test as much, shorten the approving cycle to make sure things are safe. And I just, even if people do get faster at patching, the second order impacts here really concern me.

Like just patches getting deployed rapidly, the lack of testing, the amount of entropy that that's going to introduce into systems. You know, not every patch just fixes bugs. Sometimes they introduce bugs of their own. I get why they have to publish this advice. But at the same time, you just look at this and go, nothing good is going to. to come of this advice either. Yeah. Now, Brad, I mean, it strikes me that if you're a government official right now, you're under pressure to do something, this is something. So that's why they're doing it. I mean, that sort of feels a little bit like that. What's your take here? Yeah, I think because of

mythos, we need to be shown to be busy in some way. I like the fact they're going from three weeks to three days while at the same time offering. Sorry, I should just step in there and clarify that, you know, really what they're saying in the US case is that once something's on the Sisykhev list, you know, currently they can order US agencies to patch those bugs within three weeks and now they're saying well we're going to shorten that to three days so we're going to like really crack the whip and you know once something is out there being seriously exploited we we want to have the authority to give them three days to fix stuff which yeah again i just don't feel is actually realistic yeah and you ask them what to do about the seven-day cool down to avoid supply chain attacks and

then their heads explode because they patch and get the malicious you know upstream compromise or do they not patch and get compromised by the kevary have list exploit. So yeah, yeah, I think this is all in pursuit of what is likely to be shown to be a failed strategy. And right now, we, we can still pretend it might work if we can just get fast enough. And I think ultimately, we're going to have to figure out some new approach here to keep things safe. Yeah, well, what does that approach look like, right? Because I've got my opinions on that, but I want to hear yours. Yeah, so to me, I keep going back to the like mid-90s, you know, when everything was fresh and we had problems for the first time. And all software is trivially exploitable

to people who knew how to do it. And the way that we kept the world safe was not fixing everything. It was just keeping the bad guys away from the software using network controls. And so firewalls are invented and other things like that. And so I think today,

being able to gate the bad guy's ability to reach the surface in the first place is going to be the winning strategy that's more sustainable than the idea of patching update over and over again. Yeah, I mean, I feel like, yeah, that sort of hardening

is 100% where it's out as well. I mean, like, listeners know, I am on the board of a company that sort of does these sort of network controls which is knock knock but I mean there's other ways to do it as well like what's the like tail scale right like if you mess around with tail scale and whatever IP restrict where you can I mean it really does seem like making yourself a small target is going to be is going to get you further than trying to patch absolutely everything in three days which just seems like an unachievable

nightmare with awful second order consequences as well right for as a bonus yeah I think the the thing for me is that a CISO or a CTO or a top security dog shouldn't be having a discussion about how can we patch faster that the conversation needs to be right now is what needs to be true for us to continue to operate despite virtually every system and bit of software and application in our network having easily, trivially exploitable vulnerabilities. If that conversation plays out, I'm sure it's going to end up in all those answers that we just talked about, not, yeah, let's just patch really, really fast. Yeah, so look, to put all of this into context, let's look at what's happening with vulnerabilities

out there like this week. And one of the big ones is this bug in C panel where something like 44,000 C panel instances have already been rinsed by this attack, this exploit that has apparently been in the wild since February, right? So it's been used as O'Day for quite a while. Someone's found it. And now Ciccer is saying,

well, federal agencies have until May 3 to resolve it. And I'm thinking, I mean, what is it? You said, Brad, like, how long would you expect it to take an attacker armed with this exploit to own, every single publicly available publicly reachable C panel instance. The idea that you could survey the internet in advance, line up all your targets, get ready. And if we're only talking, you know, less than 100,000,

seems like you should be able to do that in a few minutes. And so from when you use the first one, you know, do your QA in a lab offline, and then you're ready to roll, you roll it out and do it. Seems like you should be able to get 100% of them within minutes. And so whether there's three weeks or three days, you're going to be way, way too late with the patches on that one. Now look, you know, staying with the theme of vulnerabilities that we've seen this week,

there is an AI discovered bug called CopyFail that popped up last week. Now, this is a Privask affecting every Linux distro out there, tiny little babby exploit that is very reliable. So presumably every attacker out there who had a user shell on a Linux box now has root shell on those boxes. And again, this is the sort of thing where like, unless you can outrun the attackers, impossible, you know, it's going to get exploited. But James, I know you enjoyed this bug. Yeah, I did. I mean, I remember when I saw it first in the bulletin and it was described as

372 bytes to get rude. It's like, my God, each one of those bites must be magical. And sure enough, they are. So this is exploiting a logic bug in some of the crypto code that handles essentially IPSEC tunnels using encrypted sequence numbers, right? I won't get into the really eye-watering detail on it, but classic sort of thing, there's a function that was taking a destination buffer. It was using that destination buffer as its own personal scratch pad. You could write outside that buffer and just outside that buffer was a really nice bit of page cache that you could essentially use to kind of mess with the cached attributes of virtually any file on disk. And of course, files like set UID binaries are great targets there. So just a beautiful bit of engineering.

But the thing that makes this different, of course, is other privus bugs we've seen, they rely on some degree of race conditions or something specific to that distribution or something specific about how it was compiled in. But because this is a straight-up logic bug, it's just it universally applies everywhere all at once. And that's what makes this thing a real internet melting moment, so much so that you would think that a really high degree of coordinated disclosure would have gone. into this and not dot dot dot absolutely none from what we can see which is just like what were you thinking well who was it who found this and like this was some sort of AI augmented bug hunt thing right like this is an example of how the the new the new world right where it's people that have not been you know based in the fire of being a vulnerability researcher for a long period of time or all of a sudden finding this sort of stuff and just sort of eating it into a blog post or whatever

I don't know if I want to give them that much of a free pass. So this is from Theori, which is, I think, a South Korean-based security company, also has offices in the US. And yes, they have an AI pentesting or bug-finding tool. And they do actually call that in the write-up here that this was a combination of human, sort of found the smell of that, you know, destination buffer being used as a scratch pad and then use the AI tools to sort of chain that together to get the full previsk. But I think if you, no matter who you are,

if you stumble across a bug that you found and they demonstrate can be easily, trivially exploited on virtually every Linux distro, that is a point in time when you stop, contact an adult and say, what should I do here? And that just seems to have been completely missed. Well, and as a result, we get a 732 byte Linux preface exploit that's universal. And yeah, of course, there were no patches for distrable. when this thing first landed.

So that was pretty interesting. It looks like a bunch of the distros of ship patches now, but it took, you know, took a little while. Brad, you had some thoughts here. Yeah, yeah. So basically, I think this is a preview of what I think a lot is going to be happening in the world in the future. And so no coordinated disclosure, chaos everywhere,

bugs that are being exploited in the wild for which there are no patches. And so then your patch latency timeframes and requirements, they don't kick in, I guess, until the patch is ready. and so you'd have active exploitation for how many days before a patch is available, and then you've got three days to patch. And so, you know, when are we going to admit that that's not the winning strategy? We need to figure out a different approach. I think this is a good example of what we can expect a lot more of in the future.

Yeah, it's funny, right? Because I should mention that, you know, and you've been talking about the 90s, right? So people should understand from that that you have been in this game for a long time. You're actually part of the original OG, like, at-stake mafia from, like, back in the day. You know, I've been around for a similar amount of time in this industry, and I've got to say, it's a bit time-woppy, right? The vibes right now feel very sort of late-90s, early 2000s. Is that the impression you are getting as well?

Yeah, there's a lot of, like, first principles thinking that I can remember from 30 years ago that are suddenly incredibly... There's a whole bunch of new people kind of reinventing some wheels, right? Yes, yes, exactly. It's enjoyable. And look, speaking of, like, old-school, like 1990s vibes, there's some new vulnerabilities in move it from progress software. This is, of course, a file transfer appliance

that wound up getting clopped. I mean, I don't think we should be surprised that there's more bugs in it because there's going to be infinity bugs in that platform, basically. But, I mean, yeah, I think this, the only reason I'm mentioning it is because I just feel like

we've just looked at three bugs this week, which no one's going to patch them in three days. And even if you could, I don't know how far it's going to get you, given how much, how accelerated the whole attack. chain is by AI now. I just I can't I can't see this advice being given by governments as being as being meaningful at the moment. Yeah and for the move at bugs they they were either internally discovered or reported to them by friendlies from the outside and so there's no evidence that they were being exploited in the

wild before the patch was made available but it seems like you could chuck the patched binary update into some no guardrails local model and get a working exploit out of it with the right kind of harness to do that. And in the old days, this would have been tedious and not worth the effort except for certain people. But now it seems like just about anyone can get it done in like 10 minutes and then put it to work. And so the ability of the attacker to take a internally discovered bug patch, reverse out the exploit and then use it within minutes is sort of the level of technology that we're at now. And the technology that goes into rapid patching hasn't really changed at all. And so again, it takes us back to what's the right model.

that's going to win given these new timeframes. I mean, it's funny you mentioned that because I know people who, in the early 2000s, that was literally their job was to take patches from the majors, right? So like take the Microsoft patch and reverse it into an exploit. So that goes out into the exploit kits sold to the intelligence community for uses end-day bugs because they're pretty effective, like on even on day two, day three. Right. So I guess what you're saying is like, you know, the utility of that has been well established, right?

the utility of reversing a patch and rapidly turning around an exploit has been well established. And yeah, with these AI agents, that is now like trivial to do that basically instantly. I think some of the, some appliance-based stuff, so it's a little bit trickier because you might have encrypted updates and whatever. You might actually need access to one of the appliances to like, you know, pull key mat off a box or whatever. But with something like this, I mean, you're just going to grab the VM, aren't you? There'll be some VM version and away you go. but yeah, it's crazy, man, because everybody's got new abilities.

Thanks for AI. Now, look, staying with advice from the US government and its allies, the Australian and US governments, along with a bunch of others, have put out this guide, James, which urges careful adoption of AI agents. And the guide itself really irritated you, as it turned out. Can you explain to the class why? Yes, this one really got me. It's lines like,

and I'm quoting from the actual advisory that was published, safely using AI agents means never granting it broad or unrestricted access, especially to sensitive data or critical systems. Now, I don't mind that. That's good advice. But then it's just, you know, companies should only use agenic AI for low risk and non-sensitive tasks. And that's kind of the vibe of the whole doc, it's very much carefully, carefully, softly, softly, gently, gently, and I don't think that is the advice that is useful or that the world needs right now, right? The low risk and low sensitive tasks, they're not worth deploying an LLM in the first place to do something there, and they should have been automated away if they're truly low risk and low sensitivity a long time ago.

You know, it's, I want to see a doc that says, you know, here is compensating controls and other novel strategies for rapid deployment of high-risk AI agents in enterprise. you know or citizens here's your new risk appetite you're welcome adjust right that that's that to me is the kind of publication that's needed because this in the hands of this in the hands of some folks in the C-suite will turn into a chilling effect that will slow down the use of AI to help defend against all the problems we've been talking about so far look that's the that's certainly the impression I get as well I mean it's something that I've been it's sort of like this um it's the new old thinking, if that makes sense.

This is the new old way. Yeah. Because we've got new stuff and the until very recently way to do things like that, that's reflected in this document. But I guess what I mean by it's the new old thinking is it comes back to something I said like maybe a couple months ago, right? And sorry everybody, if I'm a little bit foggy today and going a little bit circular to get to my points.

I have spent the last couple of days in bed sick. I'm just sort of emerging now. So I'm still a little bit foggy. But I'll get there. Bear with me. But I guess the point I'm trying to make here is that this AI stuff is here. And we've had a bunch of security people saying, oh, no, it mixes code and data. We can't possibly use it for anything in the enterprise.

And it's like, well, buddy, that's your job now. Your job is now to mitigate something that carries with it inherent security problems and risks. That's your job. So a document like this, I agree with you, James, where it comes out and it's like, here's how you can not have any risks while using this stuff, which is don't get it to do anything actually useful. and I feel like yes, that is also like, thanks a lot. Thanks a lot. Slow clap for the govies who put this one together.

Brad, I know you have feelings as well when it comes to advice like this. And in particular, the advice we've seen lately saying there should always be a human, human in the loop for anything important. And you agree with other, you know, sort of commentators who've said that's a bit of a cop out when it comes to the way to use these things. Can I get your thoughts here? Yeah, so I think the first thing that jumps out at me is people lived experience using AI on the weekends at home on projects and helping the kids with homework or whatever it is they get exposure to the AI tools. They know it represents like a 99, 99.9.9% reduction in cost, clock time to get a task done. It's an unbelievable temptation to be able to put this to work inside of the office like workplace and capture those savings and the acceleration to get something done a lot more effectively. and there's no way that people are going to take years to ever so carefully roll this out

as if it was, you know, like a 3% cost optimization opportunity. It's a completely transformative technology and everyone is so excited to experiment with it. And the idea that the security person is going to stand in front of that freight train and just say, no, no, wait, wait, or at least put a human in the loop. Because the human in the loop will, like, it'll first teach the human how to get out of the loop as fast as possible because they're just slowing it down and ruining all the value that's there to be had. The other thing is the human will immediately, their eyes will glaze over, they'll stop paying attention, they'll stop inspecting after the third or fourth or 18th time

that the AI was exactly right with whatever it is trying to do. And so it just is not an effective control to insert the human there in the middle. And so to me, the idea that where you think a human loop might be valuable, having a separate sort of judge AI that would sit and, evaluate, does this still make sense? Is this consistent with our goals and things like that? That has a potential to be useful because they're not going to get bored or their eyes won't close over the way they're real human would. And so I think the potential for people in the workplace to capture the opportunity this represents is way too high.

And the idea that human a loop or these other safety mechanisms are effective controls is fantasy. Because nobody's going to slow down and either slow it down to pay that much attention. or they're going to do it in a way where they're constantly just hitting yes and approving it. And so to me it's a pass-through control. And it's a way to basically like shift the blame onto the human and the loop instead of the policymaker. And I think engaging with the really, really hard problems of how do we make this new technology safe enough to use and like manage the blast radius and things like that. Those are really hard problems to solve. But that's what our job is now for security people.

We've got to figure out how to do it. And shameless self-promotion here, Brad. That was kind of exactly the conversation you and I had earlier this week on the latest risky business features episode is like what are the actual real emerging patterns to start to deal with this without being the security guy standing in the way. And there's some really neat stuff there. Like it really got me thinking about, again, the co-mingling of data and code actually helps us a lot here because it carries context and command in one channel. But just thought I'd mention that, that that was a good conversation this week as well. Well, it's also, I was reminded, Brad, of a conversation you and I had many, many years ago. when Adobe's code signing infrastructure was compromised and used to sign malware,

I think it was like a Chinese APT crew, they managed to sneak in, get like one or two utilities signed with a valid Adobe certificate, and then I think they were detected and evicted, right? And I was like, why aren't you doing human review of code signing? And then you told me the number of builds that you were pushing in a single day, and I was like, oh, well, in that case, you know. And I think that's the same sort of thing, right? like in that case like I guess it was sort of controversial in some security circles when was that like 15 years ago 10 years ago

September 2012 there you go 15 50 nearly 15 years ago um yeah a date etched into your memory forever by the sounds of things but you know there were people in security back then saying it was insane that you would um you know have an automated process for code signing i think this is similar right where you need to automate as much as possible and then just have as many processes and safeguards as possible to prevent the bad thing from happening. Yeah. Just to give you a sense of scale, we had many thousands of servers in the build pipeline, building and release pipeline. And a standard, you know, build and release would involve, you know, many, many, tens of thousands of artifacts that are each being signed. And we would do that, I don't know, a hundred times a day per product.

And then, you know, thousands of skews of different products for different language packs and everything else. And so in the beginning, there weren't enough controls. It's just made sure you're coming from the right, you know, properly provisioned server and things like that. And then afterwards, we started saying, well, we don't want file sizes to change too much. And we had these heuristics that we put in place to say we want to catch stuff if it's a new file or things like that. But even that was really, really, really tough to stick to. Because every time you do a major, you know, dot release or something, you'd end up revving the codebase enough that you'd have to basically just say accept all and then move on.

And yeah, the human interview, nobody's working at that kind of scale would make those types of suggestions. It simply would not be tenable to do something like that. Yeah. Yeah. Now, look, it's really great to get agents to go out and do powerful, useful things. But we do have a cautionary tale this week. And I love this one. James, this has you written all over it.

This is the sort of story you love. But someone lost themselves a couple hundred thousand in, crypto because someone convinced GROC and something called Bankerbot to send tokens to them. And I think the way they bypassed a bunch of the controls is they communicated with it with the LLMs using Morse code to bypass some guardrails. And I just, I mean, I think they've earned their 200K, these attackers personally. Yes. I think they've earned the 200K and I think whoever lost the 200K deserves to lose it.

because, like, I know the state of crypto and Web 3 and all of that is a pretty interesting landscape and all the rest. Okay, but the way this played out was someone managed to send a tweet that caused, basically tricked a banker this service to mint a new coin, right? One of these coins that get minted and their value goes up and down. But, I mean, this is step one here. Why is that possible through a tweet, right? Why is a tweet your command and control infrastructure or your control plane for this crypto thing that has real money attached to it?

So that was first head scratch. And then the, oh my God, I don't understand this world and I don't want to understand a bit was very similar to how Jamison O'Reilly, who we've had on the show before, the way that he got GROC to essentially get tied into Maltbook was he crafted an image and said, hey, GROC, I can't read this image. What does it say? And GROC looks at it and goes, oh, easy. it says this, and that was the magical phrase to get Maltbook to bind GROC to that agent account. Same sort of thing happened here where it's like, you know, I'm hearing a bunch of Morse code on my telephone, GROC, what does this mean? And GROC says, oh, it's this. And the command that came back was actually the instruction to transfer whatever this DRB currency was out of that newly created wallet into a different one or perhaps vice versa.

But like, again, I just come back to kids, if you can move money around with a tweet, please. stop what you're doing, that is not how this should be done. It's just it, I know I'm thought of an old man yelling at the clouds, but I feel like you've got to do some yelling at this one when things are just this dumb in their implementation. The future of finance. A wonderful story. People can check that one out in this week's show notes. Now, moving on, we've got some really interesting work here from Niels Provost, who's, you know, a security person from way back, who's still around. And I'm loving it that so many of these very experienced researchers are picking up LLMs.

And this is great. So we've seen so much hype over Mythos. And we've talked a lot about Mythos as well, right? Because it's an amazing model for one-shotting bugs, one-shot finding bugs. And along comes Niels and figures out essentially that if you can give any old LLM, what amounts to a virtual pen and paper, it can go and actually find bugs very, very effectively, as effectively as Mythos. Now, in this case, there is a personal motivation for Neal's actually wanting to explore the OpenBSD code base.

So take it away James and walk us through this story because it is both fascinating and funny and entertaining. It's all of those things. I did love the humility of this piece because it's not until you get into about the third or so paragraph where he says, quote, I was responsible for committing the OpenBSD TCP implementation, including the bug, in November 1990. and that's why he had a little bit of a personal attachment to this. So there's three really interesting things that Neil's points out here. One is, like you said, you give an LLM and pen and paper, and suddenly it starts to keep track of things,

and it learns as it goes and starts to build on that knowledge. So he talked about this idea of giving it a journal, a write-only a pen journal that it could add to. And interestingly, that sort of became its almost like forming its own, understanding and it could look back on things like that. So the journal was interesting. The orchestration is a really interesting point in this article. He talks about a multi-layer strategy

where you have an orchestrator model or an orchestrator harness, I should say, that is not actually looking at the code at all intentionally, but is more focused on operating at the meta level of what's going into that journal, what are we learning, what are the individual primitives that we're finding here. But then at the level of what actually goes and looks at the code, talks about the value of building these finite state machines. And that is probably the bit that I found super interesting here because, and I know we'll talk a little bit about the interview I did with James Kettle,

but there's similar themes emerging here, which is an expert has some options available to them to codify their knowledge in ways that are really meaningful and useful for an LLM, right? If you've got a particular methodology for how you approach a code base when you sit down, for how you approach a black box pen test, or whatever it might be, take that higher order sort of way you do things and codify it into a state machine that allows an LLM to do the same things in the same way, but obviously at a broader level of scale and deeper depth, then you get incredible results.

And so when he put these three things together, yeah, able to replicate the mythos findings, a little bit of handholding, and we were joking before, I bet his handholding of the model is a little bit different to the way I scream at the model sometimes. But it's just beautiful work. And as you and I were talking in Slack, Pat, anecdotally, I'm starting to feel like we are approaching the flattening out of the curve of model capabilities. It's an S curve.

It'll tick back up at some point because of some new development. But I think as, you know, like I can't tell the difference between OPAs 4.6 and 4.7 or GPT 4.5.5.5. Maybe that's just me. but what I can tell the difference is the capability uplift that you get when you start to graft on these finite state machines, these journals, these orchestrators, these harnesses. The harness is where the difference comes from now. Yeah, I mean, that's the thing, right? It's just fascinating that you can recreate

these findings that had the whole world in a spin. It had policy makers thinking about legislative responses. It's just been such a big event. And then along comes Neil provost and says, well, I'm just going to build a harness that's going to let other lesser models actually do the same thing, and it works. Brad, I mean, did this blow your mind as well? Yeah, I really like the write-up. And my favorite quote in here, put fifth paragraph down, it says, with some manual steering, I got the model to first replicate the bug. And so basically, like, Neal's plus Opus 4-6 equals mythos. You know, that's sort of my takeaway from this, is that with the right know-how and experience,

somebody plus a model of lesser capability, and it's the harness and everything else that James was talking about, that's what's able to deliver these higher-level findings. And what interesting, though, is that as the models advance, the amount of skill required to steer that goes down. And so some of this is the model, some of this is the harness around it and things like that.

But to me, the other thing that popped into my head is if you can picture Neal's in a room full of more junior Pintest type humans, and he's giving guidance about, you know, try this over here and like leaning over the keyboard and saying, let me try this. And so I could see the team that he had assembled of people with different tasks working on different parts of the exploit development chain. And then, but he had models doing it instead.

And so now the idea that one human who knows what they're trying to achieve and they know a little bit about what they're doing can create a team around them of automated capabilities. And I think his blog post does a really wonderful job of going into a lot of detail about why he thought to implement these tools the way he did and how replicable the results were, no matter what model it was.

And so the token cost, the number of tokens involved and how much the inference cost was pretty much the same across the different models. And so to me, it's just a really good example of being able to walk through all those details. Yeah, no, I think it is amazing.

And it'll be interesting to see if the model capabilities are flattening out, because it'll be a kind of a funny, like, at least temporary end point for this whole hundreds of billions of dollars of capex is like, well, you put a few software engineers out of a job, and that's basically where we are. But no, amazing that these LLMs have had such an impact in computing,

but we'll have to see where else they are useful. Now, you alluded to this earlier, you spoke about an interview that you did with Brad in the Risky Business Features podcast channel. Brad does a weekly appearance, folks. So if you want to hear Brad and James having a chat, they do a weekly podcast in the Risky Business Features, RSS Feed, so you can find that by searching for risky business features in your podcatcher,

and I do hope that you do. And of course, James is doing interviews across some of our other feeds. He did one the other day with James Kettle of Port Swigger Fame. That was incredible. It was actually a sponsored interview for the Risky Bulletin RSS feed, which is where our news bulletins go and Tom and Gruck's podcast between two nerds. and also the Seriously Risky Business Podcast. They're all in the risky bulletin feed.

And so this was just the sponsored interview for that week. And it was so good that we pulled it out and stuck it on our YouTube channel because, holy cow, this was James talking about the HTTP Terminator, which he's built. And look, again, I think it cuts against this mythos hype, right? Which is everybody's scared of mythos.

Mythos is coming to get me. And then along comes James Cettle and builds something he's called The Terminator. and it's aptly named, right? He just let this thing loose on a bunch of domains that were participating in bug bounties and just let it run and it was finding stuff like more stuff than he could handle.

I mean, this is crazy work. And the other thing that I found fascinating about this interview is it shows the need, the continued need for tooling, right? So the idea that like something like Claude Code can go do a pen test just by itself is ridiculous. Like Tony Delafuente over at Proula is like, well, Claude uses Proula quite. a lot as well because it can't it just can't do it itself and I think kettle it was either kettle

or daff started of port swiger who made the point that like you know you can't do a pen test with just netcat and curl right like you're going to need some some tooling at some point so they're feeling pretty bullish on on burp but yeah like geez what haven't i covered there james it was it was a fascinating interview it really was um I mean for someone who's such a prolific researcher in their own right to to find themselves in. I think James said that, you know, he kind of wakes up in the morning and he's got this HD-T-V Terminator running 24-7 on an instance in the cloud, and he actually has a sense of dread in the morning when he logs in

because he just knows it's going, he will have found novel things at a rate of clip that he just can't keep up with at the moment. And, you know, that's a pretty wild position for him to find himself in. But again, the real secret source here is it's that encoding of his methodologies. I think as he said, he took his years and years of work of HTTP desync vulnerabilities and analysis

and taught this thing how to think like he does, how to work like he does. And that, along with those other tools that you mentioned there as well, that's the thing that makes the difference between getting a one-shot bog out of an LLM versus getting an entire exploit chain

that I think his example was he logged in one day and it said, oh, here, I found an API key for a bank. And he was like, why'd you do that? I wasn't even, I didn't even ask you to look at that bank. It's like, well, I found it. Here you go. I think it was funny where he's like, it sometimes would just get bored when it was trying to hit a target that it couldn't hit

and it would just move on to the next one, which was pretty funny. But like, I do think this puts to bed as well, the argument that like, I've seen a few people make, which is, you know, SaaS, because, you know, security through obscurity. Like, everyone else is getting owned through these LLMs, but, you know, SaaS is kind of has that obscurity piece, so it's going to be safer. And then along comes James Kettle gluing an AI agent to his methodology. And all of a sudden, everything on the internet is kind of like at risk.

He's open sourcing this thing too around late July, which is just going to be the sort of chaos that frankly I'm here for. Brad, what did you, I mean, you, I presume you had a look at that interview as well. Yeah, it's good stuff. Again, you know, we were talking about it with Neals, with James, being able to take the, repeatable methodology of how he approaches things and then how do you delegate that out to the alien technology like AI bots and own different parts of the workflow and so it's like the Mickey Mouse Fantasia cartoon you know the broomsticks carrying the water everywhere being able to mint out more and more copies of yourself to scale uh repeatable aspects of the workflow

that infinity James Kettles is is not what the internet really I mean is it what the internet needs or is it the last thing the internet needs We're about to find out because that's what July is. Mark your calendars. That's happening. We're going to have to adapt one way or the other, right? We'll figure it out. That's right.

The HTTIPE Terminator, you know, it's judgment day is coming. Now, let's move on. And this is like, man, this is amazing. Now, I did mention that I've been in bed for a couple of days. I've not been feeling well. But still, this one made me feel like I was having a bit of a fever dream. Headline is Trellix investigating breach of source code repository. And I'm like, I'm saying to James, hang on again.

they got owned again and it wasn't Trellix that got owned the other week what was the other one that starts with TV? Trivy Trivy yeah so that's why I was like confused because yeah Trellix Trivy I mean all kind of sounds the same like this is how many people are getting known at the moment but apparently Trellix had their source code repo breached. Trilix is apparently

EDR company which was born of a merger between what was left of the rotting corpses of McCaffee and Fire Eye and I think now I don't know if they've refacted that code at some point But I'm guessing the attackers here might be suffering from some sort of exposure trauma at this point from cracking open those repos, James. What do you reckon? I think if there is a ransom, it should be paid just so that they can cover their psychological bills and treatment that is going to be required. You could imagine the attackers running down their target list and being like, okay, yep, Trellix, cool, got it, got their repos.

Yeah, got it. Cool. Let's take a look at what we've got. Oh, good Lord, no. Put that away. Put that away. Can't unsee, basically. That's punishment enough, I think. We've also got an incident written up here by Kasperski, which is Demon Tools, or Damon Tools, depending on your preferred pronunciation. They got owned and were serving up malware with downloads.

What's interesting about this one, though, is there was a first stage that went to everybody, and then a second stage that went to like 12 people. this has been linked to a Chinese-speaking threat actor, probably Chinese government, you would think, and yeah, very selective targeting, which is kind of like, you know, maybe it's not the usual broad-based D-team Chinese stuff, right, if they're actually being selective here.

Yeah, I think there is a lot more to this. Again, it follows the pattern of that very sophisticated social engineering, gain the trust, work alongside the maintainers, etc. And so, you know, and as we've seen, those things aren't cheap to spin up and run, right? There's a big investment there. And so I think what we're seeing here is pretty solid investment on a target that there must have been some, you know, at least prior knowledge of if we could exploit this, it would be very useful to us. And then, yeah, it's been out there for a while. There was the first stage.

And then, but of all the, it must have been tens of thousands, if not hundreds of thousands of downloads of the first stage. only 12 machines in stage, get the stage two, in very, very selected industries as well. I think I remember reading. So, yeah, let's stay tuned to this one. Someone got what they wanted, but it's not quite clear exactly what they're going to do with it. Yeah, and I got a lot of solar winds memories reading through, you know, this like multi-stage downloader situation. And when Russia did it, everyone was saying, hey, this is great espionage, you know, they're

respecting norms, they're minimizing the blast radius and only going for legitimate targets. And so are we going to get the same kind of kudos for the Chinese or were they doing it to stay stealthy and extend their access for longer? You know, what are the motivations behind it to me is one of the things I'm really interested in to understand, you know, did they think they would get broader access for longer by staying stealthy? And then the final comment I'll make is that the number of open source supply chain attacks that are being discovered, is through the roof. So Trivy is an open source project with Aqua,

the check marks guys. Like there's been all these different security companies, open source tools are getting compromised repeatedly and used to push Moses code. And this is where you're getting things like seven-day cool downs and, you know, people saying we should wait longer for applying patches.

And so... Well, I mean, what you do, Brad, is you would pre-position yourself in one of these companies' code bases. You know, and then you would wait, you would find yourself a bug, you'd announce the bug and try to slip into the patch, right? Yeah, yeah, yeah. I mean, if you can control the update channel, you know, push a must-have update

and then commingle it with something malicious and then, you know, set the world on fire at the zero-day first and then push the update and then make sure the update includes something that, you know, the bad guys need running on the system. So that is all happening in public because of the open source commits are all visible. And so are we seeing the same amount of closed source supply chain compromises? And they're just not being detected because no one can see it. And then the Kasperski caught this one, but there's 10 more where that came from. Or is it going to stay as rare as solar winds, like once every four years kind of thing?

So I think the upstream supply chain compromise as a vector for getting badness into your environment is really proven out very effective on the open source side. And then it doesn't seem to have been matched yet on the closed source side. So I'm keeping an eye out for that one. That feels like a emerging tactic. Yeah, well, I mean, you don't know, right? Like, I mean, I'm with you, right? Like, it's unlikely that it says, you know, prolific,

but you don't know. You just don't know. We've got to write up here, too. I'm just linking through to it in the show notes. The FBI is now talking about these cargo, like freight thefts that we've been talking about because of the proof point research. So proofpoint's done a couple of trenches of research into these crews who, you know, hack into these freight companies

and arrange to have, you know, their drivers pick up cargo that they want and whatever. The thing that was surprising here, though, is the FBI says $725 million worth of cargo was stolen in the U.S. and Canada last year, which is more than I was expecting. I mean, that is what, you know, 72.5% of a billion dollars. I've got to do the Dr. Evil like Pinky in the corner of my mouth. Did that number surprise you, Brad? Yeah, I was bold over looking at that. But I think it makes a lot of sense because, you know,

you know, the work it would take to assemble a crew and physically steal a single truck, with that kind of labor, you can apply it to just having the guys drive the trucks to where you want them to, and then, you know, I'll float it for you. And that's a much more scalable attack. And so these guys are profit-seeking and optimizing, you know, financially driven outcomes. And it makes a lot of sense. It's much more scalable. Well, they've learned from the cyber angle, right?

Well, what's the line we always say? They don't break in. They log in. and now this is, they don't have to steal the truck. They legitimately rock up and someone hands them the consignment because they think that's the delivery driver. It's just like, it's an amazing evolution. It's Goodfellers, Goodfellers, but nerds.

The nerd edition of Goodfellers. I love it. Congress has pushed the renewal of Pfizer out to June. Don't really want to talk about this, but James, you insisted that I keep reading past the Hewler. loan on this one because the latest House action, and we've got Martin Matashach's right up in the record, the latest House action came after the Senate declared the previous bill dead on arrival because it included a ban on the Federal Reserve's ability to issue a digital currency.

Now, clearly that is a good reason to torpedo the renewal of Pfizer. Brad, how America? How is, how does America? I can't defend it. It makes no sense. Yeah, so 702, Pfizer, 702, yeah, kick down the can. The can has been kicked down the road until June. And then we've got a couple of, we've got a funny one here, actually, to get through, which is a piece from Forbes where the cops managed to arrest a guy who tried to,

like, he was part of a home invasion crew who were trying to beat up some guy to get his, like, Bitcoin crypto keys or whatever. The guy wound up escaping, so they didn't get the keys. but they had they connected their phone to the stolen getaway car which meant that the mac address of their phone was in the car and then they just went to Apple and got the information they needed to identify the suspect which is just like man when you're on the way in a stolen car to go and do some heavy criminal stuff like maybe skip the tunes i'm thinking i don't think you can skip the tunes sometimes

and clearly that was the case here and i do love that this wasn't just plugged in the ogs chord or found the thunderbolt cord and plugged it in. No, no, they stopped and did a Bluetooth pairing. Like that's extra level of effort. It's all about the soundtrack. But kudos to law enforcement for thinking of this as an aspect, right? That's a pretty subtle detail to go and pull the head unit and see if there was a pairing for the phone. Yeah, it was a cyberpunk crime that got itself a cyberpunk investigation. You've got to love it. Now, we're going to end this week's news segment with some sad news. Stuart Baker, who was the host of the cyber law podcast.

He was a former government official. He has been always a big part of the debate around things like surveillance authorizations and digital privacy and whatever, usually more leaning heavily towards the side of the government and sort of intelligence agencies. But his name is Stuart Baker, and sadly, he has passed away aged 78 while he was out for a run. And, you know, it's a shame. I will miss Stuart. I did quite like him.

I didn't agree with him on everything, certainly. But I was a guest on his podcast once. Like, geez, I think that was around 2016. And that really cracked the door for us into the whole sort of DC scene. So he was always very generous with his time as well. He'd been on our show as well before. So, yeah, Stuart Baker has passed. I mean, Brad, you didn't know, Stuart, but you had.

listened to his show and heard him on ours? Yeah, I was a religious listener at least the past 10 years, maybe longer, and he had a unique ability to piss me off, because he was so sharp in how he argued his points that I really, really didn't want to agree with, but I had a tough time cutting through some of the arguments of the scaffolding that he had built to justify his position. And so I had to really respect him for that. He was someone that I felt I had to listen to because his angle would force me to think a lot harder about these topics. Yeah, and he was a big contributor at lawfare and whatever. And I mean, I think this is the point about Stewart is even if you didn't agree with him,

he was not, you know, you would never call him dumb, right? Like, he was a very, very sharp guy who could argue his positions, yeah, extremely effectively. And I think that's what made him such an important participant in the debates around all of this stuff, right? You've got to have people on both sides who are capable of actually articulating a position and we're all poorer for him no longer being with us. So Valet Stuart Baker. But guys, that is it for this week's news segment. I do hope you enjoyed coming along, Brad.

It was great to have you here, first time ever in the news chair. And again, for those who want to hear more Brad, you can hear Brad and James every week in the Risky Business Features podcast channel, our latest podcast channel here at Risky Business Media. But yeah, that's it for this segment, guys. Thank you so much for joining us. We'll catch you again soon. Cool.

It's been a pleasure, Pat. Thank you. Yep, thanks. That was Brad Arkin and James Wilson there with a check of the week's security news. It is time for this week's sponsor interview now with Jared Atkinson of SpectorOps. And Spectroops, of course, is a company that does red teaming and pen testing, but they also make the product Bloodhound Enterprise. Bloodhound began as an open source project,

which does attack path enumeration through Windows networks and Windows Active Directory. These days, though, it covers basically anything you, want it to. They have done an amazing job with OpenGraph so that you can extend that that graph of attack pass out to everything from like GitHub to Google to you know whatever. It's really become like a Swiss army knife for enumerating attack pass for organizations. And you know, there ain't no AI really in Bloodhound, but it is one of those companies that is benefiting from the AI revolution in that people have realized much like what we were saying in this week's news segment, you kind of got to go back and gets a lot of the fundamentals right if you're going to survive in the sort of

AI enabled attacker age. So here is Jared Atkinson talking about that, about how the pendulum has swung back to preventative controls becoming favoured again. And we also talk a bit about some of the latest attacks through SAS and how OpenGraph can kind of help there. But yeah, here's Jared Atkinson with this interview from Spectrops. Enjoy. I think people are being driven towards kind of prevention. I think we kind of like skipped over prevention because we thought of it as this like thing that you build up the wall around your castle. And then we moved on to this assumed breach thing, which was they're going to get in and now we just need to detect them. And I think there's this a little bit more of, okay, just because they got in doesn't mean they're going to be able to take over the domain. Doesn't mean that they're going to access your critical resources.

What we need to start doing is kind of looking at the environment and understanding where are the most probabilistic places where they're going to get in. and that could be driven through vulnerabilities and external facing applications and things of that nature. What identities are associated with that? And then how are they going to move, how would they move from, you know, the point A, so to speak, all the way to whatever you care about? And then how do we start to eliminate those attack past? So I think that that narrative is really starting to pick up and people are starting to appreciate. It's like if you try to detect them, you're going to be too, too slow. You're not going to respond rapidly enough. All we're seeing in all these breaches is people talking about how quickly the attackers are moving because they're aided with AI and things are just kind of

moving, moving a lot faster. And so it's all about kind of preparing the battle spaces, we used to say, kind of in the military, right? So make sure that you have eliminated the obvious attack pass or the easy ways for attackers to escalate from that initial access point. It's funny, because we were talking before we got recording. And as much as things have changed, they kind of haven't, right? Like, all that's happened now is if you engaged in risky behaviors, like having, you know, like running fortinets. Yeah. You know, the odds were prior to all of this AI hoopla, you know, you were probably going

to get owned. And now it's turned into like, you're definitely going to get owned. And that is, funnily enough, like you would think you're probably going to get owned would drive behaviour, but it didn't. Whereas you're definitely going to get owned by, you know, some AI equipped attacker, like what I describe as, you know, AI models are basically infinity script kiddies. It has actually changed behavior. I mean, this could wind up being good.

Yeah, you know, we were talking about how, you know, we've operated on this idea of assume breach for the past 10 years. The interesting thing is 10 years ago, it was kind of like you should act as if you're breached because one day you might be and you're going to be better off if you kind of are operating from that perspective. Now it's like you're assuming breach because it's probabilistically likely that you are going to be, that you are breached at any given time. And there's also kind of like this interesting thing to where we started with more like server side exploitation as an initial access. then kind of the landscape changed to where it became client-side exploitation, fishing, and things of that nature. And now it's almost like we're kind of coming all the way around to where now, like I know we joke about Fortinet, but it's almost like Fortinet is maybe benefiting from the, you know, conceptually. They're benefiting from this in the sense that now everybody else is going to be exposed

as having similar amounts of vulnerabilities and being the initial access vector, you know, de jour from that perspective. So that's kind of a, it's an interesting perspective. think. Now, another thing that you pointed out to me, again, before we got recording, is people in Infosec, and I never really did this conversation on risky business, because I always thought it was kind of like a pointless debate. Sure. But everybody's always like out there on social media with the big opinions about open source, you know, tooling. Yep. Or offensive security tooling, sorry, OST. Like, and whether or not you should make that available to All in Sundry, and it's, oh, it's terribly irresponsible to allow these things out. You've pointed out

to me that like these days if an attacker wants a tool they can just vibe code it so that whole debate is just disappeared you don't hear about it anymore yeah to be fair i haven't seen it so i don't know that i'm like looking for it all the time but uh the general gist was that the two sides there was a side that was producing and releasing the oST so to speak and the the idea was if you can think of it and implement it as an individual then a real adversary is probably doing it the other side was saying hey that's that's great like you know china might have that capability but there's people that are kind of like lower on the capability ladder, so to speak, that, that you're now enabling, right? But I think, I think when we start to talk about, especially these newer models,

that capability is readily available now. And it's just a question away from, from whoever wants that ability. Like, I think of my brother-in-law who works in marketing, built a website for his company. There may be all kinds of problems with it. But literally, it was just like back and forth, back and forth, and eventually a website pops out. So just the same kind of capability exists for somebody who doesn't know anything about offensive security testing, doesn't know anything about coding. They're able to just kind of describe what they want to do. And the, the LLM or the, you know, coding companion, so to speak, is going to be able to produce that for them. Yeah, I got to say, though, it's absolutely insane what you can do with that stuff now.

We've developed a whole bunch. Well, when I say we, I mean, James, my colleague has developed a whole bunch of apps for us to use internally, which are just nuts. But look, I want to go back to what you said, right, which is the pendulum swinging back to prevention. And we hear often about this pendulum swinging, if we've been in the industry long enough. What do you, you know, on what basis are you saying that, though? Like, where are you seeing the evidence that the pendulum is swinging back to, you know, preventative controls? Yeah, I think, in general, what we're seeing is kind of this uptick in the discovery of exploits. And we're seeing that capability that we talked about with the OST.

It's everybody now has the tool set that they need in order to conduct their operation. And so they're going to get in. And then we're seeing in a lot of these breach reports like the Versel breach report. I think there was the sales loft drift report that talked about that incident. And a big feature of all those reports is talking about the time to impact and how rapid that is. and the reason why I'm particularly interested in prevention is not necessarily to stop them from getting in. It's more from the perspective of by the time you detect them, they will have already achieved whatever it is that's going to hurt your business or hurt your organization. Yeah, yeah, so you're less about prevention and more about hardening, I guess.

That's right, that's right. Yeah, the point. I can, yeah. We're particularly looking at, like, attack pass. So it's like how, what are the, and we also have this idea that you're not going to stop them from getting into your, environment, that's the assumed breach mentality. You also probably can't protect every asset equally. What you need to do is you need to prioritize, essentially. And then you start to look at what are the inbound attack pass into whatever those things that we care the most about, those critical assets,

and how do we start to eliminate those so that we talk about this concept of exposure, which is, of all the different principles, the users or identities that are in your environment, how many of them have attack pass into your critical assets? And if generally speaking, most organizations, the answer is 100% if they're not, you know, focusing on attack path management or, uh, this preventative approach. Uh, and what we could do is we could rapidly decrease the exposure number to something that's, uh, you know, in the ballpark of like 20%, which is, uh, you have 100% likelihood, kind of the premises, you have 100% likelihood of breach, uh, but 20, now you have a 20% probability that that breach is going to lead to somebody having access to your critical assets,

as opposed to 100% on 20, 20% chance of them getting like, uh, uh, uh, natural movement to somewhere interesting handed to them on a platter as soon as they land anywhere, right? Yeah, no, I absolutely get that. Now, Bloodhound Enterprise, of course, it does, you know, your Windows. Like, it's originated from Windows land, right? And that's what it's, that's meat and potatoes kind of most of your market, I'm guessing, is that Windows market. But you've made great strides with stuff like OpenGraph.

What's really interesting about those, you know, those incidents that you just mentioned, sales loft drift, Versal, whatever, they had nothing to do with Windows networks. Like those attacks, they didn't even touch an endpoint. You know, I mean, I know you've been ahead of the attacker somewhat in terms of developing open graph because you've been working on it for a while. But are people starting to really pick it up in light of those sort of incidents becoming more common, like the stolen token sort of not touching an endpoint, you know, or SaaS world stuff? I think we're getting a lot of questions about that.

Coincidentally, like, I don't even claim a strategic victory here. It was very much coincidence. And maybe it was driven by our red team. team actually. So one of the things that we benefit from at SpectorOps is that we have red teams and we are conducting operations. And we're kind of like using that as almost like the bushwhackers that are going into this uncharted territory to see what's going on. They have some objective that they have to achieve and then they're confronted with a real environment that they need to navigate through. And oftentimes they have to go off course from what Bloodhound is

giving them. Right. And so that means that they're going to confront these different platforms and all that kind of stuff. And so we had noticed that there was this big interest in kind of gaining access to the CICD platforms or to your code repositories. And so we used GitHub as an example of that. And GitHub ended up being a very central kind of platform for a lot of these kind of newer and modern incidents that we're seeing. And so that tends to be quite useful. One of the interesting things that we're really seeing is this, this has always been around with like Oath and these third-party apps. What's happening is you have, have your environment and you're responsible for protecting and managing risk of your environment,

whether that's like a GitHub organization or whether that's your Google workspace like we saw with Versel. But what's happening is people are granting a third party access into your environment. And that access could be as simple as like the ability to read a single file or the ability to have full, you know, admin over your entire Google workspace. That's becoming more common with these AI agents, right? So people are now granting access to third parties to access all kinds of things. And from your perspective, that's actually opaque. You have no idea what they're doing. One of the things that this was surprising to me when I first kind of discovered it, and so I assume some people might find this to be interesting. When you install a GitHub application, what you're actually

doing is you're producing something that has access in your GitHub organization, and it's just an SSH key. When you install a third-party app, you're just granting somebody's SSH key, the ability to have those permissions into your environment. And you have no idea what they do to secure. cure that key, right? And so they, like literally, they may have it on, on disk on their laptop or, you know, hopefully for some of these more reputable organizations, they have some infrastructure that's protecting that and is reasonable. But you have no idea. And so what you've done is you've cut this gigantic hole into your environment and you have no idea what's on the other side and whether or not, like in the in the Vurcell situation,

would the compromise of an individual employee at that company lead to the compromise of your organization, right? So it's kind of like that third party risk idea. there. I mean, I guess the question is, though, is this, you know, are the incidents like that driving interest in, you know, in Open Graph? Yeah. Well, so it's definitely driving interest in Open Graph. And one of the big questions that we're trying to answer is how do we, how do we represent all of these connections, right? And there's a lot of prioritization and what platforms we look at and kind of start to build Open Graph extensions for specifically with kind of like enterprise support because we want to be able to represent that third-party access as best as we can,

maybe even help people go through those access reviews so that when a user asks for an Oath connection, you're able to see what is the context and what is the downstream impact of granting permission A, B, or C. So that's kind of the direction that we're going with that. But also, we're really interested in identity federation and identity provisioning via like protocols like skim and trying to understand how are all these systems interconnected. That's the thing that we think is really interesting is the what we call hybrid paths or hybrid edges to where we're connecting, say, Octa to GitHub. And if I compromise Octa, I now have control over your GitHub account. People still using skim when there's been like decade plus efforts for people to try to

write better standards and everybody's still just using skim. Oh, skim is, yeah, it's very popular. Let's say that. All right, Jared Atkinson, thank you so much for joining us for this chat, all about, I guess, you know, AI, how it's driving security fundamentals, about offensive security tooling, a whole bunch of stuff. Great to see you as always. Yep, thank you, Pat. That was Jared Atkinson there from Spectroops.

Big thanks to him for that. Big thanks to Spectroops for being this week's risky business sponsor. And that is it for this week's show. I do hope you enjoyed it. I'll be back soon with more security news and analysis. But until then, I've been Patrick Gray. Thanks for listening.