 All right, thank you all very much for attending today. My name is Daniel Nermy. I'm the CTO co-founder of a company called Anchor. We've been working in the security space for a bit. Largely we work with customers to add security tooling into their development processes. And today I was going to focus in a little bit on this intersection between discussion that's been going on, you know, with more focus over the last half year so even really between supply chain security and the concept of S-bombs. We see these things talked about a lot and I was going to explore a little bit the relationships between these things. And so first of all, you know, we did an interesting survey where we went out to a number of larger enterprises, not anybody but very large enterprises and actually asked quite a few questions, some of them focused specifically on supply chain security. And I thought I'd share a couple of these results, pretty interesting stuff in our opinion. And one of them was asking about the past, you know, over the last 12 months, how many large enterprise respondents were affected by something you identify specifically as a software supply chain attack. And, you know, overwhelmingly, a lot of respondents came back with yep, yes indeed, some form of yes, whether it's a minor impact based on the fact that something happened and we had to spend a lot of time on it or a major impact that was significantly impacted, probably actually hacked, you know, that kind of thing. And the second question we asked was actually more about the future. You know, now, given where we are, are you focused, do you have a specific focus on improving your supply chain security stance? And again, you know, we were a little bit surprised to find over 50%, you know, closer to 60% of our respondents came back and said this is a significant area of focus for us in the next 12 months. Just a little bit of context, kind of, you know, putting some facts and a little bit of evidence towards a lot of the discussion that's been going on about improving supply chain security. Now, I think a lot of folks in this room probably have something in mind when it comes to what a supply chain is. And I think, you know, Operation Salsa can get it out for us a little bit. But, you know, another way to just sort of ground this discussion, we kind of think of a supply chain more like a graph, right? When it comes to software, there's open source projects, there's vendor projects, all of this stuff is related, there's cycles in this graph. But at the end of the day, it's in kind of a, you look at it this way, from a malicious actor's perspective, you can see some obvious ways to influence what ultimately ends up running in production. You can find anywhere in this complex graph to come in and make a problem happen. But if we kind of look closely at one of those boxes, everybody that's trying to infiltrate a supply chain is looking for the weakest link in the chain or the graph. And if we kind of look closely at this stuff, this is a depiction of kind of a standard, left-hand side, we've got a bunch of external software coming in from earlier in the supply chain. On the right-hand side, we're publishing or running some software, that's kind of the other side of the chain. In between, you know, nowadays we've got a fairly modern setup, a lot of automation containers are in here, a lot of software builds. A lot of things are happening automatically and very quickly. There's a lot of dynamic stuff happening. And at any point in this process of left to right for any given software project, there are opportunities to come in and either get some credentials leaked or insert some malicious code. So a lot of opportunity in here, which is why this is a significant problem, something worth all of us thinking, thinking about how to improve. Now I'm gonna jump over to the S-bomb. So we look at that previous picture and there's a lot of places where we can have problems. How do S-bombs actually help? Like what is this? You know, what do we do with an S-bomb and how does it apply to this problem? Well, there's a couple of ways of thinking about it. One way is probably a little bit more obvious based on existing tooling and the kind of technology that's been out there, which is to say if we do a software bill of materials, if we generate an S-bomb for all of the artifacts in this software development process, you know, we can think of it as a manifest, right? It's a list of software, right? It's our dependencies, it's our application software, it's names and versions of things. And just by itself, that's really useful. A lot of times folks that aren't necessarily in this space don't realize that one way or another, that piece of information is an important input to tooling that does vulnerability scans, it does license checks, it does things like provenance checks to figure out what dependencies do you have so that I can do something in a security or compliance function on top of that. So S-bombs already have been used for a very long time as one of the inputs to some of the standard security tool we tend to build into these development processes. But now, moving forward, I think there's some additional opportunities to kind of extend the definition of an S-bomb from being, you know, something that's a list of dependencies to add a lot more context. You know, when we go in and start looking at source code or container images or binaries, we can generate lists of dependencies, but we also have access to a lot of other information. We have access to the files, we have access to their checksums, we can look at configuration files inside of containers that define how things might operate in their execute. We can look at all sorts of information, and one perspective here is to say, we can add that additional information to an S-bomb, and if we start to do that, we start to unlock some additional security functions is our prediction. For example, if we go in and generate this richer S-bomb document against a bunch of these artifacts being generated, we can codify that one of them as an intention. This is something that we can review, we can run our vulnerability scans on, we're okay with this S-bomb. We have that codified now in our development automated process. We can start to observe everything else that's happening and generate a comparable S-bomb start to compare them, and that gives us a notion of, say, drift, right? We can look at, this is what it's supposed to be, we can generate a new S-bomb for what actually is and start to compare them. This is an interesting function that we can start to look at as well between all of the artifacts generated by these stages. So now if we start to do this, we have our vulnerability scanning and our license checks, and then we start to add some more advanced comparison functions all based on software bill of materials coming into a system, then ultimately we can start to improve as any one element of a software supply chain, global software supply chain, our stance. And we think, one thing that's likely to happen if we all start to kind of orient around this kind of tooling, especially off of the back of some new regulations, like from the US executive order, for example, specifying S-bombs and other types of security tooling proof being required for various regulated industries and projects to use software. We predict the world's gonna start to look something like this, where not only do we use the software bill of materials and other tooling within our development process, but we can start to generate them and share them across organizational boundaries. And that's easier said than done, but if we can figure that out, then the global supply chain starts to improve substantially because we don't have to inspect things necessarily anymore. We can take what's given, prove that that's valid, and then move on from there. Use those to trust but verify what we... Thank you very much. If you'd like to learn more, we've got a booth here, encore at KubeCon, and we've got a couple of events. But I just thought I'd say, thank you again for attending. It's great to see everybody in person. Thank you.