 My name is Chris, and I'm a member of Google's open-source security team. I've been contributing to the Salsa spec for somewhere between six and nine months, and today I'm here to talk to you about the 1.0 specification release and a proposal I've been working on along with Josh Mulliken from Red Hat on setting up a conformance program for Salsa. To get us all on the same page briefly, Salsa stands for supply chain levels for software artifacts, and it is a supply chain security framework hosted in the open SSF. It's designed to track incremental progress in supply chain security for build platforms and software artifacts. Who is this talk for? Well, software developers, infrastructure providers, all of these people. By the end of today, I hope that developers will understand the benefits of Salsa and why they might want to adopt it. Infrastructure providers will understand why you may be hearing demand for Salsa, especially from build platforms or from package managers. Security auditors, I hope you'll have an idea of how a Salsa audit might work. And users, I hope you understand the benefits of using Salsa conformance software. And I do want to say our friends over at Red Hat just released an updated version of a mapping between Salsa requirements and different compliance regimes that's on the open SSF Slack. So if you're interested in meeting your compliance needs, you can look for it there. And of course, everyone here, I hope, will learn how to give feedback because this is an open source project. It is always, always in progress. And especially conformance is really just getting started. So here is today's agenda. I'm going to start by giving an overview of Salsa version 1.0. Then we're going to go on a quick deep dive into the build track, which is the bulk of the Salsa specification. I'm going to talk about our proposal for a conformance program and then one quick slide on how to get involved with the project. A quick disclaimer, Salsa.dev is the canonical resource for all things Salsa. If I contradict Salsa.dev, the website wins every time and the mistakes are my own. All right, let's move on to the overview. Once again, Salsa is supply chain lovers for software artifacts. And it is a security specification with associated tooling for tracking incremental progress in in securing software supply chains. What sorts of problems does it solve? Well, glibly, we're securing the software supply chain. But what that actually means requires taking a quick look at how Salsa models a software supply chain. In short, a producer writes some source, the producer being a person or group of people such as a solo developer, open source project, business and source is not just source code, but probably source code. It is anything that is authored or reviewed by a human. That source gets fed into a build to create a package. A package is what it sounds like. It is finished built software that you consume. What is a build? A build is the process that converts source into a package and also resolves dependencies. Dependencies being any packages required to execute the build. Finally, a consumer uses the package, hopefully after verifying its Salsa provenance. Provenance being metadata that describes how a package meets Salsa's requirements. What sort of problems does Salsa solve? We hope over time to address threats across the whole supply chain from source code tampering to dependency tampering or build process tampering. Sorry, don't read it. The text is very small. It's for reference. Go to Salsa.dev. But right now, we're focused solely on the build portion of the supply chain, which means if you verify Salsa provenance, you can detect if your build process has been compromised. If your package registry supports Salsa, then it can stop malicious actors from uploading compromised packages in the first place. If you verify Salsa, you can detect if your registry was compromised in a serving you a bad package. In the final step, you can always verify provenance again to make sure that whatever package you have is what you expected. How is Salsa setup? It's a framework, a specification, also tooling. It's kind of also a brand. Right now, it's just a box in this diagram. But then within that box, we have different tracks, each track being a different portion of the supply chain tracks contain levels, which offer common language for comparing systems and their supply chain security status. And they're each level builds on the previous the last one so that you can track progress incrementally. The tracks keep different portions of the supply chain separate to the teams that are responsible for working on them. So if you're in a large organization, the team that handles your Git repos does not have to worry about about your built your build server farm. Those are separate concerns. In Salsa one dot oh, we've defined the build track levels one through three, and the others are coming soon. Excuse me for a moment. All right, now let's take a closer look at the build track. So from a bird's eye view, these are the build levels starting from zero, which is trivially true for anything that is sorry, any package that is not doing salsa trivially meets L zero, it's nothing. Level one means that there is some provenance metadata. It's really just documentation of the builders intent. It's not signed. It's not complete. It's not even necessarily accurate. But it is and that's something build level two means that the build is hosted on some build platform, which means that you have a second party attesting to the authenticity of the package, not just the producer but also a builder. And build level three, the builds have been hardened, which means that the build platform that is running the build is guarded against specific attacks and is more sophisticated than a build level two platform. These are the requirements for the build levels. Again, don't read them. We're going to walk through them. Not at a ton of detail, but just enough to try to build some intuition. So the build track gives requirements to both the software producer and the build platform that you may remember from the build model or from the supply chain model. For all three build levels, the producer has the same requirements. The first is to choose an appropriate build platform, which means build your software somewhere that can support the salsa level you want. If you want to do salsa build level three, but you choose a build level two platform, that means you need to nag the platform to add L3 support, which is a great thing to do. Everyone should do it. But it might not be the best choice if you want to support salsa in the short term. The second is to follow a consistent build process. That means use use the same tool repeatedly use similar options and flags. The idea behind this is that if you're going to verify salsa provenance, you need to have some expectations about what it should look like. If your build process changes so much that nobody could feasibly write a policy about what it should look like, then you are not doing salsa correctly. Finally, distribute provenance, because the provenance metadata is evidence of doing salsa, you need to share it when you share your software. For the build platform, there's only one requirement at level one, and that is that the provenance exists. It doesn't need to be accurate, complete or assigned. It just needs to be there. It is pretty much just documentation. So this is my example of a level one build setup. I am writing code on my laptop. It's just me. I'm going to write a shell script that calls GCC. My laptop and that shell script are my build platform. And you can attack it anywhere. An attacker could get into my laptop, change the source code, change my build script, swap out my libc, or even mess with the web server where I'm hosting this because I cannot be bothered to put it in a normal package registry. In this example, I think where that arrow is is probably at the package registry upload. So my web server has been messed with. And the attacker is able to swap the provenance and the package. And nobody can detect that change because it hasn't been signed or verified in any way. It is just documentation of my intent. That's build level one. At build level two, things get a little bit more sophisticated. The build platform gets two new requirements. The producers stay the same because again, the producers are the same for all three levels. The first requirement on the builder is that the provenance be authentic. That means that there needs to be a way to prove that the build platform created the provenance, not the not the software producer. The second requirement is that the build be hosted on the build platform instead of local to the producer. And if you think about it, the hosted requirement comes from the authentic requirement because the build platform cannot faithfully attest to the accuracy of the provenance's contents unless they actually host the build and run it for you. So if I want to do a level two setup now because I'm tired of my laptop getting messed with, I can use the open SSF's Fresca project and set up my own Kubernetes build cluster. I am, however, bad at Kubernetes, and it's not well secured. So it only meets build level two. In this case, an attacker is able to run a parallel build on my Fresca installation, and that that build breaks out of its container and swaps out my package and tricks the build platform into signing their malicious package. And I've been thwarted again. So at build level two, a second party is attesting to the software's provenance, but it is not necessarily a sophisticated second party. That's level two. At build level three, the guarantees get stronger again. So once more, the producer's requirements are the same because they're the same for build levels one through three. But the build platform needs to create unforgeable provenance and use isolated builds. What we mean by unforgeable is that the provenance is they believe it to be complete, accurate, and that they store the key materials or any other metadata used to cryptographically verify the provenance in some hardened way. And that can be using a cloud KMS server and HSM, or even there's a way to do it through SIG store as well. The isolated requirement is again required for the completeness and accuracy of the provenance, because if the builds are not isolated from each other, then they can mess with each other, and the platform can't attest to their accuracy or completeness. In addition, the build needs to be isolated from the build platform in order to secure the key materials, because a malicious build could, of course, seal signing keys, and then mince false provenance. So here, I've got the same Kubernetes setup from level two, except I get someone to help me harden it properly. The attacker can't modify the control plane, and so they don't get to mess with my build. You can see the emojis frowning this time. So you can see through the move from L2 to L3 that Salsa tooling supports a seamless upgrade for the producer, where from level two to level three, I didn't change what the software that was being built. But the build platform needed to be upgraded. It just so happens I was running both. But usually that's not the case. And I want to point out that the the require the it is intentional that the work to move from L2 to L3 is on the build platform, not the producer. There are orders of magnitude more people writing software than there are people creating build platforms or services or build software. If we put the work on everybody who writes software, the job would never get done. And I also want to say, if I didn't want to upgrade my fresco installation, I could have used another open SSF project, the GitHub salsa generators, which will produce salsa level three provenance. All right, now let's take a look at the conformance program proposal. Again, this is something that I've been working on with Josh Mulliken from Red Hat who couldn't be here today. So to get us on the same page, what is a conformance program? It's a way of officially saying that a product or a service meets some standard or specification. If you've ever looked at a cloud provider or some other software vendor, you might find a page that has all of these badges or a chart on it. Those are marks of conformance. And it could be that someday salsa will have a conformance badge on that page too that might look like that. Why does it need a conformance program? Well, let's think again about the different build levels and who you have to trust at each step or at each level. At level one, we just have documentation, so you're trusting the whole supply chain. At level two, you're trusting the build platform and its tenants. And you, the anchor of trust moves from everyone, but all kind of the producer, to the everyone involved in building. Then at build level three, you're trusting that the build platform has isolated the builds from each other and that it's basically built better than an L2 builder. The provenance doesn't look very different between L2 and L3, and you can't detect that change in verification. All you can do is configure your verifying tool to say, if it's signed by this build platform, it's L2, that platform is build L3. So we need a way to determine who to configure as level three. I think the best way to do that is with audits. The stronger guarantees for level three should require stronger proof than the guarantees from level two. What would this program look like? Well, Salsa kind of has one trick and that's levels. I guess we have tracks too. We have two tricks. But here it'll be a two tier program starting with self-certification and moving to third party audits. They're called tiers not levels because I do hope that tier one will disappear over time. It's more of a bootstrapping mechanism. So for tier one, it's similar to build level one in that it's primarily documentation. This also community will maintain a questionnaire that build platforms need to answer about how the platform meets Salsa's requirements. Then each build platform will answer the questionnaire and gather up any additional evidence they think is necessary for the community. They'll publish it to a public registry controlled by either the Salsa community or maybe the open SSF. They'll commit to keeping the questionnaire up to date and making public vulnerability disclosures should they have any security incidents that impact their systems. Then they'll sign terms and conditions and get to use Salsa's badge. At level two, tier two, yes, thank you. At tier two, you start to get stronger assurances. So before the actual audit, an audit will or an auditor will publish their proposed audit procedure to the open SSF's registry. And they'll agree that they will always, whenever they do an audit, they'll publish some report about it. It's okay to hold an audit for a bit to respond to vulnerabilities or let a build system fix itself because this program is not about punishing anyone. It's about making sure that secure build platforms are available. But if for whatever reason you bury reports, the community will kick you out. Then when performing an audit, you publish the report to the registry, the build platform signs, terms and conditions, and they get to use a Salsa badge. Maybe with your auditor logo, it's unclear. All right. So last little bit, how to get involved. The canonical source for all things Salsa is salsa.dev. We have community meetings regularly, more than different special interest groups, but there's at least one meeting a week. You can also go to the open SSF Slack and go to the Salsa channel or check out our GitHub organization, which is Salsa framework. Finally, if you have feedback on the conformance program, it is Salsa proposal triple zero five under the Salsa proposals repo on GitHub. And I'm very much looking for feedback from people who have compliance backgrounds or experience doing security audits, because that is not me. All right. I think we should have time for questions now. Go ahead. I can repeat the question. Okay. So the question is whether or not auditors would be paid. I expect so. I could imagine some audits being done for free, but I don't see any reason why an auditor's labor has no value or would have no value. Another question. I see. Okay. The question is whether a an organization should have audits internal to its different dev teams or whether public platforms should be audit should be getting audited. I think the answer is both, and it depends on the use case. So I absolutely think public platforms should be audited. Internal teams, I think it kind of depends on why you're using Salsa. So I didn't go into this, but you can use Salsa strictly for internal purposes, perhaps to meet compliance needs, or you can use Salsa for software that's meant to be consumed externally. If you are strictly doing it using Salsa internally, I don't think an audit is necessary because the trust boundary ends at your company. If you are doing Salsa for external consumption, it again depends. If your infrastructure is specific to your organization, then you should have it audited. If you're using a public service and it has been audited, then there's no need to do it again. The question is about how Salsa maps to other other frameworks like the NIST cybersecurity guidelines. So I mentioned this briefly earlier. Our friends at Red Hat just finished an updated mapping between Salsa's 1.0 spec and a whole bunch of different standards. It's available on the OpenSSF Slack. And if you come talk to me afterwards, I can make sure that you're able to get it. I'll put a link in the slides and reupload the slides. Then everyone benefits. I'll do that. Yes? The question is about isolation, specifically network isolation and authentication. So in Salsa version 0.1, which was the alpha version of Salsa, there was a level four that included a hermetic requirement. And we've held off on publishing level four because it's been difficult for us to nail down what hermetic means. And we weren't convinced that it would be stable in the same way that levels one through three are stable. So level four isn't a draft. And I would expect that sort of isolation to be part of build level four. When you say that it wouldn't be stable, do you mean that because of security standards changing frequently, it would be different? No, sorry. What I mean is that we are confident that build levels one through three, at a high level at least, will not change. For example, we might want different levels of hermeticness. It's a word, I just can't pronounce it. That could be like a build level four, part in build level five. It's not clear. We haven't decided. That's the instability, not the actual once we land on a meeting, meaning we expect it to be stable. Okay, thank you. Of course. I also have two questions. One, do you expect the auditors to have like a continuous auditing or is it like a human being actually going into like get up and auditing them? And the second question, do you see like auditing going into like open source build system that I can deploy on my own and the open source is audited or something and I can deploy it and have Salsa level three without like paying hosted services that went through this? Okay, so if I got that correctly, the first question was whether the audits are at a point in time or continuous? Is that right? Yeah. So I I'm not entirely sure this is a point of feedback. I think or where I'm looking for feedback, I think annual sounds about right to me and I think I've seen that in other compliance regimes. But I'm I'm picturing a person either in inspecting architecture documents or source code or even I could imagine penetration test to it's kind of up to the auditor. Although it's worth noting that Salsa has a set of guiding principles about how it will develop over time. And one of those principles is that when you trust a a piece of infrastructure, a build platform, it should be audited by a human because that is labor intensive and you only do it a few times. Whereas when you are dealing with provenance that you verify perhaps every time you're going to launch a job. That's done automatically because you do it a lot and it needs to be quick. Did that answer your question? And your second question was about whether there are going to be open source or on prem build platforms available or whether only cloud services would work. Is that correct? Basically, if you like see a helm chart that is compliant to Salsa level three and I can deploy it and build my stuff on it on my own cluster without going into GitHub and asking for their hosted services. Yes. And I think that that the open SSF's Fresco project should also can be deployed on prem and it is completely open source and can be configured to meet build level three. Any other questions? I guess I'm just kind of going back to that and based on the information, I'm a little bit confused. Maybe it's my organization's objectives being different. But you said something that that was maybe confusing to me. It's up to the auditor to decide what information will ask for in order to certify. Is that the understanding? Because to me that seems very flexible and therefore is not following a framework, right? The question is about asking for clarification on the audit or who determines the audit procedures. So in the actual proposal, the the requirement is that the audit procedure at least gather all of the information that would be in the tier one questionnaire. Beyond that, I I mean, the way I think about it is that we're we're moving the the root of trust and it one of the ways that you determine whether you trust an auditor is by looking at their procedure and seeing if it meets your organization's needs. So yeah, beyond the I guess minimum standards set by the tier one questionnaire, it is up to the auditor. OK, that makes more sense. Thank you. Right. If there are no more questions. Thank you very much for your time and your questions.