 I guess we can get started here. And I know it's the last talk of the last day of the conference. So I'm not going to try and not hold everybody up. I know everybody's tired, probably wants to if they pre-ordered it, probably play Zelda. So yeah, I'm going to talk about Salsa. Going to have a little bit of a demo on Salsa. And try and actually keep it relatively short and to see if folks have questions. And keep it relatively informal here. So a little bit about myself. I'm Mike Lieberman. I'm a co-founder of Kusari, a supply chain security startup. And also a member of the Salsa Steering Committee been there actually since day one when Google first released it to the public. And I was like, hey, what's this thing? Is there a community meeting? They're like, we just announced this like an hour ago. OK, so let's start with, again, and I know this is going to be common for a lot of folks, what's the problem? What's the breadth of the problem that we're trying to solve? Well, one of the big issues is we're trying to kind of, part of the whole supply chain security thing is we're trying to take source, take dependencies, pull everything in, package it up, build it, et cetera, and push it out. And there's a whole lot of issues that can happen. You could have a developer or somebody who is posing as a developer submitting an unauthorized change. You can have your source repo that gets compromised. And all of a sudden, hey, you thought you were pulling down Acme's AppX, and then it turned out, no, you're downloading malicious Source X. And also, when the build itself tries to pull down the code or the source gets pushed to the build system, if that gets intercepted or somehow something happens there, that's an issue. And then you have all the dependencies in the world that you might be pulling in, your open SSL, your Glibc, your log4j, all that great stuff. What happens if there's dependency confusion attacks? There's typosquadding. There's all sorts of things that could possibly happen. And then when you go and you're even after you've actually built your software, well, what happens if somebody manipulates it before it actually reaches the package repository? That's another issue here. What happens if somebody messes with your package repository so that all of a sudden you thought you were hosting, once again, Acme AppX, and then you're hosting something malicious? And then for the consumer, there's risks at the consumer level where they think they're using your application and it turns out they're pulling something down that isn't that. Now we're going to talk a little bit about, so for Salsa 1.0, which was just released a few weeks ago, there has been a focus on the build track, and what we're calling the build track. And so the build track here is focused around where that red box is. And this is where we're trying to really focus on what goes into the build and the build itself, and then what comes out of the build. And I'll explain a little bit why we have been focused on there. But really what we're doing here is we're tracking what the source, the build ingests. We're tracking the dependencies that we're pulling in. We're recording all of this stuff, and then we're also recording the parameters to the build. And so let's talk a little bit about why this is, in our opinion, like a good solution here. So you have this hierarchy of supply chain, towards a supply chain solution, where first you want to have a trust foundation, and what does that mean? You want to be able to say what are the identities that I trust, and not just the identity I trust, but what are the identities within my supply chain? So I know who is doing what, whether it's who's building what, or where did this software come from, like is it coming from ACME, is it coming from trusted developer X, to trusted developer Y, or is it coming from unknown person X, or even known malicious provider, a no malicious provider. Then on top of that, you want to be able to go and say, okay, well I want to have all these documents, or all this metadata that's associated with those identities. If I'm a build system, I want to go and tell people I built this thing. Here is, I have a bunch of metadata that I am then signing. So you know it came from me. And so this is where stuff like S-bombs come in, Salsa, VEX, et cetera. And then for folks who were here for the previous one, you want to then be able to kind of take all of that, those S-bombs, those Salsa attestations, VEX documents, all of this great metadata that's being produced with their associated identities. You want to then pull that in, you want to synthesize it, aggregate it, do analysis on it, and that's kind of where stuff like Guac comes in. And then finally on top of all that, you want to then run policy, right? Your OPPA, your key verno, and so on, against that data so that you can kind of know, hey, I want to only run software that has been built with Salsa. I only want to run software with Salsa level two at least, or Salsa level three. Salsa build level three, I should say. So yet another introduction to Salsa, right? So for folks who aren't aware, Salsa is a supply chain security framework. I'm going to be talking purely about build 1.0, there was some stuff over, you know, we had V0.1 for a while, and so I know there's still some stuff that's still using V0.1, but I'm going to be focused more on 1.0. And so Salsa build 1.0 has three levels, right? It is, Salsa has now been split into tracks. The build track is the first track that we've released, and Salsa has a provenance statement format in TOTO format. So for folks who are not aware, there's a thing called an in TOTO statement, an in TOTO attestation. Also sometimes referred to as ITE six or ITE six. And it is an easy to generate and consume JSON format that you can then have essentially subtypes called predicates that are, you know, can be whatever metadata. In this case, Salsa is a particular predicate type, and so the Salsa build predicate is what we'll also be talking about. And for folks who maybe are a little bit aware of the community or might be wondering, right, like why focus on the build, right? There's all this stuff in supply chain security, why are we focused on the build? Well, the build is probably the most critical part of the supply chain, right? You're taking source code, trusted or untrusted dependencies, you're pulling all of that in, and then if you're compiling, right, you're running who knows what, right? You're running some sort of arbitrary actions against source and dependencies, and then you're packaging it up into some sort of often binary artifact, and then you plan to publish it, right? It's not just as simple as, hey, I'm pulling down a file, it's not as simple as, hey, I'm adding two numbers, right? You're doing a whole lot there that's hard to reason about compared to a lot of the other steps in the supply chain process. The other thing is, you know, provenance is generally missing in the community, we've noticed, right? There's very few people who are recording, yep, here's my artifact, and this is the source it came from, and this is exactly the commit hash and so on. That has generally been missing, and so how do we track from source to built artifact? And that's where Salsa, you know, that's why Salsa has been so focused on this particular piece for pretty much the past almost two years. And so how does Salsa 1.0 help, right? You know, there is, there's really two main actors within Salsa, there's the producer who is a, the software producer in this context, and there is also the implementer. And so, sorry, not the, hold on one second, the build platform. And so as a software producer, right, you know, which many folks are, probably most of the folks who would be using Salsa are more on the producer side. What are the requirements from your end, right? You wanna be able to choose an appropriate build platform, you wanna follow a consistent build process and you wanna distribute provenance, right? So for you, for folks who are just building software, there's not really a whole lot other than, hey, use a Salsa compliant build system or a Salsa conformant build system. And when choosing appropriate build platform, this is stuff like choose a secure one, right? When following a consistent build process, it's like, hey, don't have a million different ways of doing the same build, try and follow an actual process that can be easily tracked and that when you give that provenance information, it's not super confusing and complicated for the end user consumer. And then when you're distributing provenance, right, you wanna be able to, whether it's, you're publishing it to an OCI registry or you're emailing it or whatever, right? You wanna have some way of doing it, preferably not email, but you know what I mean. And so for this, the examples here, right, are Kubernetes itself uses Salsa and generates Salsa provenance. NPM packages as of recently are starting to generate Salsa provenance. And you can imagine like a Hello World application, you could just sort of do that. Then there's also the other sort of actor in here is the build platform and the folks who are working on the build platform are the ones who do the majority of the work here. So first off, right, there is a set of requirements and I'll explain in detail what those are, but generally it is two main categories. First is you wanna generate provenance, which is just I wanna take some stuff from your source and dependencies and so on. And I wanna kind of record that, I wanna record what I did in the build and I wanna record the information of the outputs. And then you wanna also have some elements of isolation, right? You wanna make sure that for your users, right, your no given build can mess with another build, whether it's a previous or future build or two builds that are running at the same time, right? And so this is where build systems come in. Examples are Fresca, GitHub Actions, GitLab CI, Jenkins, Circle CI and all that good stuff. So let's dive in a little bit more, right? So what exactly do I mean by provenance generation? Well, there's three requirements as a reminder. You have exists, authentic and unforgeable, right? And exists is for level one, right? And exists just means, hey, are you generating salsa provenance? And though salsa provenance recommends in Toto, the in Toto predicate, sorry, the in Toto statement with the salsa provenance format, it could also just be as simple as like, hey, you're recording the logs and you're recording all this information and so on. And this is super useful for stuff like audits and investigations, right? Because how many, hey, I've been there, right? You're like, hey, where did this artifact come from? Is that one of ours? And you start trying to dive through build logs and see if something recorded that, yes, this was actually built by us versus it just somehow appeared and you find out later on that some developer somehow got access and went, yeah, we were trying to hit a deadline so I ran the build locally and I just forced pushed it to production and you're like, whoa, whoa, what? That sort of thing, right? So then for level two, right, you wanna have authentic, right? And that's where you're actually signing the provenance, which means you're associating an identity with a particular software provider. So you're sort of saying, hey, I am signing off with my build system. I am signing that I used this key or whatever that I signed off on this artifact and this is where you're actually signing that provenance and it's just pretty much a way of saying, yep, me ACME provider is signed this artifact. And then that lease to level three, which is unforgeable, which is pretty much means those signing secrets that you're using can't be, are not accessible by the build itself, right? So a lot of folks just sort of say, yeah, no, no, I give the build the access to the signing secret. Well, if that build happens to be malicious, that signing secret has now been stolen, right? And there's lots of different ways to achieve this, right? Some folks use ephemeral signing secrets or per build signing secrets and so on, but also you can sort of secure the signing secrets from the build and sort of record the build from outside, which is also super useful here. And this protects the provenance that you built from malicious user builds and I'll explain a little bit more what that means in a second. Okay, so for isolation, next up is isolation, right? So you had the provenance generation piece, now you have the isolation piece. And so there's two main requirements there. The first one is hosted, pretty much means, and this is at level two, pretty much means don't run the build on your local workstation, right? You know, lots of developers still are running builds locally and hey, that's not great practice for various reasons, developers, malicious or not, right? You could have malware on your machine. It's much harder to control a workstation than it is to sort of control a build, a controlled build system that has lots of security controls and a lot of great stuff on it. And then isolated, pretty much just means, builds can't affect each other, right? Builds running concurrently, can't access each other's resources, and build environments are ephemeral. So, you know, you can't conflict either in space or time. And so how does this protect us, right? Well, it's also level one is kind of, something is better than nothing, right? It helps with investigation, but it's also only as good as the trust and worthiness of where it came from. So if you are super sure that everything's secure, maybe you can start to say like, yeah, L1 is good enough for me, but it's the big piece of L1 is it's a start, right? A lot of folks today are not recording what they're building, they're not recording what they built, I should say. They're not recording any of this information and, you know, moving forward, starting recording that information, starting recording all this, so you could go back is a start, right? Still doesn't necessarily protect you in case your build system was already compromised or a particular build was already compromised, but it's a start. And then remember, level two here, you're associating identities and systems with the software itself, right? It helps prevent attacks against developers and their workstations, stuff like that. You know, it also helps, you know, people understand, you know, where the software was built because now you've associated identities with the build systems. You now have a much better understanding that, yes, in the very least, this did come from ACME, right? Or somebody who stole ACME's key, right? And that's a, you know, better than, you know, better than L1 where you're like, I have no idea. Somebody is telling me that it came from somewhere. And then it's also L3, so this is much better, right? Where you're now enforcing security at the individual build level, right? So that individual builds cannot conflict with each other. This helps us prevent attacks against the build systems themselves, right? Where, you know, you could have potentially a malicious build that's going around trying to infect other builds, right? Well, now, you know, by implementing those isolation requirements, as well as the Providence generation requirements around unforgeable, that helps prevent attacks against the build systems. It also helps us provide sort of granular identities that can be tied back to an individual build. So it's not just that ACME built, you know, this piece of software, it was ACME built this piece of software at this time, potentially on this individual build. And it also helps in, you know, a compromise of a single build doesn't mean that all the builds are necessarily compromised. And so what isn't Salsa, right? What is it not, right? Well, Salsa can't prevent malware from being built. It just makes it easy to detect, right? So that's, I think, a key piece because a lot of folks just assume like, oh, Salsa's supposed to prevent, you know, all malicious behavior? No, no, no, and to be clear, we might still move in that direction, but we found the big gap was folks were saying, yep, I'm securing my build, I'm doing all the right things, but I'm not actually keeping track of any of that. Okay, well then, how do you actually know? Whereas here, the idea is, if let's say you go back and you say, oh no, this particular hash was malicious, this file was malicious, well, you've now tracked that in your Salsa, you could go back and, you know, whether it's using a tool like Guac or just sort of scrolling through all of your Salsa attestations and analyzing them, you go back and say, okay, what are all the Salsa attestations that said that they use this file? And then, you know, what is, Salsa is also not a comprehensive set of rules for ingestion, right? So for as the end user, right, you, you know, who's just more of consuming stuff, you want to kind of look at another open SSF companion project under the supply chain integrity group called S2C2F. And that project, you know, is a bit more focused on, hey, as the end user, in which case there were requirements like, look at consuming Salsa built artifacts. So how do you Salsa? First off, from the build platform perspective, right? You know, if I am building my own build platform, whether I am a team within an organization or if I am planning to run a SaaS that is gonna be Salsa compliant, it's about securing your build system infrastructure, right? By that I mean like, you know, the VMs, the hardware, all that good stuff. You should be securing your build system control plane, right, that means, you know, make sure that users can't run, if possible, like obviously malicious or insecure sorts of builds, right? If the requirement here is they should be running, if they are supposed to be running only Salsa builds, cool, don't allow them to run a build that wouldn't be Salsa compliant, right? You wanna be able to secure builds from each other, and you wanna also enforce rules on your users. And then as a software provider, right, you can pick, you know, for you, you wanna be able to pick a Salsa conformant build system, and for example, for level two, you definitely wanna secure your signing secrets. For level three, that becomes more of a burden on the actual build platform, where often the build platform will either provide through OIDC or a similar mechanism, a sort of like individual identity that is associated with that build, but can be related back to, you know, who you are as an organization, or as a developer or whatever. And then on the right hand side, this is a QR code to the secure software factory, which is a CNCF white paper, which I helped co-lead, which sort of talks more in detail about how you might look at securing a build system. All right, next up is a demo, and feel free to, you know, follow along here. So this is actually going to be based on some great work from some of the folks at the ghost team at Google, that regarding sort of the new NPM Salsa builder here, and so give me one second. So first off, I'm just going to go in and I'm going to go in and I'm going to update the version here of this. It doesn't really matter what this application is, but it'll just update version, push this out, give it a second, and hopefully, and this run this. And so what this actually is going out and doing, and we can kind of talk a little bit about the architecture a little, but largely, you know, I'm going to oversimplify it a little bit, because it's not a deep dive into the architecture, but the GitHub Actions Salsa builder, what it does is it uses what's referred to as a reusable workflow, which a reusable workflow here within GitHub is something that the user of the actual build can't themselves modify, and because they can't modify it, that means that reusable workflow can be used to essentially observe the build. It can record what the build is doing, sign off on the build itself, and the actual end user build, this NPM commands are not actually, the NPM commands never have access to the actual signing secret. They are never also like outside of, they're not generating the provenance themselves, so there you have the workflow that actually is generating the provenance, and because that workflow is hard-coded and you would have to go and update the workflow in order to change it, and that workflow is under control of a different team, not under the control of the developer who's running the build, outside of just saying, hey, the developer says, hey, I use this, that means that that's much easier to audit, that's much easier to test, that's much easier to look at compared to an end user build, which they can largely write whatever they want, they can run whatever they want, and just say, yeah, I did it, yeah. So this thing will help out there. And so it takes a little while, but it's essentially just running a build, and then it's generating provenance, and the generation of provenance is actually, it essentially, let me see if I can find, well, I'll show you what the predicate looks like while it's publishing, let me actually show you that. So this is what an attestation looks like, and once again, not even though Salsa, even though Salsa v1.0 of the provenance spec has been released, not every tool supports it yet, in fact, very few do yet, but in the coming weeks, we'll see that change. But pretty much here, we can see here that under the predicate type, you have a Salsa provenance. There's some information in here about the bundle. Not gonna go too deep into the details here, but if folks have questions, feel free. But pretty much here, what I'm doing is, I'm just sort of, what this is doing is essentially just recording that, yes, this was built within the context of GitHub that it was recorded in Rekor or Recor, and this is the signature. And if I go back here, okay, so it's been published. And cool, so now I can go in, well, first off, I can go in and look at over here, and I can see here that there is a 0.1.134 version, which is the one that it goes back to. It shows that, yep, it was built and signed on GitHub Actions, and we have proof of that. We know that this is the source commit that this MPM package came from. This was the build file that actually ran it. So now, if you are as an end user, you're going in and you're like, hey, I wanna use this MPM package, but I'm not so sure that they built it right. Well, you go back and this is proof that it was built in a particular way. And then you can also get the transparency log entry, which is, this is Rekor for folks who are not so familiar. This is a transparency log, so it's, I don't want to misstate how it works, but it's pretty much immutable ledger, so you can't modify the records as they're coming in, or sorry, you can't modify the records once they're in. So you have a record that yes, this was signed and built in at a particular time. Cool. So now what we can do is we can do a couple of things. If I go back here, do this. So I can also, if I do MPM install, and I update to the latest package, I can also do, I can now also audit the signatures. You can see, hey, there is a verified signature here, so this was signed by my key, or by, sorry, the key that came out of GitHub that gets generated as part of the OIDC flow, and I'm not gonna go too deep into how that works within Sigstore, but there is essentially the token that's associated with this GitHub build is exchanged with another piece of Sigstore called Fulcio, and then you get a certificate that's used for a single signing activity. And right now MPM doesn't support verifying the actual salsa attestation, but we can still do that via a couple of commands here. And so I just have this in a shell script, so I'll just run it, right? And so pretty much what it just does is it downloads the attestations, it downloads the actual package, and then essentially verifies that, yes, the hash of this package relates back to the, relates back to the, the hash of this package relates back to the, what's actually in that salsa attestation. And then in addition to that, we can also test out a couple of things here, right? Where we can say yes, the builder ID should be this builder, Node.js salsa3.yaml, if I were to go in and I don't know, change that to salsa2.yaml, right? And do the same thing, it's gonna go and, Oh, right, right, right, I have a, my bad, I have a version. Right, it's gonna say, hey, I expected, there's salsa3.yaml in there, not salsa2.yaml. And you can, there's lots of different things in there. And then you as the end user, right, who is consuming these packages, you can start to build out like policy rules around these things. If you know, for example, this is supposed to come from github.com and Librenav5 slash actions-test, you could test that, you could verify that against the salsa attestation. And as long as you trust that github actions itself is secure and telling you the right thing, that information should be accurate. And this helps out because if you download a package and all of a sudden you're like, wait a second, the salsa attestation says something completely different than what I assumed, you can block on that. Cool, so, yeah, that's about it. Yeah, and, oh, actually, first off, let me go back here. There's a couple, I have one more slide or two more slides, okay. So where is salsa going, right? So there's gonna be new tracks for post-salsa 1.0. The ones that are most likely, and once again, even though it says these things here, they're not necessarily what's set in stone, but the new tracks are going to be most likely around source. That's gonna be probably the first one. So for folks who are familiar with salsa v0.1, you might be asking, hey, why'd you remove two-person code review? Like, do you not care about two-person code review? And it's like, no, no, no, hold on. We care about two-person code review. The thing was we wanted to focus purely on, like have laser focus on one thing, in this case, the build. And then the other thing we wanted to do is we wanted to separate it out into tracks so that folks don't think that the build system should be the thing that necessarily needs to confirm that you have gone through two-person code review, you should have the source system or something that looks at the source system essentially do that verification. And so for folks who are interested in that, we wanna hear more about that. We wanna hear more about different types of requirements you think should be there for what a different levels of a salsa source may be, maybe an L3 that recommends stuff like pair programming and stuff like that. We're also looking at probably a dependencies track. And as you can probably imagine, a dependencies track might look something like, hey, you should probably, it's recommended you also use other dependencies that are also salsa compliant, right? Or of a similar sort of framework, right? And then in addition to that, there's also the build system itself, right? So there's not really, there is some guidance around building a secure build system, but there's been some requests around, hey, how can I, like what can I start to do to build a secure build system? What are those requirements look like? And then for folks also who are familiar with V0.1, we remove salsa four. And that wasn't because we wanted to be less secure. Some folks have mistakenly think that, hey, you removed the reproducibility requirement and you removed the hermetic requirement. Isn't that less secure? It's like, hold on, the problem there was we didn't have clear definitions of what hermetic meant. There was a lot of debate about whether content addressability was hermetic, whether it really only meant just network isolation and all that stuff. So we took it out, but expect to see a draft coming soon and we want to see folks come in and help us, right? Help us define what salsa four means, help us define how to prove it and stuff like that. Next up, there's a conformance program which Chris over there is working on. And that is like, you can get a fancy salsa badge, but no, it's really about if you are somebody who is running a build system, whether it's a build system for your own organization or whether it's like as a sass for other folks, you can go in and say, well, here are a set of requirements that I am a testing to or that I've been audited against that say that I am, yes, I am generating salsa provenance that my build system is capable of generating salsa provenance that could hit a certain level, right? I'm doing the right things. Oh, do you want to just get the mic? So does, is the badge dependent on an assessor saying that you meet, that's easy to get a badge for your build system? So no, you can self-attest? Anybody can do whatever they want. Sure, well, so then that really comes down to there's two things and I'll let Chris clarify a little bit, but do you want to clarify? Just it's all still TBD, the proposal is on salsa framework slash salsa proposal. So you can read that in comment. Yeah, but the intent from the salsa community is to try and make it like, there's always going to be a burden on you as let's say a consumer of software to say, who do I trust who's telling me that this is accurate? But you might also say, hey, if you're a smaller provider, I might not trust you, but somebody else has audited you or looked at your stuff and said, yep, you guys are good. So I trust them, so I therefore I trust you. There's definitely a lot of ways that could go. And in fact, that's why comment on the proposal as well as there's going to be some meetings and we'd love to hear your feedback as well on that. And then in addition to that, there's also a tooling SIG, which I also help co-lead as well. And yeah, there's a lot of stuff that's changed with salsa 1.0. We wanna see folks who are tools providers come over and integrate your tools with salsa, whether it's like a build tool, whether it's a supply chain metadata ingestion tool or analysis tool or anything like that, as well as if you have ideas and use cases for other things like help us figure out how we can help the ecosystem better distribute salsa attestations and things like that. And then I'm gonna finish it up with come join us. So the left one is essentially just the site for OpenSSF, the calendar and all that good stuff where our meetings are on that calendar and the Slack info is on there as well. And if you wanna learn more about salsa, the salsa.dev website is on the right there. And yes. Yeah, I had a question on the conformance program. So I'm a bit familiar with some others like the cyberspace maturity model certification, CMMC or even OSHA's voluntary protection program. So these are, you have these frameworks and then you have these various levels that you have and you have these overall capabilities that you strive to achieve. So it looks like right now where salsa is it's largely self attesting, but is there a chance then that we're going to get to a point where you actually have a set of auditors or someone like that that would come out and then rate you against a certain level? Yes, so at least, so what I can talk a little bit about beyond just necessarily the conformance program itself, but generally the open SSF is open to doing some of these things and through partnerships like ASTF and Simbler, we're looking to do that actually for other open source projects. And we are looking at like some sort of criteria that an auditor can look at and provide an attestation or an assessment at a yearly cadence or something like that. But yeah, I definitely recommend come take a look at the, it's under the salsa framework GitHub, but there is a proposal there from Chris on how that might look like. And right now it's based a little bit off of the Kubernetes conformance program. And it's at least initially based off of that and then there's a bunch of more. I'm assuming that would include a lot of things, right? That would include training auditors and you have to have auditors certified and then you have like some conformance team or entity that maintains all these things and you have an expiration date where you'd have to be reasserted and things like that. The reason why I'm bringing all this up is as part of the Air Force, like it's great that I could go and tell my team we could use this, but then it's like, okay, you say that you're level three, but they're really wanting to have some independent standard body to come out and do that. Yeah, and I think that's definitely something, at least from the requirement standpoint, we're interested in building out. As far as let's say, and also potentially certifying auditors and those sorts of things. So I think on that end, we'd love to hear your feedback on some of the proposals for the conformance program and see if all your things were missing, right? For a lot of folks within the group, we're familiar with conformance programs in other industries, but definitely not government and that sort of thing. And so we'd love to hear more info. Yeah, get feedback on that end. Excellent, thank you. Yeah, you're welcome. So what's also level, oh, good question. That's actually also level three. And the reason being is, there's a couple of reasons, but one of the main reasons is because it uses that reusable workflow, that reusable workflow can't be modified by the actual end user build and that reusable workflow is actually doing a lot of the recording and actually signing of the metadata. And in addition to that, there's a couple of other extra pieces in there. One is that it uses, via SigStore, it uses the OIDC flow, which means that even if that build got compromised and somehow could steal the key, it could only ever be used to sign one build. It can't now be used to sign future, it has a very short lifespan, it's a single-use certificate and so on. It can't then be used to sign future malicious builds. Any other question? Cool, thanks.