 Yeah. Thank you, Brandon. Yeah, so I know we haven't talked about supply chain enough already, so I figured we could spend some time on that today. But before we do, a fun fact I just learned from the bird app is that Hitchhiker's Guide to the Galaxy was released for 12th 1979 exactly 42 years ago. That's your fun fact. You learned nothing else from this talk. You can tell your friends that one. That is the 42nd anniversary of that. So yeah, I'm really honored to be here and speak with you. I'll introduce myself in more detail in a little bit. But I want to talk first about a story because I think a lot of what we've heard about securing the supply chain and great tools around doing it maybe doesn't have all of the historical context that we can give it. And so it's important to think back in our history. When I say in our history, I don't mean like the early days of Kubernetes. I don't mean before Kubernetes existed. I don't mean really any history you or I were around for. Before Hitchhiker's Guide for the Galaxy, long before. Over the entire history of like where we've organized ourselves into society and then had adversarial relationships with other human beings. There's always been supply chain attacks. Always been a feature of adversarial relationships. There were wars over many years that were won and lost on the ability to control your supply chain or that of your adversary. In fact, entire civilizations have either thrived or perished because of their supply chain or logistics. In fact, in the art of war, Sun Tzu writes that the line between disorder and order lies in logistics. So this is something that's been around a really long time. And the reason we're talking about it so much right now in our industry and in software is because we've got this concept that software has eaten the world. And because of that, now this kind of long ago supply chain style attack that we've seen is now something we see in software. And so it's not that new. It goes back to times long before. So in that sense, the SolarWinds attack that was often times cited as one of the key attacks that we saw to make us all think more about supply chain isn't really that new, but it also doesn't mean that there's nothing to learn from it. So I think it's been mentioned a few times today in this conference, but SolarWinds themselves actually spoke at the supply chain security conference yesterday. They had fantastic technical details in that talk about all of the technical things that went wrong, went right, all of the efforts their team put in after the event. I want to talk about some of those today, but I also want to talk about the human factors and then some other factors that we don't often bring into the discussion around supply chain because it's not just about this single event. It's kind of easy to point the finger and say, here's the thing that shows us supply chain's important. But it's not new. Again, it's not new and we're going to talk about why. In fact, one of the victims of this attack was actually the first people to report it, FireEye. They previously had written a report to NIST, National Institute of Standards and Technology, called the Supply Chain Risk Management Report. They had talked about how organizations putting greater and greater security and ensuring their security position to the rest of the world is a good thing, but it means that adversaries will necessarily go up the chain or down the chain in the supply chain to then attack their real targets. SolarWinds wasn't even the target of this attack. That we all call your SolarWinds or Sunburst Attack. That's important. It's worth knowing just a little bit more about what happened so that we can talk about that. If you weren't familiar with the details of the attack, again yesterday, you can get the real deal from the first-hand source if you watched the videos from yesterday. But just to give you a little flavor, it wasn't this kind of full-scale assault that you might think of when you think of an attack. It wasn't against the intended target. SolarWinds was not who was targeted in this attack. They targeted SolarWinds so that they could get at their real targets. The customers that SolarWinds had who relied heavily on the software that SolarWinds was producing, they installed that software pervasively throughout their networks, gave it expansive permissions, and then accepted updates directly from SolarWinds. That's what made them vulnerable to an attack on SolarWinds as part of their supply chain. Again, just to give a little bit more of a detailed overview from what we know, this attack wasn't even one point in time. The attackers were very sophisticated and originally gained access to the CICD build infrastructure rather, SolarWinds build infrastructure. That gave them the ability to inject their own code into the pipeline where SolarWinds was building the Orion product. At first, they just tested this. They didn't really deliver the real payload. There's this thing called SunSpot where they were just testing to see would they be detected. They inserted these DLLs, named them things that looked like and sound like classes that SolarWinds was already using in the package. They wanted to know, are we going to be noticed? When they realized that they were able to get away with it, then they released Sunburst, which was the real Trojanized code that got injected into the Orion software. Even that wasn't the end goal. Then they moved all the malware that they had from the VMs where the builds were happening. The code was signed to try and cover their tracks. Then it wasn't until later that they then activated the code to actually get at the targets that they were looking for. It was aptly pointed out by SolarWinds CEO in a blog about it that they're not the only ones that have this kind of infrastructure. These build machines that are signing code, they're definitely not the only ones vulnerable to this type of thing. That's the point of this talk. We have this web of dependencies and we're going to talk about that in more detail. As we build our modern infrastructure on top of more and more dependencies, you end up building on something that eventually you don't know. You have this little piece holding up everything else. We're going to talk about that today. Again, as promised, I introduced myself. I'm Brendan O'Leary. I'm a developer evangelist at GitLab. I had the inverse problem that Dan Popp was talking about. No, sorry, that Dan Naranz was talking about. His hair grew out from worrying about supply chain. I used to have hair before. I thought about supply chain security and now I don't. I think that as of May. We talk about these dependencies. We saw that funny XKCD that talks about dependencies. Again, we've talked a lot about that today. These tools to search for dependencies and talked about the software build materials and all these things. I want to really define what that is because I think it's really important to this concept of supply chain security. Of course, a dependency is traditionally what we think of as an open source dependency that we bring into our project. A library to do something better, to interact with a known API, to interact with a piece of hardware maybe we're using. This is some data from the Activerse report that shows the percentage of projects in different languages that use open source dependencies. This is not news. We talked about this this morning. One thing that that doesn't cover is transitive dependencies. The graph we just saw was dependencies. Things we specifically call out in a package manager file or elsewhere to say, hey, we've made a decision to include this library into our product. Now, the problem is or a concern there is that those dependencies come with dependencies of their own. You end up with this web of dependencies that come along with it. This graph shows us that as an amateur-ish no developer I can attest to that JavaScript line right there. If you just look at node modules on this computer in any file, you'll see that that bears out. But these are the transitive dependencies that we bring in as we're adding these other dependencies. But it's not even just that. That makes sense. We've got open source libraries. We've got the code rewrite. That's part of what is included in our final product. Again, that's not new. We said, okay, it's not those libraries. It's also other third party libraries that we bring in. Maybe those are ones that come along with these open source dependencies. Maybe they're closed source ones. Things used to access the operating system or from some vendor, again, hardware vendor or some API we're using that's closed. But that library then really is a dependency as well. And then, of course, both of those have their own open source and maybe closed source dependencies. This is where when left pad gets taken out of the MPAM registry, all of a sudden nobody can build. Not that many people were pulling left pad to pad some numbers into their code, but they had depended on something that was doing, you know, how they were doing their AJAX calls and that thing was depending on left pad, right? And then there's more, right? So then you have, what about our DevOps process, right? We heard this this morning. What about all the things that we're doing to get code into production? That is a dependency. We've solved that in the SolarWindows attack, right? That is a clear dependency to our production environment. And then there's our production environment. And then, of course, in there are a bunch of other vendors with a big S and they have a lot of open source dependencies that they rely on and they probably have a lot of closed source proprietary stuff they rely on, right? So this web gets a lot bigger than just, oh, these are the dependencies caught out in my files. And so I think it's key to understand that the sum total of all those dependencies really is what you should think of when you're talking about a supply chain. And so, okay, so let's talk about then what is a supply chain? Yep. So we got that. Oh, I thought we had 20 minutes. No, just 10. Oh, great. Sorry, that must have been a change. Sorry about that. Okay, well, the rest of the talk is online. If you'd like to take a look at that, I'll tweet it out soon on Olyricrew and I'll let you hear it. Thanks, Brandon. Yeah, thank you. Thank you.