 Hopefully you're all here for our talk about navigating the software supply chain defense landscape. Thank you all for coming, and we'll just get into it. First of all, a little bit about us. I'm Marina Moore. I'm a PhD candidate at NYU, as well as a maintainer of a number of open source security projects, including TuF, Intodo, and Uptane. And I'm also a co-chair of TAG Security. Hi, and I'm Adithya. I'm also a PhD candidate at NYU. I do a bunch of open source and software supply chain security. I'm one of the maintainers of Intodo and a few other things, like the parts of Intodo specification. I'm the maintainer of GitHub over at the OpenSSF Sandbox, and I've contributed to a bunch of CNCF and other OpenSSF FFs as well. So given that you're all in the room, you probably really care about your software supply chain and actually securing it. And I'm guessing a part of that reason is because of the massive increase in software supply chain attacks we've seen in the last few years, with a ridiculous number of high-profile number incidents as well. And the other reason why you probably care about it is all of those attacks has led to the form of creation of new regulations in the United States, in the EU, that require you to care about securing your software supply chain as well. So as someone who's sort of new to this space, you're obviously going to be like, OK, where do I start? How do I start securing my software supply chain? Do I create this thing called an S-bomb, a software bill of materials that I keep hearing about? And does my S-bomb solve all my problems? And should I be signing my S-bomb or my software releases? And who should sign it? And who actually verifies these signatures if we actually sign it? All of these questions that just keep coming up, and at the end of it, you're like, is there a tool that I can just deploy, and it does all of these things for me, all of my software supply chain security problems are solved? And let me just look this up and see what shows up. And then you certainly hit with a ridiculous number of tools again that all have the software supply chain keyword somewhere in there, because they're all just solving different parts of it. And this can also be really overwhelming, right? And again, most of these are just open source tools and projects. A couple of them are maybe platforms, but none of them really are companies that also come along and are trying to solve your software supply chain security problems. So this list of logos, it's not a list, but this set of logos would be even bigger if we try to actually include everyone that's trying to do software supply chain security. And so to take a step back and to make sense of all of that, we're gonna start with some of the building blocks and separating some of these tools from the concepts. And the first concept that you probably heard of a bit yesterday in a few talks and just generally looking at the space is the notion of an attestation, right? You've heard this word a lot, and it's actually quite simple. Like conceptually, an attestation is some piece of metadata that contains some claims about your software artifacts or some things that are happening in your software supply chain that produces these artifacts or transforms them in some ways. And there isn't just one attestation out there, you're gonna have different types of attestations and usually it's explicitly listed in the attestation itself. And for a lot more information of how this works, you should take a look at the in total attestation framework. The other building block is signatures. Signatures are really important in our software supply chain because they answer this question of the who, right? Who's making that claim that's recorded in an attestation when you have a signed attestation? Or who is making some claim about the software artifact that you're signing? And of course there's a lot of pain that comes along with trying to do signatures with key management and then that's why there have been remarkable strides in that space with things like SixTor introducing keyless signing in the last few years with OpenPopkey, another newer project that's trying to do similar things with using OIDC authentication for signing. And when you put these two things together you get signed attestations that contain claims about different parts of your software supply chain. And again, as attestations can be of multiple types, what you see when you start assessing all of these different tools for securing different parts of your supply chain is this repeating pattern of oh, we have this piece of information and we can express this as an internal attestation sign it with SixTor and so on. So, so far, right? Like you have this way of capturing these claims and you have this way of signing off on these claims. There's still this question of what should I be recording from my supply chain? What claims should I be making? Like we just talked about S-MOMs a couple slides ago. Is, am I looking to put an S-MOM in my attestation and just signing it? Is that enough? The S-MOMs are really great for some things, right? They're really great for mitigating the next lock for shell, for example, for identifying where you have a vulnerable dependency in your software and what you've got a patch. But they're not so great for defending against the next sunburst, right? The SolarWinds hack from a few years ago. So, and to answer that, so the next question is like, okay, is there a guide, right? To understand what I need to record in different parts of my supply chain and so on. What I need to be doing a different, you know, to really guarantee the integrity of my processes and my software. And if you look within the CNCF, there's the DAX Security Supply Chain Best Practices white paper from a few years ago. OpenSSF has this thing called SALSA. There's the NIST SSTF. The DAX Security Supply Chain Best Practices white paper, that's a mouthful. But it contains a lot of really detailed best practices for each of the different phases of your software supply chain. It contains some tooling options and what you need to be, like it's a bit more abstract also in that it tells you the design considerations you're gonna have in mind. And I also wanna highlight that the V1 came out in like 2021 and there's a V2 effort underway because so much has changed in the last three years or so. So, you know, also just a small shout out for you to jump on that effort as well. SALSA is, again, I think I mentioned some of the OpenSSF, it describes a number of levels for different parts of your software, right? The current focus is on the build track, which has three levels and it tells you what requirements you need to care about. It defines requirements that you need to care about at each of those levels. And as you move up the different levels, you get higher security guarantees. And it also defines something called the provenance of your build process, of the built artifact that is a set of metadata that must be collected as your software is being built and recorded as an internal attestation. And going back to like, you know, what I was just talking about with like taking attestations and signatures and putting them together, everything from level two of SALSA V1's build track and above requires that provenance to also be signed. There is ongoing work to move some of this over to like the source track to secure your source repositories for the dependency track for how you consume external software and so on as well. And I wanted to give a shout out to that. But so just to zoom out, right? Regardless of, so that images from SALSA's website, regardless of where you are in your software supply chain, those, some things remain the same, like just to connect the dots. You care about who's building your software and who's modifying your source code. It's the, you know, what, the, where all of this is happening. It basically the five W's in the one head, H. And that's why those concepts, the ability to capture claims and sign them and so on are so important. And that's why you see that repeating pattern all over the place. And this is also where like the policies that you care about start maturing, like you wanna be able to enforce that the correct answers to those five W's and one H questions, right? The what, where, why, when, who and how are all the right things. They all, you know, line up to with what you expect and also where you start focusing on things like the visibility into what's in your supply chain with all of that metadata you've just captured and you use that to funnel back into like writing the right policies and so on. So, separate, like, you know, separating the tools versus the concepts, different parts of the supply chain obviously do have very specific contextual requirements. And so you do have all of those specific tools that you need to be, probably need to be using and you likely need some combination of all of them. So it's like, oh, I saw this thing that keeps popping up all of these different places and does that mean that this solves all of my problems? No, but what really ends up happening is it's like the connecting layer between all of those different tools and that, yeah, hence the repetition, I guess. So to make sense of all of the tools, you had to reason through what security properties you care about and things like Salsa can get you along where they're, the best practices, White Paper can get you along where they're. And the other part of this is what technologies you're already using today because it's not trivial to say, oh, okay, so now we've gotta really start caring about securing our built pipelines. You can't really start from scratch with like, I'm gonna throw away my CICD system that I have today and start over from scratch with the state of the art security. So the other part of this is like, okay, so this is the stack that I'm currently using. This is the set of software that I'm already using. How do I inject these properties into here, into what the stack we already have and move towards a more secure software supply chain? And with that, I'm gonna hand it back to Marina. Thank you. Yeah, so once you have all these questions that you now need answered, we'll start to try and answer them. So Tag Security has recently introduced this supply chain security tools mapping effort. And the goal is to map requirements from the Tag Security supply chain best practices, White Paper. You know, one of those sets of requirements was chosen just because it's within Tag Security as a place to start. And for each of these requirements, find the tools and platforms that address each requirement so you can figure out how to map a set of these tools together to actually achieve all of the different requirements. So we'll go a little bit into how that works. So say you wanna try and secure your build pipeline. We're just gonna zoom in on this one piece of the software supply chain. And you already used Tecton for your CI today. That's just, that's where you are today. You can use the Tecton chains existing tool to generate Providence attestations. So there's those attestations we talked about before that test to the different steps of the build process. Let's say you would actually use GitHub Actions to build your software. Don't worry, there's already this support for attestations there as well. There's early access support directly in GitHub Actions for supporting these Providence attestations. What about Jenkins? We also, there's also support there. There's the Jenkins and Toto plugin which also creates attestations for your build pipeline. Okay, so we have some kind of build pipeline with some kind of attestations. What's next? Well, you need to sign these attestations, right? That's what we talked about. So you know who is creating the attestations. So to solve this who question, you can sign these attestations with six star. And then you can add more layers to this. You can get runtime trace attestations with Tetragon. So you actually can see what's happening during the build process itself as well as just the results of that process. You can use BuildKit to generate an Sbomb. If your users are asking for Sbombs out of this process, if you want to be able to get insights into everything that's coming into your build process, all your dependencies, what these are, where they're coming from, you can use BuildKit to generate an Sbomb which gives you all that information. You can use a tough route of trust so that you know where the keys for each of these other steps are coming from. For example, the six star project uses a tough route of trust so that you know where the six star I guess the six star full CEO and record keys come from which is their internal transparency logs. So it's all kind of based on this foundational route of trust. That's a lot of tools for this one step. I thought we were making this simpler. How do you actually find these tools and how do they fit together? And how do you actually use them to build up a secure software supply chain? That's the goal of this tool's mapping effort because it's not just one tool for each of these steps. This is just kind of an example software supply chain just for the build step that you could build. But there's multiple different ways that you can combine all of these wonderful tools in a way that actually provides all of the security properties that you need. So what the supply chain tools mapping does is it provides kind of a landscape of these supply chain security tools categorized by which requirements each tool helps you meet. And some of the tools that you use today actually probably provide you with some of these requirements if you just turn on certain configurations or use them in a certain way. And there's also existing integrations with other tools. So you can use this mapping to then figure out what the easiest tools for you, where you are today, are to then move forward. The current status of this process is in data collection and organization. We have a series of projects focused on open source projects along with the different requirements that each of these projects is able to meet. Sometimes there are some projects like, say, Six Store that has a various different sub-projects. So it's sometimes broken down like that as well. And the end goal is to make this into kind of an interactive landscape, something like the CNCF landscape where you can click into the different steps in the software supply chain and find all the tools that you need to meet your goals. And we're still in the process of this data collection. So if you write a software supply chain tool, especially in open source one, we have lots of opportunities for contribution or if you have a lot of that kind of front end development experience, it can help with making this more interactive and usable. So it's also a great opportunity to come join in. As well as updating capabilities of existing tools in this current data collection stage because the data is only as good as the experts that help provide the data. So there's some data in there now, but there's always room for improvement. And what we're gonna get from this is that if you look at the series of requirements, in this case, this is for securing the source code. These are the requirements taken directly from the cloud native security best practices white paper. These are all just kind of a summary of the requirements for securing the source code with a series of tools that actually can help you provide each of these steps. So if you look at this, you actually have a couple of different options to put these things together and achieve all of this if you just like take something that gives you each row and combine those in a way that works for you. And some of these steps aren't exactly a tool like the automation step is there's no tools today that are in the mapping that provide this property. So if you know of one, you can add to the mapping or you wanna write a new tool. This also kind of helps us identify gaps in the open source tooling that folks can then go and develop new tools for and solve those as well. So to summarize what we're doing here is we're taking this map of lots of tools, all of which solve pieces of the software supply chain and we're mapping them into the different steps in the software supply chain that they solve. This is of course not every tool that's out there, but this is kind of an illustration of how some number of tools fit into this mapping. I know a lot of people taking pictures like to stay here a sec. But you can see at each stage, source dependency build artifact deployment, there's a number of different options and within each of those stages, none of these tools actually solve every single problem, but you have to use these tools together to actually address every requirement. So you can kind of zoom out and zoom in to figure out how to actually address all the problems in your software supply chain. What's next? So in addition to mapping out these tools to make it easier for folks to find them, we have a call to action to make it easier for newcomers to this space to not need to understand all 50 of these tools or however many there are there. And to make this complexity invisible to end users by creating other open source tools that combine all of these tools in a way that actually can secure your software supply chain end to end or at the very least, secure one of these steps end to end in your software supply chain by kind of putting a lot of these tools together into overarching tool into a box, something like a reference architecture. And the security tool belt effort in the open SSF is definitely taking steps in this direction as well. But always remembering that it's important to know what's in the box and why it's there. Just because you have a box that solves some amount of problems, you wanna know exactly which requirements that this tool is solving for you so you can make sure that you're still actually meeting every single one of the requirements for every single one of the stages of the software supply chain. Going back to there. Yeah, so in conclusion, it's called action. This is all open source work that we're talking about. So that means that all of you can help make it better. Sli chain, a tools mapping effort. There's a link there to our data collection effort as well as some, a link to the issue where we're working with the CNCF to help with that visualization effort, which of course everyone could also get involved with as well. The supply chain best practices white paper that this mapping effort is based on is going through a V2 revision. This is another great place to get started. If there are requirements missing from this mapping that you think should be there, they should probably be in this V2 of the white paper. So if you come talk with tag security, you can get those in there as well. And eventually we want this to be a tool that everyone can use to find all of the open source, wonderful open source tools in this space and actually solve all of the gaps in their software supply chain so they can really address the security of the space together. Yeah, I think we have some extra time. So if folks have any questions, feel free to come up. Thank you all. Oh yeah, there are mics in the middle there if folks don't mind going up there or I can repeat the questions if you can shout. Hi, thanks for the talk. One question regarding the amount of work which is required, is it a one time effort to implement all those things in the pipelines or is there some regular work needed from people to get it running, keep it running and so on? I think it's a little bit of both. I think right now I think the goal is just to have an initial effort to have the whole mapping in a nice visual way. And the maintenance work I think will be less than the initial work of getting this together, making it really usable. Then it'll just be updating capabilities. As tools add more capabilities, it should be as easy as changing your configuration to then just add those capabilities. And hopefully the maintainers of those projects will be incentivized to help show that their tools meet these requirements and help us keep it up today. Thank you very much. Hi, good morning, yeah. Thanks very much for the talk, very informative. I just wondered whether you mentioned something like 50 tools there and I just wondered whether you're also providing some guidance on the ease of use, adaptability of those tools. Because obviously I imagine there's a number of tools that are doing the same thing. So that's one question. The other thing would be the provenance of those open source projects themselves. So is there some way of us certifying or getting behind the provenance of the tools? Thank you. Yeah, thanks for the question. As far as the usability of the tools, I think the goal here and I think the goal of tax security in general is to not like pick winners but to really help people identify the projects. There are other projects in the space that can help folks with things like the governance of these projects, things like the OpenSSF scorecards effort or other kind of scoring efforts of projects to kind of get some insight into what's going on there. I think that's still a work in progress. I think we still have more metrics that we can look at to judge the health of projects. I think that's actually a great question in the whole software supply chain space more generally. But yeah, I think including something like scorecard metrics or something like that is definitely a potential future direction for this. Cool. No one has any other questions, I guess we could. And so yeah, we'll stick around for a bit too if you wanna come up and chat about any of this or anything else at all related to this. Thanks everyone.