 Hello everyone. Thank you for being here. So my name is Arnaud Ars. I'm part of the Open Technology Group at IBM. I've been involved in open source and open standard. It's pretty much my whole career. I brag about the fact that in 1990, I did my first release of something which back then we didn't even call open source. But the funny thing is I actually recently discovered it's actually still being used. It's running on my HP printer at home. So, you know, the power of open source is there. So anyway, today we want to talk about the supply chain integrity working group at OpenSSF. I've been involved personally in OpenSSF for the last two years. And so I just have a couple of slides I'm going to show you to give you a little bit of context. And then we will have a discussion with my co-panelist here today to try to give you a better idea of some of the names that are floating around OpenSSF. So it should be well known to everybody I'm sure now that, you know, open source software in general but through open source in particular is under attack today. We are seeing an explosion in attacks. Basically, you know, bad actors have discovered that as we harden production systems, there was a soft spot which was the software supply chain that incorporated the law of open source, a lot of which is not very well secured. So this is a problem that has become so important that governments around the world has actually taken note and actually starting developing as we heard earlier in the keynote different regulations around the world to basically tell the industry, wait a minute, we cannot keep going like this. You need to fix this problem. And so OpenSSF is part of the movement from the industry to try to address this problem. Of course, you know, it's a bigger problem than any single organization can address. So OpenSSF is by no means the only organization out there working in this space. There is quite a bit of overlap in some cases. We're trying to collaborate with other organizations, even within the Linux foundation, right? There are different foundations working on these aspects. And so the OpenSSF was actually launched over two years ago. Initially, we were doing the COVID era. Quite frankly, organizations like IBM and other vendors were not too sure about what the economic impact was going to be. And they were not so eager in investing in a new foundation. And so the project was started in a fairly, you know, a typical way with regard to how typically Linux foundation starts projects in the sense that there was basically no funding associated with this. And so for the first year, it kind of grew organically. And I think we actually feel some of the pain because of that still today, because the organization can grew in a different ways, in different parts of the organization, fairly disorganized. And but after a year, we were getting out of COVID and people realized, okay, maybe this is not the end of the world, thankfully, we can actually take this problem more seriously and put money behind it. And there was a sort of reboot of the organization in 2022, where we moved to a more well funded organization with, you know, organization actually putting real money behind it. And so we now have these funds available, we have a fully staffed organization from the LS staff. And the members have been busy, some of us are involved in the governance structure of the organization, trying to get it all sorted out and make sense of all the activities that are going on. So this is a high level view of the organization. I'm not going into the detail of this. This is not the point of this presentation. It's just to give you an idea at a high level, we have a governing board, and then we have the technical advisory council that kind of oversees all the technical activities in the organization. And what we're going to talk about mostly today is what's in that black square or rectangle there, supply chain integrity working group, right? So we have different working groups addressing different parts of the problem. And we have one that's specifically focusing on the supply chain integrity problem. And within this, each group, right, actually has a whole bunch of different activities within them. They take different forms, and we're still trying to figure out all the details of the governance aspect. But at a high level, we are different types of technical initiatives. They are projects that are mostly focused on developing code, like actual programs that you can use. And then there are activities that are more like working specifications, or best practices, documents, guidance, that kind of stuff. So again, what we're going to focus on today is what's at the top right corner there, the supply chain integrity. We have different activities within that working group. So we have Salsa, which we'll talk quite a bit about today. There is actually two different groups within related to Salsa. There is one that works on the specification, Salsa is a specification. And then there is one that actually focuses on projects. So there are tools being developed that actually help you use and implement Salsa. And then we have Fresca is one of the implementations of Salsa, which we'll talk about. And there is S2C2F is another specification. And then there is another, there's a group, which is the integrity positioning working group. It's a bit different. It tries to give a little bit more of positioning for the different pieces, how they relate to one another within OpenSSF and beyond, and try to identify possible gaps so that we can put that on a roadmap moving forward. And then there is a newcomer. It's not officially part of OpenSSF today, but I'm hoping maybe it will become. And there has been a proposal, so it's not completely accidental. I'm bringing this up. It's called Guac. And I think, you know, whether it ends up in OpenSSF or not, I think it's a tool that's related to the supply chain integrity. And I think it's worth mentioning. And we have one of the co-panelists involved in this. So he can tell us more about this. So that sets the background. This is what I wanted to kind of give you as a background for the discussion today. So now I would like to turn to the panelist and let them introduce themselves first. So, sure. I'm Mike Lieberman. I am a co-founder of the Software Supply Chain Security Company, Kusari. I'm also an author of the book, Securing the Software Supply Chain by Manning Publications. In the open source space, I'm a CNCF tag security lead. I'm also an open SSF tag member. I'm also a steering committee member. And I'm also the co-creator of the Guac project. Laura. I'm Laura C. I work at Red Hat. I'm a manager of our supply chain operations team under product security. And I participate in the positioning group for supply chain integrity. My name is Joshua Locke. I am a steering committee member on the CELSA project and tried to get involved in a bunch of the open SSF efforts and paid to work at Verizon in the new open source program office. We're just kind of bootstrapping that. Jay White, I work in the open source strategy ecosystem team in Microsoft. I'm all over the damn place. And I'm being all over the place in Microsoft, all over the place in the open SSF, and in other open source communities as well. I'm a board member. I'm a board member on Oasis Open. I work in the supply chain integrity working group as a co-lead. I'm a co-lead of the positioning, CIG, co-lead, and the S2C2F, CIG, co-lead in the DE&I education subcommittee. Am I forgetting? Anyway, I'm all over the place. I love this stuff. So that's why I'm all over the place. I don't sleep much. Okay, go ahead. If Jay lists all the group he participates in, we ran out of time before the end. Every time I join an open SSF call, Jay's on it, no matter what it is about. So thank you. So I mean, the goal is primarily going through all these different technologies so that this alphabet soup kind of thing makes more sense at the end, right? So we're going to go through a few rounds of questions, and then of course we'll open to the public if you have questions as well. So let's get started with Salsa. Laura, can you tell us briefly at a high level what Salsa is about? Yeah, sure. So Salsa stands for supply chain levels for software artifacts, and it's a set of guidelines for securing your software supply chain. It is established by industry consensus to prevent tampering, to improve build integrity, and secure software packages and infrastructure. It's also organized by tracks and levels. So there are tracks that are focused on a specific aspect of the supply chain. Right now we have just the build track, so it makes it easy to keep track of. And then the levels, so it's measured by security levels for incremental adoption, and the build track has three levels right now. So one, two, three. Thank you. Michael, Fresca. Sure. So Fresca is a implementation of the CNCF's secure software factory reference architecture. It utilizes a bunch of different open source tools like Tecton, Tecton chains, Spiffy Spire, the Q language, if anybody's familiar with that, along with some other tools to try and create something that really implements Salsa and looks at what can even go beyond when it comes to securing the build and securing the supply chain. And Jay, I'll turn to you for S2C2F. S2C2F, secure supply chain consumption framework. Eight practices, four maturity levels, takes you all the way through ingesting open source to how you protect it, preventing, if you can prevent attacks, all the way to auditing now, how you audit the nature of your protection methods into fixing things and then upstreaming. Really designed for the consumer in mind, so how the individuals ingest and consume open source software. And then pairs very nicely with the other frameworks as it takes from one end, takes you into the middle and then allows connective tissues on to the others. All right. Thank you. And so let's finish with Guac. Sure. So Guac is a tool, a backer name for graph for understanding artifact composition because it's Salsa and Guac. So it's intended to be sort of an ingester for all of your software supply chain metadata, whether it's S-bombs, whether it's information from sites like OSV or depth.dev, scorecards and tries to aggregate it all into a graph that can then be used so that from the consumption side, you can kind of say, am I enforcing the best practices and those sorts of things? So you can ask questions like, am I enforcing this S2C2F requirement? Do I have a Salsa attestation for this project? That sort of thing. All right. So let's now get a little bit deeper into what's behind those high-level introduction. So I mean, Joshua, maybe you can tell us a little bit more about Salsa. Who is it for? What is it for? So Salsa is really focused on kind of improving the machinery that we use to build and deliver software. So the end users, the developers shouldn't have to do too much work in order to adopt Salsa in the ideal circumstance. The build track especially is very much focused on people building CI and CD systems. And the next things we're going to work on is training more of those platforms together to improve the integrity. So one of the core principles of Salsa is trusting platforms and individuals. So we can identify a system that we trust and root trust in that rather than trying to evaluate whether we can trust all of the individuals producing software in the spotlight. So Laura, how does that relate to compliance? I mean, we heard earlier there's more and more references to regulations and compliance which plays an increasing role. How does the Salsa fit within the compliance picture? Sure. Yeah, it provides evidence for attestations and it also strongly aligns to NIST's secure software development framework. It also aligns to NIST 800-53 for security and privacy. Also 800-161 for specifically written for supply chain. And even OWASP, and we did a mapping to OWASP for SAM version 2.0, which stands for software assurance maturity model. And so if you are trying to attest to any of those industry frameworks or governmental frameworks, it's stepped in the right direction. And it's great because with the Salsa specification group, it demystifies how to implement that for the build requirements. All right. Thank you. So Jay, I know compliance is also something that you hold close to your heart. First, let's go back to S2C2F. Who should use it? And the big question that people always have is, so how does S2C2F compare to Salsa? So S2C2F is for the end user, for the end user, for the consumer, specifically designed to manage dependencies. Where this differs and then aligns with Salsa. Salsa is a more producer-focused framework. So it concentrates on builds in general, where S2C2F controls how you manage dependencies that go into that build. So this is where you'll see a lot of S-bomb creation. This is where you'll see ties into other things that we're working on, like VEX and things of that nature. These are the tie-ins with not just stuff that we're working on inside the openness, but these tentacles that reach out to other organizations as well. So end user in mind, consumption in mind, dependency management in mind. And then aligns with Salsa, where when you take on these things like S-bombs and VEX statements, and now you're branching over into Salsa with builds and how these builds get produced, and then they go out and create these software that our shared customers consume, now the one-two punch gives off that assurance that, hey, and I said the word assurance, right, gives off that assurance that, hey, things were done securely from front all the way to back. And the compliance aspect, do you have more to say? So, Laura did a good job of providing the mapping between Salsa and SSDF and then OWASP and 800-53. Well, S2C2F does the same thing, right? There are mappings that go back and forth. So if you take the controls in S2C2F and then write down there in the bottom of it, you'll see the mappings and the mappings are very similar, right? So you are able to meet certain compliance requirements, but even more so, right? So here in Europe and in the States, also South America, Australia, there are all these different privacy requirements that are being developed, security requirements that are being developed, but even more so, these cyber security requirements around how software gets developed, how it gets consumed, and when they say consumed, you mean by the person buying the software and whether or not they're secure, the security's in place enough for them to use it and therefore not to be data disclosures and everything else, right? All this stuff is happening. But these frameworks attempt to do, because we're working so closely with them and we're so close to these different, these different regulations that are being developed, is that we get a chance to say, hey, how can we meet the metric at the same time, not reduce productivity? So when it comes to compliance, right? I always refer to this meme with the truck that got these big giant wheels, but they forgot to change the entire in the back of the truck that has the original factory wheel on it, and all the thing says is you got to have that wheel on it, right? That wheel has to be, therefore, the truck to be compliant, and nothing says that the wheel can fit on the little big wheels that you now put on it, right? So when it comes to compliance, I say, all right, let's meet the metric, but also let's make sure things secure. What we have to be careful of is to not over engineer in the process. So that's how I feel about compliance. You could meet the compliance requirements, but let's make sure that we're still keeping our thumb on security controls. All right, thank you. So let's talk about the status of those different technologies. So Laura, what's Salsa actually hit the major milestone in the spring? Can you tell us more about the status of Salsa? So yeah, Salsa released its first version, so version 1.0 in April, and it specifically focuses on the build requirements and specifically for producers and build platforms. So the build platform requirements include provenance generation and isolation strength. For provenance generation, it starts with level 1, it just must exist, right? And then level 2 would be to authenticate. It must be authentic, and the third one would be that you have to be able to deliver the provenance. And so with regard to the isolation strength, or I'm sorry, unforgeable, I believe this word is used for build level 3. And then for isolation strength, level 2, it must be hosted, and then level 3, it must be isolated. So that's, but with all that, there's also an attestation model that goes along with it so that you can sort of like a analogy with the manufacturing factory. So the first step would be to have that tamper proof seal for the code. And the second would be to verify that the artifacts were created by who they said it was created by with this stamp made by Harry in Michigan. And then the third would be to just implement industry best practices. Yeah. All right, thank you. I will interject that there's something that has confused people a little bit, which I think is worth explaining about Salsa, because it's kind of like we have three dimensions at play. We have the version of the specification. So in this case, we're at salsa one zero, we have different levels and different tracks. And it becomes a bit like, you know, puzzle to put all the pieces together. So I think you need to understand that those things are actually unrelated in some ways. The idea was, you know, well, we have the version of the specification. And it surprised a lot of people that the one zero has less than what salsa zero, I think five was the previous version to 0.2. Okay, 0.2. And so this was actually, you know, a concerted, you know, a decision in the group to say, okay, we cannot focus on trying to address all the issues we have with the original draft, which, you know, we have to give them credit. It came initially from Google. So they came with a specification that contributed to OpenSSF. And as it always happens, I am an old standards guy, you know, every time you bring your spec, you think, oh, this is solid. Well, as soon as you submitted to public scrutiny, you realize there's plenty of holes you have not even thought about. And so it happened there as well. So a lot of issues came up. And then the group said, well, if we try to address all these issues, we'll never be done any time soon. And so there was people already implementing the salsa 0.2 draft that was out there. And so the group decided to basically narrow down the scope. So we went from four levels to three. And we reduced the number, we came up with this notion of tracks to define different domains, if you will, and focus on the bill track for the one zero. And some people were offended a little bit, you know, because they say, wait, you know, you're basically, you know, we cut short of the original offering because we remove stuff. And some people said, how can you even dare calling that a one zero? You should maybe call it a 0.5 or something like this. But so this was, you know, concerning the effort within the group, everybody agreed, this is the most rational way of progressing and getting something out there that the industry can start using sooner rather than later. Yeah. So the one zero was really an indicator of confidence and stability, not of features. And so we effectively in software terms removed features from zero to one to zero. But that's because the focus was always. So one of the things I think super interesting about what's happening in the SCI working group is that it's basically taking best practices that companies and communities have developed over years and trying to enshrine those in standards that people can implement in incremental ways and as easily as possible. And so what we found with South Level 4 and some of the non-build requirements, or build Level 4 and some of the non-build requirements, is that we were struggling to articulate those in a way that everyone could understand and that would be equally applicable to like Google and Microsoft scale organizations as to, you know, three person open source projects. And so that's why we ended up removing those things ultimately while we continue to work on reintroducing those features, but with those kind of goals in mind that being very clear and relatively easy, you know, none of this is easy to implement, but at least clear to implement and well, well described. So why don't you continue on this actually trend and tell us what's happening now with regard to Salsa. I mean, as we talked about Laura, I said Salsa 1-0 came out in April and quite frankly, after that seems like nothing has happening. I was involved in the group and I think honestly, everybody needed to take a break a little bit and focus on other things because we worked really hard to get that 1-0 out, but work is starting again. So can you tell us what's happening? Yeah, so we did take a break. Some of us changed employer, but we have resumed effort. We've got a few things happening. So we're trying to release an incremental patch version. So we're following semantic versioning so that we can indicate when we're making changes, which are incompatible. We're trying to make sure that we signal very heavily when people should be paying more attention to changes in the specification. We've been making some editorial clarity edits over time to the 1-0 release, but working towards the 1.1, which introduces further clarity, but based on how you interpret it, that could be considered to be a significant change. So that's why we're working towards this patch number release, not patch number, minor version number release. But we're also working on new features that we don't have a concrete timeline for, but we're focused on source, which is something that was removed from the 0.2 version of the spec. Notions of whether the source has been reviewed or scanned by various tools. How you can have a greater level of assurance that the source code that you introduced into your build system is the source code you expected. So we have some of that encoded in the build platform, the build track, but there's definitely a lot more we could do. So that's a very active area of discussion. And then we also want to introduce some additional considerations for the build platform. So one notion that was in Salsa 0.2 that we unfortunately lost a bit in 1.0 was this, because it's so abstract, we can very easily hand-waverly say two people should approve everything as a general kind of principle, but then how do you turn that into kind of something concrete for each of the different tracks? So with code review, it'd be like you should have two reviewers effectively for each pull request or for the build platform. We like this notion of you can't make changes to the platform itself, whether that's the operating system or the users that are enabled on it and things like that without a second approver. So no one rotation. I think there's an XKCD comic which uses the $10 rent security metric. And so we're trying to make sure that we don't have a, although we have a two-range factor effectively throughout the specification. So yeah, the things we're working on, the source track, build platform, and then we want to reintroduce level four of the build track. All right, thank you. Yeah, go ahead. Yeah, so that is absolutely a concern that has been raised and why we have struggled. We have this notion of, I forget the exact term we used, but effectively, if you're a maintainer of a project and you open a pull request and another maintainer reviews it, that's kind of two because you're already a known trusted entity. But if you are a non-maintainer and you submit a pull request and that's reviewed by one maintainer, that's a weaker level of review because there's only one trusted known entity involved. But I didn't do a great job of explaining that and trying to write that in clear and precise text has been a challenge. But then also, even that is contended. We would like open source projects as much as possible to be able to achieve as many sales to levels as possible. So yeah, that is a great question. It is a topic of contention. We don't have a good solution for that. We are definitely going to have to strike a balance between security goals and supporting smallest projects. But I think ultimately there will come a cutoff where if you're a tiny project you'll only be able to reach a certain level. And I think that accurately reflects the kind of risks that people are implicitly taking on by depending on a single person project. Just going to have an organization dedicated to software reviewers that can be able to reach out and be like, I need a reviewer on the pull request and then all of a sudden you're soft on the line. That would be a good way for me if an SSF to spend all of its money very quickly. And you know it's very easy to create new GitHub account too. So one person can impersonate right? Not suggesting anything but I mean there are limitations that are well understood. So you're creating a standard, I suspect, or attempting to. Could you, instead of that, can we get it on Zoom, for example, right? How a verification of an entity is the literal entity that's in the center? Yes. But I don't think we have time to address the question now obviously. This is a big question. You know my view on this general premise, we cannot address the whole chain of problems we are facing, right? But this is still moving us a step forward. It doesn't solve everything but it's still better than if we had none of this. I think it is important seriously to know that we are concerned by these kind of things and there are people in the group that raise that concern and we do joke about it but we, one of the reasons that we remove that requirement for the initial release is because we don't want to place arbitrary barriers towards open source projects becoming secure. That's ultimately, most of us are there because that's our passion, our interest. We don't have a good solution and one of my characteristics is that I make jokes about things that I can't solve. Yeah, it's definitely a big problem that we would like to try and address and we don't have a good solution. All right, so let's move on a little bit because I still want to hear Jay give you a chance to talk about the status of S2C2F and what's happening? What are you guys doing? So S2C2F is evolving all the time. As a matter of fact, we've just added a new control. We added one, a few months ago around audit and then we added a new control around another threat that came up and it was very recent. I can't remember. Please go to the Rebo. Look up the issue when the pull request is there. Trust me. Anyway, one of the other cool things that's happened in those that we just had a hackathon internal to Microsoft, of course, and I tried as hard as I could to get external participants, but the hackathon was to develop an attestation tool that can provide a level of assurance of meeting at least level two on S2C2F. And of course, that's through doing specific get hub actions and things like that. We're still trying to perfect it, but the great thing about this tool is that it's formatted in OSCAL format. Now OSCAL format, I'm still working out or helping to work out. By helping, I mean doing a whole hell of a lot of complaining, finger pointing questions, asking and waiting for answers. And then when I get those answers, they give me the answers and I'm asking people, but really trying to operationalize OSCAL such way because it's so dynamic that you're able to report out a machine readable format and provide those assurances in machine readable format that says, hey, you are indeed meeting level two because it was an automated check that you have these specific things enabled that provides that level of assurance. Anyway, that's happening right now. That's also very exciting. Also, S2C2F is working with GWAC closely as well to see if we can bridge that gap between putting the artifact stuff on the end of S2C2F so now you can provide that historical context of where things were, where things are now, and of course, where things are going to be in graphing format. And I say that to say once again, these tentacles. Right? These tentacles, man. So yeah, so that's where S2C2F is there and of course, you know, we'll say this at the end, I'm going to say it now though. Come on in, the water's warm. So Michael, why don't you follow up and tell us a bit more about GWAC? What's the status, what's going on there? Sure, sure. So GWAC is currently sort of in beta. It's had it's like 0.1 release a few months ago and now we're up to 0.1.2, maybe 0.1.3 this week. I haven't been checking up on my emails. But so, you know, GWAC, as I sort of mentioned before, is trying to kind of come in and ingest all this data from places like, you know, Salsa, your Salsa attestations, your S-bombs in all the various formats, and lots of other supply chain meta-data like OSB, Depth.dev, scorecards, and associated with the stuff like the artifacts, the identities that sign those artifacts, and those sorts of things into a giant graph that you can then query to kind of, you know, ask questions like, am I compliant or conformant to this S2C2F requirement? Am I conformant to this NIST requirement? And so, yeah, GWAC is very much focused on that sort of thing. So you can ask questions like, do I have log for shell somewhere in my known software supply chain? Right? And also in addition to that, GWAC really tries to help answer the question of, do I have enough information to be able to answer that question in the first place? Because that's, like, I think one of the key things that's been missing from a lot of the software supply chain stuff is people just go and say, great, I generated a S-bomb. Well, is it accurate? Is it complete? Do you know? And so, with stuff like GWAC, we can start to see where are sort of the big gaps, you know, where does, you know, my supply chain supposedly end, right? You know, I might have three or four layers of artifacts, and then somewhere down here I have my final artifact, but does it still have its own dependencies or do I just not know? And GWAC is hoping to help answer that and helping answer stuff like, if in the future you're like, hey, I have some salsa ad stations that came from this party, we know they were compromised. So now we are concerned that all of these artifacts that we might have ingested over the past X amount of months are now vulnerable. Find me all of those artifacts. Where do they live? Where do they live in my software supply chain? And then also eventually where are they deployed? And how do I answer that? And then potentially where are the central areas that I need to upgrade to just be able to kind of sort of fix the problem, fix those vulnerabilities upgrade and that sort of thing. All right. Thank you. Unfortunately, we're already running out of time. So to finish, I would like to invite everybody, you know, I recognize quite a few people here. So a lot of you already know that. But, you know, one of the particularities of Living Foundation organizations, they're open to everybody. Of course, you can be a member and support these organizations financially. But independently of that, you're welcome to participate. So I invite you to look into OpenSSF. I give you a quick overview. If you haven't looked into it, there's certainly something, if you're in this room, there's probably something that was of interest to you. We welcome every newcomer. Typically we have calls. There's an open, there's a community calendar that's available where you see all the different calls from all the different groups on the calendar. Don't be intimidated. Feel free to join. Typically, we make an effort to give every newcomer to introduce themselves at the beginning. If you're not comfortable, it's okay to just pass and stay silent. But we all were there once first time, right? So don't let that stop you. Just, you know, attend. And as you get more comfortable and you feel like you want to contribute, you can start participating. I do want to also point out that if you want to know more about Salsa, there's actually a good opportunity. There's a tech talk that's going to happen on October 5th. It's online. It's free. You can participate, attend. I put the QR code there. If you can't scan that, you can find it from the website. If you go to openSSF.org and you go to the events, it's actually listed there. And there's all the information on how to join that event. So I invite you to take that as an opportunity to learn more about Salsa. Several people here will be part of that panel. And so thank you all for joining us today. We'll be around most of us for several more days. Feel free if you have another chance to ask us a question here to follow up later on. Thank you.