Episode 704: When You Can’t Trust Your Software Updates

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

You're listening to another episode of the CTO Advisor Podcast. I'm Calvin Hendryx-Parker. I'm your host this week and Keith is here with me. Hey, Keith. Hey, Calvin. How's it going? Well, it's been quite a week. In the last seven days in the cybersecurity world, I'm becoming dubbed Black October by a lot of folks out there. So I think that's something we should probably talk about. Yeah. Seeing that you actually support live customers, I'm surprised you even have time to talk.

It's been a busy, busy. Yeah. I don't even want to call it a month. It's been a busy week. especially if you're in the PHP world, but that wasn't the only one. I think the PHP news hit a lot of the headlines because there's just such a multitude of WordPress, Drupal, you name it, sites out there that are in lots of people built lots of little one off little toy sites with PHP. All of them vulnerable to these remote shell attacks.

But that's not the only one. Probably the bigger one was that there was a certificate authority with crackable keys. I believe the funniest one was the number four was literally the private key for one of the intermediate certs, which that poses a huge issue for man in the middle attacks, supply chain attacks, all the things that basically needed to have that intermediate cert in their bundle on your client. So Python was affected by this. So there's been releases of Python out there with updated bundles.

And then there was some poisoned supply chain attacks around the CI pipelines. So LiteLLM, which you may recognize, got attacked back in March, attacked again by some keys that got exfiltrated from the build process due to a key not being fully revoked after it got accidentally pushed into the GitHub repository. That all said, I think the CTOs out there and the people who are in the trenches have a lot of great examples to learn from, from the remediations that these folks are doing in the public.

But let's jump into, I think the core question that I had coming from this, from all the vulnerabilities, were these operator related things to resolve? Or were they developer related issues to solve? I mean, I think you've got both cases here. There are, well, the LiteLLM example is a DevOps issue. Like code got pushed to repositories, didn't get, keys didn't get revoked, which are operational. So you've kind of got the devs and the ops people who are on both sides of this, maybe not fully aligned with one another, and making sure that these supply chains are safe.

And that's how this one really got into the public view. Now, they've had two of these exploits this year. And in each case, they have hardened their CI pipeline. And it's interesting because I think a lot of operations folks may be thinking from the CA cert bundles or just the running of the infrastructure. But this is the applications running on the infrastructure. This is the build pipeline, building your apps. But that build pipeline in itself is an application that is controlled by who?

Who owns it? So that's a very good question. But let's back up one step. And I think one of the things that we've been hyper aware of in just security hygiene is that we need to update as often, frequently and as often. And there's this assumption that our vendors are secure and the security updates that we're getting from them are inherently trusted. This breaks, you know, kind of this whole zero trust architectural approach. So I guess the first question that we should be posing to our audience is how do we implement zero trust when we can't even trust our trusted vendors?

But there's techniques. Like, for example, in the Python world, uv and pip both implement a cool down period for grabbing new packages. That LiteLLM package was only on PyPI for two hours and had 49,000 downloads in that time period. But it was only up there two hours. If folks had been using a good practice of a cool down period on not grabbing the absolute latest whenever their CI ran, they're generally never going to hit many of these things because most of them are remediated within the day.

So if you put a cool down period of two days, never grab a package that was just released within the last two days, only grab the one that was prior, you're not going to hit, I mean, probably 90% or 95% of these type of issues in your development pipelines. So that's the developer side. And to be honest, I've not met many enterprises that are implementing, you know, this type of integration or updates this frequently. But the counter argument to that is the PHP problem.

That you want to, yeah, you don't want, I don't want to wait, I don't want to wait 15 seconds to implement. That vulnerability was so gaping and so bad. Or even the certificate renewal. Like if my certificate is based off a key, the length of one, which is the number four, which is always, four is always the answer. Wow. It's a valid private key. So I think, and you hinted towards this, the LiteLLM kind of gives us a roadmap on how you should think about CI/CD and our pipeline.

I mean, it's hard for them. They're operating a very visible surface area for attack, but they are a great model for how to respond to it and how to harden. They've got the patterns down. They're the ones who are in the thick of it. And I think many enterprise groups could learn a lot from this, especially the case that, you know, least privilege around operations and roles and principals that are running in the CI pipelines. We talked a little bit about this last week when it came to like, what identity does your agent have as in the AI sense?

This is similar in that you're granting permissions for those keys to run in an automated fashion without observation. They should be locked down to the most smallest piece that they could have. So one of the things they did with these keys, once they exfiltrated the keys, was they dropped branch protections and were able to make releases. The branch protection bit shouldn't have been anywhere controllable by a key that was accessible via the CI pipeline. Just shouldn't be. So this is something that I experienced this morning in an adjacent area.

I was messing around with my code assistant. In this case, it was Claude Code, but it could be anyone. And I directed it to stop an experiment or lab that I was running. Then all of a sudden, every application in my MacBook was closed. And I'm like, what just happened? And I went back and I said, you know what? I'll have Claude investigate it. Came back. Turns out that it misinterpreted or it interpreted my command correctly. It expanded beyond the instruction.

Yeah. And it made the mistake, the lazy mistake of basically issuing a kill all instead of killing the process. And then that reminded me exactly how difficult it is to want to secure a system when you've given a process complete authority over the system. And as I was going through, I'm like, there's no way to get the best of both worlds of having this agent that can, one, look through and understand what happened without giving it the rights to my file system in the first place.

So this is kind of an extreme version of what you just described. The process shouldn't have keys that have the ability or the authority over the greater system. Yeah. And I think we're going to see more people diving in on smaller, more specified agents and agentic workers that are orchestrated by a bigger overall orchestrator. Tools like Paperclip, for example, allow you to orchestrate across many harnesses. And it's open source. And I think that allows you to give least privilege and then have an audit trail and probably like kind of AI as judge across the top of all of this.

But that's a lot of moving parts, a lot of infrastructure. And it's not just the simple go open a web browser and talk to your AI or open up Claude Code and know that it operates as you. It used to be like, oh, never log into your system as administrator or root. But all of us basically on our laptops, our desktops have that elevated permission basically out of the box. As you saw, it was able to kill all and kill all your running apps.

That's got to be a pretty dramatic experience. Yeah. I was like, whoa, is there like, did I install Tailscale or something on my laptop and someone's taking over? It's, you know, a regular user may not even notice. Like, oh, you know, my PC crashed. But for us, you know. We're aware. We're aware. We're like, wait, Claude is still running. Like, the only thing that was open was Claude and Finder. I'm like, OK, this was something.

This was an event. I should investigate it and find out what happened. But again, this is the thing that started to have me thinking about how I, when I'm warning other people, like, it is super convenient to give a coding assistant or a harness access to your email. Yeah. Yeah. But when you start to give it ability to send email on your behalf, what is the control you have and your users have over it sending a rogue email or a rogue communication or deleting all of your email?

Once you've given it that right, you either need to give it the right for a limited time bound period or you need to give it least privilege. You should do probably both least privileged and time bound. But we're seeing kind of this hygiene take itself not just from the desktop, but into these systems that LiteLLM, which I think we all use. Yeah. Yeah. And this goes back into a concept as a developer I've thought about a lot, which is like code smells.

When you think about like building an application and you just coded up something and you're like that something doesn't smell right about what I just did. Like it seemed off. It probably is. And I think a lot of CTOs need to adopt that code smells approach to the operations, the infrastructure, the DevOps. If it doesn't feel right, you need to go back and relook at it again. You've given either too expanded a role or there's too much control in one spot or there's not enough granularity in the security.

I think we're going to see a lot of this happening in the near future. And this is just the start. Again, like you mentioned earlier, any one of these exploits 15 years ago would have been the news for the whole year. Like it would have been crazy town, hair on fire. But now we have what, five or six of them in one week that hit. And, you know, we talk about the surface within the Internet, but the PHP thing is so scary because think about all the PHP that happens inside of your network.

Like there's so much we've we've used PHP for so long to create automations and information wikis and all the stuff that operators depend on. It is a thing that, yes, it drives WordPress and all this other stuff. But in the enterprise, PHP is pretty prevalent on systems. You know, a lot of times systems of record. I'm pretty sure there's a lot of people who are administering SAP that looked up and said, oh, my God, this thing runs right on my ECC server.

Yeah. I mean, I wish I could be smug and be like, hey, I don't use any PHP because I'm the Python guy. But we had a we had an exploit as well that we haven't even mentioned, which was the broccoli to shell. There was the Google C decoder Brotli and Brotli CFFI that also had an RCE. The Python world was not immune to this. It's just definitely buried below all these other stories. You know, I missed that one. That by itself is big.

It is big. But in shadows in comparison to the CA with crackable keys and the PHP bit, because the Brotli one, not every pack, not every Python install is susceptible to that. You had to have brought it in either with a transitive dependency, etc. But again, watching what you're doing, watching for the alerts, knowing what's going on, observing your environments and being aware of what's being brought in can help. Again, these all get fixed, patched within a lot of times hours of their releases.

That one was patched as well. Don't grab the latest, but grab the one that's a couple of days old because it's probably got the right thing. So you work for a lot of CTOs. You work for a lot of people in varying levels of organizational complexity. And I think for teams that have dedicated security teams, this is kind of, or if you're a dedicated security team, you're like, oh, yeah, Keith and Calvin aren't telling me anything I don't know. For a lot of CTOs, especially us one man shops, what are some key advices you can give them, not just for hygiene, but tooling that can help them kind of detect this?

Like for me, I went back and asked Claude Code, like I'm pretty sure it was you that screwed something up, but help me investigate how you screwed it up and how I can protect myself. And I think that's the right approach is be curious, stay inquisitive, use the tooling that's available to you. And since we have this wonderful world of LLMs available to us, they are great tools for investigating bits and attacks and process. And I think there's still a bit of first principles, like there's not magic because we have LLMs now that we can just build all these crazy pieces of software.

I mean, you can, but that's problematic. And I think there's still a first principles of software development and security and best practices around deployment that folks cannot ignore and actually need to double down on. And again, lean in on the LLMs. They are great at doing all the drudgery you didn't want to do before around security. Now have them do it. All right, Calvin, take us home. Well, that sounds good. I'm excited about the future. I think the AI is actually going to uncover a lot of these security events and make the world a better place because of it.

That's my optimistic view, Keith. I think I'm with you. I'm hopeful. I'm optimistic that I can have share your optimism, but we'll see. Yep. Sounds good. Thanks, Keith. Thanks, Calvin.