 All right. Hello, everyone. Thank you for coming. I'm giving a talk today. It's very long, so I need to read it. Maslow's security hierarchy of supply chain needs. I thought of this some time ago, and we'll kind of talk about the history of it. It's something, it's a topic near and dear to my heart. Now, I love being interrupted as I go. So if you have any questions or comments or thoughts, just yell it out. I love that. It's absolutely wonderful when people do that. So we'll kind of start with like, who am I? My name is Josh Bressers. I know many of you in the audience, which is awesome. Thank you for coming. I appreciate it. And my title is the Vice President of Security at a company called Anchor. We do the two open-source tools. Many of you may have seen our SIFT and GRIP. SIFT is an S-bomb scanner. GRIP is a vulnerability scanner. We really like the tools. We have some enterprise products as well, obviously, as many companies do. I am the host of, I'm actually working on three podcasts, but these are the two I'm going to talk about. So a hacker history podcast is one where actually Jonathan Leichu, who has that awesome hat right there, he was recently a guest on Hacker History. You should go listen. His story is fabulous. It's basically literally, I sit down with guests and I say, tell me your hacker story. And then I usually have to tell them like, stop talking. I'm out of time. But it's absolutely fantastic. I'm always looking for guests. So if anyone would like to be on the show and tell your story, like hit me up. Absolutely. I would love to have you. I also do a podcast called the open-source security podcast. This one is a little more off the cuff, we'll say. And I do it with a fellow named Kurt Seafridge, who I'll talk about later on in the presentation. I'm on the tech, the technical advisory council. All right, Chris is nodding his head. Committee, is it committee? Okay, whatever. For the open SSF and where the like technical people that help shepherd the group along. And then I'm a co-founder of a project called the global security database. I'm talking with a fellow named Josh Bucher, who's sitting right there. Raise your hand, Josh. On Thursday, Thursday morning, right? Thursday morning, I think. About, yeah. Am I walking too much? All right, take the lanyard off. I was told the lanyard was a good idea. That's fine, that's fine. I'll just put this right here. Sorry, everyone. All right, is that good? That seems to work, cool. All right, all right, we good? No? All right, he's giving me a stink eye. All right. All right, anyway, we'll get moving. If anyone can't hear me, just yell. We'll do my best. All right, my clicker quit working. There we go. All right, so this is where this talk began. Is on January 1st of this year, I was thinking about kind of organizing all of the stages of supply chain in some coherent way. And so I created a triangle, the Maslow hierarchy, as many of us know it as. And it was just a way for me to contextualize, like what is all these supply chain stuff? What are all these steps? How do we relate these things together? And the reason this came to be is I had some friends talking to me about reproducible builds. And I'm like, you don't have a CI system. Why are you talking about reproducible builds? Like this is madness. And so that's kind of where this all came from. It's one of the funny things about the holidays, right? As you go to people's houses, you have dinner with them, you talk about what they're up to, and then you're like, what is going on? I don't understand the world anymore. And so this is just, this is where it started. We're gonna go into this a little bit deeper. But basically when I began this, I was like, there is an order to supply chain. And I'm going to decide what the order is and I'm going to write it down. And it turned out there's actually not really an order. But we'll talk about that a little more. And there we go. Okay, so the first thing I wanna do is there's no answers in this talk. There's none at all. And this is one of the things that I came to realize when I started working on this is what makes sense to me doesn't make sense to you. But the real problem we end up with is no one actually knows what the problem is they're trying to solve, right? I know we all love being in the meeting or someone's like, what is the actual problem we're trying to solve here? And then you just wanna like stab them to death with a pen. But I mean that's kind of the case in this. And this is something as I kind of traveled down this path and started working on this is just understanding like what is going on here? What makes sense? And it became very apparent that what makes sense to me isn't gonna make sense to you. And even in the context of individual projects there are things that don't always make sense between different projects even within the same organization. And so we're gonna talk about that, right? So it's all about the questions. We're gonna talk a lot about questions today. And anyone who has kids, you know all about questions, right? But this got me thinking. So my kids are actually teenagers now. And so all they do is they talk to me when they need like food or money. But when you have small children they ask a lot of questions. And I realized the reason for that is they don't have any context to make decisions about many things, right? And this is I think where as technical people we have a lot of context. And so we love jumping to solutions. We don't always like asking the right questions. And so for example, I might say I need reproducible builds. Why? Like what is the purpose for that? Or you could say I need a vulnerability scanner. Like why? What is the purpose for that? And so I think the more I talk to people about supply chain and the more I investigate and read and just work on this, I realize that we have an obsession with solutions but we don't always understand what the problem is we're trying to solve. And so that's what we're gonna talk about. So we'll start out with this who is this Maslow person anyway? His name was Abraham Maslow. He was in a, I had to write this part down because I can't remember any of this. He was an American psychologist and worked at a bunch of universities. And he's famous for not the triangle but something called Maslow's hierarchy of needs. We'll get to the triangle in a minute. And his paper was written in 1943 and he named it a theory of human motivation. And for anyone who doesn't, I'm gonna assume most of you have a vague sense of this I don't wanna go too deep into it. But fundamentally what happened was this fellow realized that there basically there are certain stages along kind of the path of human development and understanding where like for example, if you don't have enough food to eat, you don't care about donating to charity, right? I think we can all understand that. And I think the supply chain is very similar. Where many of us have supply chains that like we're starving to death and yet we have people talking about donating to charity or volunteering or something. And it's like, I don't have time for any of this. And I'm sure many of us who are the developers working on things, we have management or partners or salespeople that are talking about volunteering while we're starving to death at the bottom of the triangle. And so I think that's kind of the thing I want us to all start thinking about, right? Is like, what does this look like for us? How does it work? And I have some examples we'll go into later. Now also just so anyone when the question time comes up like I read Reddit too, I know he didn't draw the triangle. This shows up on Reddit about once a month. So anyway, we'll keep going. Now, this is the most important slide on this presentation. When I drew the triangle, someone said that looks like the Star Wars crawl. And I thought by golly it does. And so I wrote a text pager that takes a page of text and it Star Wars crawls it up the screen by just taking text away from the middle. So this, I called this more wars. It was a ton of fun to write. Patches are welcome. I can't get it to build on Mac because it uses end curses and I'm really old and I don't know how any of the new stuff works. But if someone can make end curses build on Mac, like then we could have this on OSX and that would be great. All right, all right. So let's kind of get down to the whole point of all of this. And this is, there's an order to everything we do, right? This seems obvious when you write it down. And I think we all secretly know this is true, but I think we miss this a lot. Is A than B than C, right? There are, if we don't do things in order, we can't get them done. It's kind of like one of the best ways I had this described to me was a million years ago, this old guy I worked with, he, I was complaining about the VI editor in fact, right? Which is a modal text editor, meaning anyone who's ever used VI, you understand. If you haven't, don't try. But basically think of it, look, I love VI, I still use VI to this day, but I would never suggest anyone learn it now. But it's think of it like you have to open your fridge before you can take things out of it, right? And that was the modal nature of VI as it was described to me. And this is true of supply chain, is there are certain steps we need to take first before we can do others. Like one of my favorite examples is, I like to say like the S-bomb is the foundation of it all, right? If you don't have an S-bomb, there's a bunch of other things you can't really do. Well, you kind of can, but it's a lot harder. And that's kind of one of the things for us to think about is what is the order of our steps in anything we're trying to do, right? So like here's a very simple example, right? I need to scan something for vulnerabilities. What do I need? What is the order that has to happen? I need a vulnerability database, I need a vulnerability scanner, and then that's gonna spit out what I need, right? Like this makes sense. If you don't have a vulnerability database, what is your vulnerability scanner going to use? I mean, when you write this down, it's like stupidly obvious, but sometimes we need to think about these things in stupidly obvious ways because it's not always stupidly obvious, unfortunately. And gripe actually is one of the tools that Anchor writes, which is why I stole our artwork that way I could just use it. Now, here's an unsimplified example. In this one I like to pick on a lot. Before a SIG store, if you wanted to sign anything, it basically looked like this, and I know it's a silly picture, but you have to think about, you had key management. You had to store the secret for the key that was locked. You had to find a way to get the key into your CI system or whatever's going on. Like if you're getting a signed artifact from someone else, where do you get their key from? How do I trust their key? How do I know no one's tampered with their key before they gave it to me? And you end up with just like a thousand layers of madness. And I think when we look at a lot of our supply chain problems today, they look more like this than this, right? And this is what we can solve problems that look like this. We can't solve problems that look like this. Now I should also add the caveat that SIG store has simplified an enormous amount of this. If you know what SIG store is, I'm sure there's a bunch of talks about it throughout the week. Go learn it, it's amazing, I love SIG store. And it has solved tons of the hard problems around signing. And so what ends up happening though, when you have a problem that looks like this, people just don't do it. Because they say it's too hard, I give up. And I think that's what we see, especially in security all the time, is we'll tell people, oh, you need to scan your product for vulnerabilities. And they do, and they get 7,000 results, and the developers say, I'm never talking to you again, go away. Because we're doing this, you guys laugh, I've been there, it totally happens, right? So anyway, and this is where we kind of now, I want you to think about what does it mean for you? And I've got some examples we're gonna give here in a minute where I break down some of the problems I've solved. Everyone is special in this context. The way you work is not the way I work. And so I would love to tell you how to do something, but I can't. When I started writing this talk, I thought I would be able to tell you what to do. And by the time I got done, I'm like, I can't tell anyone anything. Like, what am I gonna talk about? But it's kind of what happens, right? And this is where you have to understand your threats, you have to understand your users, you have to understand what's going on. And one of the examples I use is reproducible builds. I pick on reproducible builds all the time for a variety of reasons, and partially because no one really knows what they do, and partially because it's really hard to do. And the Tor browser is one of my favorites. And cryptocurrency wallets fall into this as well. This was, I actually wrote that before the cryptocurrency like disaster started, I probably should have pulled that one. But no one likes cryptocurrency anymore. But the Tor browser is a really good example. So the Tor browser has reproducible builds. And they have those before they've had a lot of other security features. Like to my knowledge, they don't have Sbombs or publishing, I don't know if they're scanning for vulnerabilities in their product, but they've had reproducible builds for a long time. And the reason they have that is because the Tor browser has real and active adversaries that are going after their build system. This is a place where the browser itself is hosted in Git. You can look at the code, you can understand what's happening, but the build system is fundamentally a black box. And so what they needed to do is they needed a way to move the trust out of that build system into somewhere else. Because obviously for most of us with build systems today, it's like, yeah, trust us, right? And that's good enough for many of us because we don't have active adversaries going after our build system that we know of. Whereas these people do. And so the intent is they put together a reproducible build system. So they build their package and then independent third parties verify those builds. That way they can tell has our build system been compromised. It doesn't tell you anything about the security of the package they built. It doesn't tell you anything about the security of their source code. But this is one of those things, like I think a lot of times in security, we think, oh, it's a reproducible build, it must be secure. And that's obviously not the case. But that's another story I'm not going to talk about today. OK, so now we get back to the question of what is the problem you're trying to solve, right? And the big ones that always come up, and especially at this show, is going to be attestation, reproducibility, and ha, ha, ha, there are solutions not problems. And so this, again, is this is hard to do. And I'm going to keep saying this over and over again. And this is where I'm going to pick on Kurt Seaford, who is the guy I do the open-source security podcast with. Kurt works at the Cloud Security Alliance, and he manages their infrastructure. He's their director of IT, I figured his title is. But anyway, Kurt comes to me about once a month and says, I'm working with this company, and they don't have DNSSEC, and they don't have DKIM and SPIF and whatever all the other email security things are. And I always say, who cares? And then he gets mad at me. And it's fine, it's fine. But the point is, right? So DNSSEC is a great example. What is the problem DNSSEC is actually trying to solve? Because people always tell you, oh, you need DNSSEC, like why? What am I solving with DNSSEC? And fundamentally, it was about trust, right? Can I trust this DNS server? And the answer is, we don't know on historical DNS. But with things like Let's Encrypt, I think we've moved the problem from DNS to other places. And so this is one of those instances where I don't think DNSSEC necessarily solves the problem. It is a solution, but is it a solution to the problem we're trying to solve? And so this is the thing to think about. What are you actually trying to solve, right? Reproducibility is not a problem. Reproducibility is a solution. What is your problem? Upgradeability, maintainability, not problems, they are solutions. And so everyone is different, and everyone has to think about what they want to do, right? This is really, really hard. My other favorite example I'll use here is the OCSP stapling, right? So some of you probably know this, not everyone does. There's this thing in web browsers called OCSP, which stands for I have to write this one again, online certificate status protocol, right? The idea is you have all the certificates used across the world. And some of them have been compromised, or there's something wrong with them. The key might have been lost. An attacker might have gotten a whole certificate. Who knows? There's a million things that can happen. The idea is a registry was created that was intended to be the place you could put the revoked certificate information in. And so the idea is you're using your web browser. Your browser is going to ask the OCSP server, say, oh, is the certificate OK? And it's going to say yes or no. And then you keep going, right? And the idea was, well, we're going to protect users from bad certificates. Except the problem isn't quite that. Because what happened was there's actually three states when you're doing this in your browser. The certificate is known bad, right? In that case, you'd expect the browser to like flake out and not allow you there. The certificate is not in the database, which means it's probably OK. It might not have been updated yet. It could be attacked, whatever. There's a million things. Or the server doesn't respond, which happens all the time. And so now we have the question of, what do we do when the server doesn't respond? Well, if you make your web browser fail when the server doesn't respond, you can't use the web. I remember turning this on at one point and it was devastating. Your browser doesn't work because the server fails all the time. And so now you have the question. As a browser manufacturer, if I can't contact the OCSP server, what do I do? If you fail closed, the browsing experience is terrible. If you fail open, what's the point of the service? And that's kind of where we're at. So they were trying to solve a problem of bad certificates, and they solved no problem at all, is what ended up happening. And so this is another one of those examples. In security, this stuff is really, really hard to get right. I don't know what the answer is. I'm just picking on them because I can't. But it's again, what is the problem? And how do we start solving the problem? And we are so good at creating solutions. So I have some examples we'll save from my extensive experience in the industry. That's just a nice way of saying I'm really old because I am. I've seen many, many things. And we'll start with log for Jake because I, well, no, we won't. Sorry, we'll get to that one. So I have customers come to me on a regular basis and ask me all kinds of things. Yeah, I love this one. This is the best picture. So a customer will come to me and say, do you have an S-bomb for your product? That is a problem because they're asking me for an S-bomb. If I don't give them an S-bomb, they're not going to pay us for the product. This is easy to understand. Now, what do I need to get an S-bomb? And this is where I put the little triangle on the picture and I just kind of thought about. What does an S-bomb mean? I basically just need an S-bomb scanner and then I get an S-bomb. And then I give the S-bomb to customers. You know what I mean? Like, this is what Anchor does. This one's actually easy to solve for us, so it's fine. But you get the idea. Like, when we do this, if we don't have an S-bomb scanner, you can create an S-bomb without an S-bomb scanner, but it is a terrible experience. I would not suggest anyone does it by hand. It would be horrible. I'm sure Allen has horror stories of people creating them by hand thousands of years ago. But that's OK. That's where you start, right? My other one I like is so at Anchor, we work with a group called Platform One. This is actually their logo. The logo is like Chef's Kiss. I love it so much. But Platform One, it's a group that's part of the Department of Defense. I do the Air Forces behind it. And basically, the intent here is they take container images and they've created a trusted registry. So the intent is if you ever worked with the government, there is this huge list of controls you have to go through before you can deploy any software in the controlled federal environments. And it's a ton of work, and it's painful, and it takes a really, really long time. And so Platform One's goal was to say, we have this repository of containers, and we want to make it so you can just pull the containers and use them. You don't need to go through some horrible approval process. And part of this is they're running a bunch of scanners against the container images. They're looking for vulnerabilities. They're looking for misconfigurations. They're looking for all kinds of stuff. And they do a really good job. It's actually a really, really cool project. A lot of it's public. They go take a look if you're interested in it. But from my perspective, the Anchor Enterprise product is in Platform One. It's actually one of the scanners they use. But obviously, even though we're a scanner in the product, we also have to put the scanner in the product. It's this very chicken and egg thing. It's very cool. But anyway, we put our product in, and then they say, here's a list of vulnerabilities in your product. What are you going to do about this? And this is another example of what do I need to reply to this in an efficient and reasonable manner. And obviously, I need an SBOM, which also I need an SBOM scanner. But that's another story. I have my SBOM. Then I have to scan the SBOM for vulnerabilities, because the idea being the contents of the SBOM don't change. But new vulnerabilities are found constantly. So I want the ability to keep looking at the SBOM over and over and over again. So I need a vulnerability scanner. It's going to scan the SBOM. And then I need vulnerability management. And the idea here is when I'm given a scan, there's going to be false positives. There's going to be findings that I know I'm fixing in the next version. There's going to be findings that I'm going to say, I will never fix this for whatever reason. And this is where having the ability to denote all of these things when in a vulnerability management system means that I don't have to do it twice. That's the goal. The intent is I want Platform 1 to scan our product. I want to see our scan. And I want to send it back to them in minutes. I don't want it to take days or weeks or months. Anyone who's ever gotten, I'll never forget when I worked at Elastic before Anchor. And this is when I started getting vulnerability scans from customers. And I was like, what is going on? What is even happening? It never happened before, really, where you'd get emails about individual vulnerabilities. But suddenly I started getting these mails with 2,000 vulnerabilities. And I'm like, what are you even doing? Where did this come from? And it was like an alarming and horrible process. And I mean, when I started, I had to build my own vulnerability management system because it didn't exist. And the S-bomb was also built by hand. It was horrible. Well, it wasn't really an S-bomb, it was a text file. But technically, right? Whatever. We all started with text files, right? But you kind of get the idea. I mean, this is one of those things that as you can build your way up, you can solve your problems faster. And it went from taking literally days to go through one of these vulnerability reports to taking minutes. And I remember it was always funny, because I'd work with sales or support. And they'd say, oh, I got another vulnerability scan. This one has 10,000 findings. And I'm on it. And two minutes later, I'd give them a reply. Because 90% of it was false positives, in most cases, where the scanner was finding things that weren't there. But it was always funny. It's like, wow, that was really fast. How'd you do that? I'm like, I'm really good. But this is my favorite, log for shell. This will be burned into our minds. We're going to be talking about log for shell at conferences for the next decade, at least, I think. But it's good, because I don't have to talk about Heartbleed anymore. But this comes up all the time, where I still, not so much anymore, mostly at Christmas time, I'd have people say, have you ever shipped log for J ever in your product, like any version ever? And this one is a really cool question, actually, because how many of us have historic versions of all the stuff we've run or shipped in the past? Like I'm sure some of us do, of course. There's the overachievers in every group. But I mean, I remember this was a problem we had in the early days of Linux distributions. I spent time working at a company that worked with Debian, and I spent time at Red Hat. And keeping archives of this stuff was important, because we want partially, because you wanted people to be able to install it forever, and partially because we needed to know what it was. We had to have a way to go look back in time. And so this is one of those questions of, if you need to look back in time for every package you have ever worked within history, can you do it? And the answer is most of us can't. Or we could today, but it would take a lot of effort. So this is the case, like in the history of the Linux distributions, it was just heavy lifting. In fact, I was part of this at one point in the past, where a human just went in with scripts and untarred all of the RPMs and then looked inside of them and it took like a month to run, because there were a lot. And you get the idea. So this is a problem. What do we do? What is our triangle look like? How do we build ourselves up from the bottom? And this one, obviously, coffee was the most important thing during Lock for Shell. But fundamentally, if you need SBOMs, you need your SBOM scanner, and there's all kinds of other steps. But fundamentally, there's this new concept called SBOM management. What if I had a system that actually, it was anyone in the talk right before this, where it was the New York Presbyterian folks talking about their daggerboard. Daggerboard, thank you. Which is part of a boat, I found out. I thought it was like a board full of daggers. That was a very cool talk. Go watch it on YouTube if you missed it after this. But it was one of those things like, how do you track this stuff? What can we do with it over time? And this is a tough one. Lock for Shell ate a lot of our Christmases, and it sucked. But I'd like to say, if we had SBOM management, it wouldn't have ruined any of our weeks. But I'm sure that's not true. All right. This is my favorite. This is my last big example. So at a station, how many of us have ever been asked by someone, are you absolutely sure you're actually running this package for real? And it's not some backdoor thing. It's not something someone found under the rug. And it's the real deal. And so this one is like my good example here, right? Now, how do we figure this all out? And so this one I've thought about a lot. This isn't completely accurate, I don't think, but I'm going to start. So we need to, obviously we're going to have an SBOM because I put SBOM at the bottom of everything. Because I think if you have an SBOM, you solve a lot of problems. We need a CI system that has the ability to check. Now, mind you also, this is best case, right? I'm not talking necessarily about where anyone's never start building the whole triangle. We have to start at the bottom and we have to work our way up, right? That's part of the point of this. So when you're at SBOM, you're going to need a CI system. The CI system has to have the ability to verify the packages you're pulling in. How do we verify packages? Well, obviously we want them signed, right? So now we need to do key management. Well, if we have a key, we're checking. And we have a key we're using to sign our stuff. Now we also need secret management because if you have a key, you have to unlock the key, right? Oh, but now we need a key server also. And then we're going to need a place to store the packages. We're downloading off the internet and it's to store the packages we're building. And then we're going to need the ability to distribute our key to the people on the other end of what we're doing. And then they have to have the ability to verify the signatures. And you can see, this really gets out of hand quickly when you do this. And no one can build all of this today. Even with SIGSR. SIGSR solves a lot of these problems. But you can't do it. Now, here's what happens. I've actually been asked this before. I don't have all these steps in place, right? We do a bunch of stuff in Anchor. Like when I was at Red Hat, we did a bunch of stuff. When I was at Elastic, we did a bunch of stuff. But we didn't do everything. And so one of the things I think we need to keep in mind is just because we don't have all the pieces doesn't mean we can't do the work. And this is an instance where if I have an Sbomb and I have logs from my CICD system, I can basically answer this question. But it's going to take a lot of manual effort. And so the thing I realize, this is the culmination of all of my thinking about this problem and going through talking to people, working through all of my examples, is saying that we obsess over the top of this triangle. As security people, it's where we live. It's what we want to be. Sometimes it feels like we want to be the cool robot that's come together from the lions instead of saying, like, I need fundamentals first. And then we'll build the lions later. That's how it works. And so I've done this, but I've done it by hand. And I would like to build it all the way up. But I recognize I can't start at the top. It's not practical. I have Sbombs now. I have a CI system. Now we can start doing things like actually Sigstore deletes a whole bunch of the crap on this pyramid, which is great. Sigstore didn't exist at one point when we had to solve these problems. So anyway, there's a saying from, I forget who said it now. I couldn't find the quote, but it was from a DevOps person, is that you can't buy DevOps, but I'd sure like to sell it to you. And I think the supply chain is the same thing, right? We have a conference we're at that has a bunch of people upstairs that have tons of products and services that are designed to help us with our supply chain. We have a bunch of talks that are going to be all about solving some problem in the supply chain. And I think this is the thing I keep thinking about is like, this is a process. It's a journey. There's no answer. This talk is a journey. When I started, I was certain I could lay down like the steps we needed for supply chain security. And the more I did it, like the more I realized, that's not how it works. Anyone who's looked at salsa before, this is how salsa is broken apart, right? There's salsa levels, one, two, three, and four. And it's because you don't start at salsa four. No one starts at salsa four. It amuses me, actually, kind of a side note. Suze just got what certified for salsa four. And I read that, and I thought, oh, well, that makes sense. And it's because the Linux distributions, they started at salsa zero two decades ago. And then they spent 20 years building themselves into salsa four, right? It literally took 20 years. And so this is something we all have to keep in mind. You're not going to start at salsa four. You start at salsa zero, which doesn't exist. And then you work your way up from there. And I think that is the most humbling part of all of this, was just putting together all of these thoughts and understanding, like there's no answer to this. And it feels like kind of a cop-out, right? I'm giving a conference talk. I'm supposed to stand up here and tell you all what to do. Like that's the whole point, right? But there's no answer. There's no easy answer for supply chain security. Everyone's different. Everyone has to figure it out themselves. And that's just, I guess, the sad cop-out that comes at the end of this talk is I can't solve this for you. However, here's a quick slide. This will be online somewhere. These are the things I talked about. But this is really what I'm here for. If anyone here, I'll put that back up for anyone. This is where it comes to all of you. I think I want to have, this has to be a conversation, right? This isn't about someone standing up in front and spouting nonsense for half an hour. This is about all of us working together and figuring out what's next. I don't know. This is where getting involved in the open SSF is valuable. Telling your story. What are your challenges? How do we fix some of this? I don't have any answers, right? I barely have questions. And so let's chat. Questions, comments? I'd love to hear from you all. It's like stun signs. Well, I mean, we legitimately have question time, though. Which triangle? The one? Oh, I don't know, actually. That's a good question. I'm not sure where that came from. I should have known that. That would have been a valuable piece of information, I think. OK, so the question was, why would we think of the problem, I guess, as the hierarchy versus just like a threat model? You're saying, I think it's related. I think that's part of the foundation, right? Is understanding what is my system? What is going on in here? How do I look at things? And then starting to figure out, so like if this is a threat I have, how do I solve that particular threat? And I think threat modeling is actually a lovely way of clearly defining problems, because then we can look at that and say, like, this is an actual weak point. How do we make this weak point better? And I think that, I mean, from like an appsec perspective, I would say like threat modeling is the foundation of appsec, right? I think from a supply chain perspective, we don't talk about, we talk about S-bombs a lot, but I think threat modeling is probably a part of that conversation we should consider, for sure, which I haven't done before, but I will start now. So thank you. Any other questions? All right, well thank you everyone. I truly appreciate it. Thank you.