EP270 The Convenience Tax: Why We Keep Failing at Supply Chain Security

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Tim Peacock, Senior PM for a bunch of stuff in Google SecOps, and of course, Anton Chuvakin, reformed analyst and now senior staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, youtube.com/@cloudsecpodcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners on the Google Cloud Security Community page. Anton, this is a fun episode because we're doing something timely and actionable for a change. We rarely do this, right?

Correct. And I think that it's probably timely for everybody and actionable for a few people because some of the actions are quite hard. It's one of those types of advice that eventually would be added to the fundamentals, but right now they're kind of still quite elite. I think top-tier orgs would use some of the advice, but very little of this is mainstream compatible, to be honest. Well, some is.

I don't know if I fully agree with that. I think the principles are super sound.

Yes, all principles.

If you don't practice an action, you can't do the action when you need to. That's true of literally everything. So maybe, listeners, without any further spoilers other than hold on to your hats for a South Park reference, let's turn things over to today's guest. Today we are joined by Dan Lawrence, the CEO and co-founder of ChainGuard. Dan, thank you so much for joining us today. Exciting times in our industry, as always. We just saw a security tool get used to pop an AI infrastructure tool to eventually pop a bunch of end users, including A major networking company. This is like a security turducken of doom. Does everybody remember turduckens? Is that a very American reference? My question is, like, have we reached the point where our security tooling is our unmanaged attack surface and it's our, our biggest one? Like, what's going on here?

Yeah, it's buzzword bingo, basically, the way you explained it. You didn't even go far enough back though. There was like an AI tool that was used to pop the security tool to then pop more AI tools. Yeah, it's buzzword bingo. And it was all during RSA when everyone was busy at sales meetings and customer events. They couldn't have picked a better time for something like this. And yeah, this has been inevitable for decades. I always go back to Ken Thompson's famous paper, Reflections on Trusting Trust, that showed it's impossible to have any faith in modern computing at all unless you hand-reviewed every line in every compiler that was used to build every other future compiler, which no one did because I think it was so scary when he explained it that everyone just blocked it out of their minds and It didn't exist. This has been inevitable. And I think, unfortunately, we're still at the early stages of this one, because supply chain attacks like this, especially from a patient attacker, are scary and cyclical. That first breach on Trivy, it didn't even just hit Trivy. Going back to mid-March, they hit a bunch of popular open-source projects and basically stole all of their credentials that happened to be in their CI systems. Then a couple of weeks later, they were used on Trivy. And instead of just ransomwaring Trivy or Aqua Security or something like that, they put malware into Trivy to steal everyone else's secrets and credentials. I've seen reports that it's like terabytes and terabytes of data that they got that they're still sifting through. The LightLLM AI attack was, depending on how you count, like, you know, really the third major step in this one, but there were a lot of smaller ones along the way. And once again, it wasn't ransomware on a specific company. It was more and more credential theft on everyone using those tools. So, it's kind of going fractal at this point, where each one leads to an equal number or more follow-on ones. And every day until this kind of slows down, the whole industry is going to be waiting for the next shoe to drop.

I have an odd question about this. So, you had a company launched a few years ago, right? Largely focused on software supply chain security. Google has published papers about software supply chain security a good number of years ago. Maybe I'm weird. Again, I use this line too much, but it always felt like an attack that is perennially second priority to people. Credential theft, vulnerability exploitation, phishing. Wake up any security professional at 3:00 AM and say, top 5 attack vectors, top 3 attack vectors. Probably they would not name software supply chain. They would name, again, all the reports, would bring up this other stuff.

Yeah.

What was that moment when it kind of broke? And if you wake somebody up this night, they probably would name software supply chain attacks in the top 10.

Yeah. I mean, if you woke them up today, they'd probably say that because that's what they're dealing with right now. But that's sort of the problem with the industry as a whole. And it's not really a problem, it's inherent. Attackers have an advantage. Everyone knows that. And defenders have to defend where attackers are attacking every given day. It's a multiplayer game. If you're securing what you think is most important and an attacker decides they're going to go spend time somewhere else, you're wrong. So we kind of have to be playing this cat and mouse game because security will never be perfect. And persistent attackers with enough time and resources can get in anywhere they want to.

But why this particular mouse squeaked at this particular time? Any spiritual, metaphysical explanation as to what changed in how we do it? Like, we have a hint at that later on about auto-updates finally growing and all that. So no, I mean, it's basically kind of random that it'd be Wait, aren't auto-updates a good thing, Anton? Well, go ask him that question. Fine. I'm not going to go metaphysical on you, but— I don't know.

I think there's macro answers and micro answers to that question. And I think the biggest macro one is actually good news. And I think it's because, like you said, though, for decades, there have been way easier ways to break into companies. Let's Encrypt rolling out HTTPS everywhere is like barely a decade old since Chrome actually started enforcing the red, not just a little scary red X and blocking sites with HTTPS. Anybody could steal your password at a Starbucks, right? In recent history, 2-factor auth has only recently hit ubiquity because of folks like Google and everyone forcing this across the internet by sheer will. And so, at some point, attackers are lazy and they take the easiest way in because they're busy people too. The shift to this is a sign that security's done a good job, not a sign that we've really screwed up. We've made it so hard that attackers are now doing this. And I don't mean every website is now secure and turns these things on because people still get popped with websites having passwords in plain text and date of births of entire states being in plain text on HTML and stuff like this. Security is never going to be perfect, but on the macro, we have done a good job as an industry. And so, that makes attackers' jobs harder. But supply chain attacks are different by nature too, right?

Yeah.

They're not targeted the same way other attacks usually are. You don't target a specific company and then try to get in through their supply chain. You can, that's a lot harder. It's really indirect. The right way to do it is to target some company's supply chain and then see who happens to be caught in the blast radius after that. It's kind of like fishing by net instead of fishing by spear. You don't know where you're going to get, but you're going to get something. And that changes the risk profile a lot. In the old days, if you weren't a Google, Facebook, Amazon, or Microsoft where you have the crown jewels of everyone's personal data, you didn't really have to worry about nation-state Now you might have to worry about a nation state even if they don't know your name, because you could just get caught up in the blast radius of one of these bigger ones.

Thank you for this, by the way. This really helped set the context.

I like that there's a moment of optimism in there against Anton's depressing metaphysical mice. So thank you for that, Dan. I want to pick on one of the tactics we saw employed here where they force pushed malicious code to existing GitHub tags. We've been talking about pinning to SHA-1 for years. Clearly, nobody's listening. So, what comes next? Are people going to listen, or is convenience the enemy of the good here?

Yeah, I think it's a case of failure by GitHub to really make the Actions platform secure by design. Pinning by tags, like, it's good, it's not bad, but it also isn't perfect, and it introduces a lot of problems at the same time. And it's taken decades for people to actually figure out how to do secure package management. And I think the Go team at Google, I think, did an incredible job here. And if there's ever some award for securing systems at scale with elegant solutions that people don't ever have to think about. I think they all deserve to win that prize. The way they built the transparency log, and the go.mod, and go.sum system to stop these attacks at the source without people even having to think about it, and pin all of this stuff by default. It's novel work they did. It's new computer science theory they had to invent, and did all of this in an ergonomic way. Unfortunately, GitHub Actions, when it rolled out, ignored those decades of mistakes other pieces of infrastructure made, and is now relearning them, right? People often malign npm as, like, you know, the worst of the package managers. And, you know, they started early, like everyone else, made a lot of mistakes along the way, and made a lot of improvements. But not even npm lets you silently push over existing tags in the registry, right? But GitHub Actions just kind of forgot about all of this and lets you silently push over tags in the registry because they don't even have a registry concept. It's all just Git tags and digests.

What could go wrong?

Even if you pin them, though, there are other issues with the design.

No, no, no, no, Tim, not what could go wrong. what did go wrong or does go wrong, right? You should, like, leave your what could go wrong be and go with a new one, what did go wrong. Yeah. So, yeah, it's like—

But even if you pin by digest, like, the Palo Alto folks showed a couple of years ago, like, the actions are fundamentally unpinnable. A bunch of the way they're designed is, like, the action itself is just a file. And the first line in the file says, run in this Docker image, and the Docker image is unpinned. So, if you pin by digest in a lot of these, you're just getting a false sense of security because there's immutable pointers sitting behind the immutable one that you're you've pinned to. It also, this attack also hid in plain sight with another vulnerability our team had reported to GitHub a couple of years ago called imposter commits, where the GitHub infrastructure, this comes up constantly in different ways, but in their infrastructure, every fork of every Git repo is stored in the same underlying data structure. They're all Merkle trees. If you fork, yeah, don't duplicate all the contents. I get why you would do something like that. But when the Trivia attack happened, the action was pinned by digest, but it said actions/checkout and some digest at the end. Any normal person would think that that digest came from the actions/checkout repository. It did not come from the actions/checkout repository. It came from an attacker-controlled fork of the actions/checkout repository.

Wow.

But because the GitHub model deduplicates all of these things, you can pull a commit from a repo that doesn't even live in that repo. So yeah, it's craziness.

You're making my morning very sad.

Yeah, I am. I mean, I am, given that it touches areas that I don't deal with on a daily basis. I think you are just bringing this beautiful new brand of paranoia to my life, and I really love it. Thank you. But I have a different brand of paranoia to bring. If I look at all the Twitter jokes about this incident, because of course there are Twitter jokes about all sorts of horrible things, there are a lot of people who joke about disabling auto-updates, people who update slowly winning. people who are behind on updates. And I'm legit nervous about people actually thinking that the supply chain attacks that can get discovered within a day or two, the answer really is delaying updates. And I feel like it's causing some damage to that thinking. So, what is your reaction to this? Is it in the world of updating auto-dependencies and move-fast culture, and, like, what are you talking about? Humans cannot possibly do it. What's the answer? Like, something I doubt it's the code scanning, but actually, maybe it is code scanning. Okay, fine. You answer the question.

Yeah, there's, the right answer is always somewhere in the middle here, right? There's, yeah, I think all of the whole cooldown period stuff started from some Snyk research paper, I don't know, 4 or 5 years ago that said, hey, look, if you just wait a week, then all malware we've ever discovered has been caught within a week. You'll be fine. There's a couple problems with that. Well, one is if everyone starts doing that, then, you know, somebody just puts a time.sleep 6 days or 7 days into the malware and no one will notice. And 2, yeah, like then it just starts escalating. If everyone's waiting a week, then you wait 2 weeks, then you wait 3 weeks. And that's only one class of supply chain issues, right? There's a whole other set of them where there's a zero-day or a CVE discovered that's being actively exploited, where you can't afford to wait 7 days. So, you know, I hope no attackers are listening, but like, you know, the craziest one ever would be if they put some malware into a project and then disclose a zero-day and everyone rushes to update it as fast as possible with that project. There's no perfect answer to any of this stuff, right? Just imagine if that exeutils guy that had full control of the project hid that stuff in there and then told everyone about an RCE.

Wow. That is— paranoia goes up. Lovely. Yeah, that's really good.

You can't wait forever, because then you're gonna get hit with, you know, an accidental vulnerability. So, the right answer is somewhere in the middle here.

I like this, everybody waits a week failure mode. It reminds me of everybody does index investing, we have no price discovery mechanism. There's funny parallels there. I actually did want to talk about the XZ Utils attack. Where with this kind of socially engineered attack, we had trust but not trustworthiness. And so how are we as an industry going to look at this part of the problem? What comes next here?

Yeah. When you say, if you ask every CISO what keeps them up at night, they're probably not thinking about this, but—

They should be.

That long game nation-state level attack is kind of the one that I think keeps me up at night and a lot of people that care about security for the industry as a whole. That was one where somebody, you know, over a couple of years established trust in the project. Eventually the maintainer retired and handed the keys to this person. It turned out it wasn't a person. It was a group of people operating under a fake email address and they put malware in. Take that one level further though, right? Just get 3 or 4 people from some, one of these labs or ransomware groups, just go make a cool open source project. Put it on Twitter, make it useful. You don't even need to take something over. Anyone can put anything on the internet. It's so easy to get GitHub stars for something cool and just spend a couple of years taking user feedback, make the project grow, show up at KubeCon. And then all of a sudden, we're in, right? Start from the beginning. You'd be incompetent if you weren't doing something like this today as a nation state.

Yeah, this is—

You continue to depress us.

Yeah, this is just lovely. I mean, it reminds me of this classic cartoon when software integrity becomes this little bit that the whole world rests on. So I feel like the XZ Utils brought up some other questions, the push from Dev Laptop, and also the fact that it was kind of a more long-game attack. So, for people who are trying to actually be secure but probably aren't equipped to audit every line by humans or robots, what are the realistic architectural safeguards for an org that knows that they can't review every line of an update? Because I'll just give an asterisk that some orgs, of course, will have humans and/or machines to review every line, and that kind of maybe can be okay. But it's obviously a high-cost, high-value, well, middle-value, high-cost measure.

Yeah. Yeah, I don't think we're ever going to be perfect, right? And we shouldn't let that be the goal or the enemy of progress along the way. If you're depending on code from strangers on the internet, stuff is going to happen. But it's defense in depth. It's all of these things, right? Be in a position where you can update quickly, be in a position where you know what is in your supply chain, and you can quickly answer this question when one of these things happens. Be in a position where the risk and blast radius of malware showing up in your supply chain is minimal, maybe not zero, but as low as it can be. If you don't have AWS keys in a GitHub secret, Then you can't lose your AWS keys in a GitHub pipeline if somebody gets malware in there, right? And you don't need to. There's OIDC and short-lived keys and ways to do all of this without credentials in these systems. So, it's just security 101. Just don't ignore it and don't ignore your CI systems. Treat them like production systems because they are at the end of the day. They are.

They very much are. And I love the security fundamentals answer. This is a very, like, somebody who used to work at Google answer to give because all of our How Google Does It episodes are, it's the basics. I also really like the agility point. I think that that gets lost for a lot of us. And one of the most depressing conversations—

There were a lot of funny stories from Log4j, kind of coming back to the other point around, should you update, should you not update? Log4j was great. It was patched by open-source maintainers quickly. It was an open-source success story, I think, not a failure story, right? The problem was organizations had no idea where they were running it, and everyone was scrambling to figure out where they were running it and update. And then there were all these memes on Twitter of like, well, I was on the older version, so I didn't even have the vulnerability.

Yes. But that's the same theme that kind of gently pushes some mindshare towards slow updates. And I don't think we need that because the other stuff is still here. It's not like the world just has supply chain attacks and zero days are gone. Like, what are you talking about?

No. Yeah. So there was this messy middle there. There were people that hadn't updated in 10 years and they were safe because the vulnerability was only 10 years old. But there were people that But there were people that hadn't updated in 5 years, and the maintainers backedported their own part. But for the people that hadn't updated in 5 years, they didn't get a backport. And then also, they had to, like, update their Java version to get the fix. And, like, updating Log4j in a weekend is easy, updating a Java version in a weekend is not easy. And so, you can't predict it. You wanna be in a position to update everything at any time.

That's a hard position for a lot of people.

Yeah.

Yeah.

It's human psychology. It's like, you know, take your vitamins every day, or, you know, go to the doctor a lot later with a serious health issue, right? People have trouble mentally amortizing that risk and dealing with a little bit of pain every day versus a huge amount every once in a while.

Yeah, we are psychologically wired to ignore tail risk. That is for sure the case. So back to the light LLM thing, we've seen that become the glue for tons of enterprise AI apps. Apparently attackers realize that the LLMs are hard to attack, but the wrappers are not. And so is the rush to AI-ify everything creating huge new swaths of attack surface? And what are we going to do about it?

I think any rush to do anything creates huge new swaths of attack surface.

This is also such a Google answer, by the way.

Yeah, I think there are differences with AI, right? I would say, like, and I think the biggest one is, I don't know, let's compare, an analogy I use a lot is like Kubernetes and containers, right? Like they blew up, like technology has rarely seen a trend like that grow as fast. It still took, like, 6 years before anybody actually cared about securing Kubernetes clusters from the first KubeCons, right? Like, everyone was showing up to those KubeCons and talking about it, but no one was doing it yet. And, you know, Kubernetes had time to get these protections in place. It was not infrastructure-grade. They didn't have RBAC in the first couple of releases, right? But it was fine because even though everyone wanted to do this stuff, and it was one of the fastest-adopted technologies in enterprise, it still had time to harden. We don't have that time to harden an AI. There are projects that appeared last month, like OpenCLAW is now running inside of every enterprise. Is it insecure? Yeah, but all new technologies are insecure the first month that they come out. The problem is that rush that's happening right now.

The problem is not AI, it's that we're moving too fast.

Yeah, because AI is so cool and you can't afford not to.

Yeah, that's fair.

Okay.

Fair take. Anton, do you want to ask the S-bomb question? I feel like this one screams Anton Chuvakin.

It was great talking to you all today. I'll see you later.

Yeah, I'm also kind of slightly depressed. I'm afraid that it would send us down yet another beautifully depressing rat hole with a lot of—

No, do it, do it. It'll be fun.

Okay, I'm gonna do it. So, SBOMs do come up as a kind of, quote unquote, foundational safeguard against software supply chain attacks, or rather maybe the enabler for them. Like, I'll go the enabler route. So, we've spent maybe like 3 years talking about this. But if the scanner that makes SBOM is the software supply chain attacked software, then what do we do? Are we screwed? Or basically explain how SBOMs play a role here, and if they do.

Yeah, short answer, they don't.

And by the way, for people who complain to us about acronyms, software bill of materials.

Yeah. Yeah. I mean, my take, like, they don't play a role here, right?

Oh, they don't.

Oh, that's easy. Yeah. They're useless in their current design form factor. Yes. Wow.

Same bar.

Okay. Bold statement. Like, and I'll walk it back a bit. There are a couple of cases where SBOMs could make sense and they could add value. They're not doing that today. They won't do that. Unfortunately, they're the wrong answer for the wrong problem. It's kind of, you know, my, my quick take. And I think this is what you were getting at a minute ago, Anton, but like the way SBOMs are being implemented and forced down people's pipelines by regulatory pressure and stuff like this, like it's just, you have to have one. It doesn't matter whether it's good, if it's accurate, any of this, everyone just wants an SBOM. Oh, it reminds me of this. Does anybody here watch South Park?

Yeah.

Yes, in my younger years, I guess. There's a— I'll go a little risky here, but there's a South Park episode forever ago and the kids were getting a sex education class and they didn't understand anything they were told, but they just started carrying condoms on them at all times because they were told if you had them, you were safe. That is what I think test bombs are at this point. I've got one, I'm safe. Without understanding what you're doing.

Tim, we're keeping this, right? Yes.

We're keeping this. It's going live.

Not live, but keeping this for sure. Yeah.

And the way they're done now is, like, they're generated by a tool, and they're as dependent on that tool as anything else. We've already had tools like that for decades, software composition analysis. If someone gave you software and you didn't know what was inside of it, you could have run your own version of that tool or 10 of those tools. Now you're stuck trusting the vendor to run one of them. You don't know if it's good or not. They miss things along the way. The only way they can have more information than those tools is if they're actually integrated into the build process itself. Like, if every compiler in the world were generating some SBOM format that could be passed along that actually had all of the correct information. But that's hard, and build systems are a pain, and nobody's doing that. They're all just kind of, you know, running an SCA tool and stapling on this piece of paper that no one looks at at the end.

And you still have to trust that that tool did it right and wasn't itself compromised. And so, there's still trust to be trusted.

Yeah. And most organizations do it. It's like, cool, you gave me one, I'm still going to run my tool. And they give me different results and neither is correct. So, what do I do with this information?

Oh.

Just an example I use all the time just to show how bad these tools are. If you take any of the open-source SBOM tools in the world, Trivy, the one that just got compromised, or Gripe, or any of these others, and you point it at the WordPress image on Docker Hub, one of the most downloaded ones ever, WordPress runs like 10% of the internet, something like that, they'll find tons of software components, but none know that WordPress is in there.

What?

Yeah, just try it. Yeah. I post this all the time and vendors tell me, I think Black Duck now does find WordPress in the WordPress image, but I don't know if any others pass this test.

Okay. So you've made me cry. You've made Anton cry. I imagine a CISO listening to this episode is probably also crying.

They can wipe their tears with the S-bombs. Yeah.

Aside from dry their eyes on their S-bomb, What should they do if they, for example, are also crying because they found the Trivy indicators in their logs? And what's the architectural change they should make? What's the response action they should take? And please don't say buy another scanner, although I know you won't say that.

Yeah, we've got a single pane of glass. Yeah, just actually spend time as a security team looking at your build infrastructure. Spend time thinking about it. Security teams know how to do this stuff, just don't ignore it. Do you have too many secrets? Are they the right ones? Can you scope down permissions? Another Google answer, like, Google basically treated developer laptops as already compromised. And, you know, we weren't allowed to have anything on them. That was kind of the fundamentals of zero trust. Treat your CI systems as fundamentally compromised because they are if you're running untrusted code inside of them. Build your protections around that model.

But that's also one more of our security tricks, which is probably hard to sell to others. Like, we have examples of security practices we use, which are amazingly effective, And also amazingly unpopular outside of Google. And if I show up as a—

Yeah, that's my qualm and a complaint from all my time at Google was it all makes sense, but only if you're 100% in that alternate universe that was built up over decades. You can't take one of these pieces and make it make sense without that whole collection.

That has a powerful magic, but you also can't sell to anybody. So, I'm sure that has some metaphysical—

Yeah, you can't pick it off one piece at a time. You either jump in with both feet or you don't.

Depressing again.

Okay.

No, no, no. Actually, that's inspirational.

Dan, I hate to do it because this has been a lot of fun. I have to ask our traditional closing questions. Do you have one tip to help people improve their build security other than audit secrets and do it the Google way of assume breach? And then 2, do you have recommended reading? And that could be anything except Anton's blog.

Yeah. One tip, pin your dependencies and set up auto-updaters. It's controversial, but I think like that, I do think that's a better practice than not doing it. A lot of people don't pin. Now you've got auto-updates and you're out of control. And if you pin and never set up updates, then you're stuck the other way too from known vulnerabilities. So, I mean, the first one is obviously audit secrets and minimize those, but you said I can't pick that. The next one is pin everything and set up auto-updates, but don't do it every day if you don't want to. Just make sure you're updating enough to know you can when you need to.

Update enough to know that you can when you need to. I really like that advice. That's subtle and great advice. And it really speaks to updating being a practice, not a thing you do.

Yeah.

It's like disaster recovery. Everyone knows that. Like, if you can't actually roll back, then you don't have any disaster recovery.

Yes. Like backups. Yeah, same thing.

Yeah.

Yeah.

And if you don't practice your disaster recovery, it doesn't exist.

Yeah.

Yeah. Great advice. And then do you have recommended reading? Could be anything from the latest fiction you enjoyed, like Project Hail Mary, to anything, really.

I'm gonna go on a limb here because a lot of the things you said make me think that you might also be a Matt Levine reader. Are you?

Occasionally, yes.

Yes.

So I'm going to recommend Matt Levine. His blog Money Stuff is amazing.

Yeah, that's a very good recommendation. I probably gave that away with the index funds comment. Dan, thank you so much for joining us today. This was timely and depressing, which is a rare combination around these parts. Thank you for joining us.

Thanks for having me on.

Now we are out of time. Thank you very much for listening and of course, for subscribing. Please subscribe so you can get new episodes piping hot And if you love our content, please drop us a review on your platform of choice.

You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcast. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.

You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, We can invite you to the next episode.

See you on the next episode of the Cloud Security Podcast by Google.

Security.