 Hello, everyone, and welcome to our talk. Today, we're going to provide an overview of Salsa. My name is Joshua Locke, and I'm an open source engineer at VMware, a current container of the update framework, and a steering committee member for the Salsa project, which is what we're here to talk about today. And I'm Tom Hennan, a software engineer at Google and contributor to the Salsa project. At this stage in the conference, we've heard a lot about software supply chains. So we're not going to describe them in any detail here. The diagram on the screen portrays a notional supply chain and indicates all of the places that the code could be tampered with. And you're going to see versions of this diagram throughout the talk. So we just wanted to show an unmodified version to ground the discussion. But let's start with a definition. What is Salsa? Obviously, this is an acronym. It stands for supply chain levels for software artifacts. And Salsa is a security framework for securing a software supply chain against tampering that's focused on protecting software from source through when it's used and letting users make automated decisions about the integrity of the artifacts that are used. And Salsa consists of a set of requirements which effectively will have become the recognized best practices in the industry. And through a leveling system, those requirements can be adopted incrementally and with an improved security posture for each additional level that you attain. But the real life demo cake that makes Salsa shine for me is that as well as software components produce and publish Salsa provenance, users of those software components can automatically verify artifacts before including them in their own software supply chain. So this high level overview already includes a few concepts which are worth lingering on. And we'll spend the next few slides doing that. The Salsa requirements are arranged into levels where each level improves the security posture of supply chains which meet those requirements. The explicit leveling has a couple of nice consequences for adopters. First, it enables them to choose the security posture they want to achieve. And secondly, it enables incremental progress towards higher Salsa levels. Each new level builds on the work achieved in prior levels with high levels putting more of the requirements into infrastructure components which form the supply chain. Specifically, the build service starting at level two and the source control service starting at level three. The table on the slide here gives a high level kind of description of each of the Salsa levels and example controls implemented at those levels. The table is taken from salsa.dev.com slash levels. The URL is on the slide here. So you can read the detailed explanation of each level and find the full list of requirements for each level on that page. But by now you've already heard me say tampering a few times and you might be wondering exactly what we mean by that word. Well, I think this picture indicates our scope and it's similar to this special tape on packaging or the foil that you get on medication that helps you identify when the thing has been opened and therefore potentially interfered with before you've received it. Software supply chain security is a large domain and you could reasonably argue that every aspect of software development forms a part of the software supply chain. Salsa is not trying to solve all problems. It's focused on protecting against modifications which were not authorized by the software producer. And so how does it do that? Salsa has its set of requirements but how are they automatically verifiable? The verifiability is achieved by supplying evidence of adherence to the requirements. This evidence is captured in the form of an attestation which is some metadata which effectively describes the artifact being attested to typically by a cryptographic digest. Some information about the artifact in the case of Salsa that's how the artifact was produced and then the authenticating actor who generated the attestation. So typically that's gonna be a cryptographic key and some kind of key identifier. Sorry, a cryptographic signature and some kind of key identifier. These attestations are generated throughout the supply chain and as the conveyor belt ish diagram here indicates they're propagated forward through the chain allowing later actors to automatically verify the artifacts and make policy decisions based on the attestations. The standard Salsa attestation which captures the information about adherence to Salsa requirements is the Salsa provenance format and you can see that on the screen here. We can see that a provenance attestation captures information about the artifact, the builder that generated it, the recipes used to generate the artifact and additional materials that contributed to the artifacts. Provenance attestations in an ideal level will be published alongside the associated software so that those making use of the artifacts can do automatic verification of the artifacts. And then along with the attestations, the other major technique for Salsa to meet its goals is through hardening the platforms that form the software supply chain. Salsa requirements capture best practices for securing source control and build orchestration systems to prevent them from being affected for tampering. So effectively Salsa has these three trust boundaries. The source control systems to build orchestration systems and then a kind of pre-admission gateway whether it's automatic or manual and they all combine to prevent artifacts being tampered with or prevent tampered artifacts from being used. And through these three trust boundaries we'll now spend a bit of time exploring some of the attacks that Salsa protects against by following the gremlins as they work their way backwards through the supply chain. And we'll see how Salsa makes it harder for the gremlins to do any damage. Because time is limited, we're not going to discuss each of the threats in this diagram. Instead we'll work through one example for each of the major Salsa trust boundaries and explore how Salsa helps to protect against use of software which has been tampered with which is threat hate on the diagram here, compromise of the build platform, threat D on the diagram and an attack which submits bad code to the repository threat A on the diagram. So to introduce our first attack I'd like to hand over to Tom. Thanks Joshua. So we'll start our discussion with the gremlin trying to get users to use a bad package. So somehow a gremlin has managed to steal credentials to the Fetcher container repo which is used by thousands of projects. And the gremlin uses those creds to upload a malicious version of the Fetcher image. And now they wait for people to download it. Then during a routine update the Vax trial analysis cluster runs the latest version of the Fetcher container image. This gives the gremlin access to all the data in the trial analysis cluster. But it doesn't have to be that way. Salsa comes to the rescue. Here we see the trial analysis cluster being protected by an emission controller which uses a Salsa policy checker. The policy checker uses published Salsa provenance signed by the builder to check the image against a policy before running the image. The gremlin can't fake the provenance with the stolen container registry credentials. So the emission controller blocks use of the evil Fetcher. If the gremlin still wants access they have to go further back in the supply chain increasing their cost. But what is this policy and what does it actually check? So to start, there are always some implicit policy checks. So here we see the signed envelope and we need to check if this key was used to create this signature. And then we need to check if that signature validates this payload. Then once we decode the validated payload we check to see if the key ID referenced in the envelope is authoritative for the builder ID used in the payload. Going beyond implicit policy checks here's an example of an explicit policy that does a number of other checks. I should caveat this by saying that this isn't a real policy language and we're still working on an example policy engine. This policy is pretty simple and it should be easy for users to understand and write. Let's dig in. So here we see the scope field which identifies the things that this policy applies to. In this case, if you're trying to use the Fetcher image then whatever artifact is going to get used needs to meet these other requirements. This is basically the name of the policy. So the policy engine knows what the salsa levels mean and policy authors can use salsa levels as a shorthand for checking. Does the builder in the provenance meet the corresponding salsa build requirements? Does the source listed in the provenance meets all the corresponding source requirements? And more. So beyond that policies can specify what builders are allowed to produce these artifacts. And in this case, the policy only allows images created by Zool CI CD. So an attacker would need to get Zool to build the malicious image that they want to publish. This gets checked against the builder identified in the provenance. Policies can also specify what top level source repos can be used to build the artifacts. In this case, the policy specified in the image or pardon me, the policy specifies that the image must have a milled from source in the Fetcher Docker GitHub repo. This gets checked against the associated material listed in the provenance. Finally, the policy specifies the specific Zool job that should be used to build the container. This gets checked against the entry point is specified in the provenance. Since the build instructions are stored in source control, the policy doesn't need to include details on how everything was built. That's delegated to the build instructions and the policy author reviewer don't need to care about the details. They also don't need to update their policy if changes are made to how the build is done. Unless, of course, the entry point changes. And with that, I'll head back to Joshua. Thanks, Tom. So at this point, the Gremlin has been denied tampering with time of use. So it needs to go back once that further into the supply chain. So let's see how the Gremlin try and compromise the build platform. So imagine our Gremlin has gained, managed to gain access to the system that builds releases for a common utility. Perhaps they successfully fished for super user credentials for the build platform. They use this privileged access to replace source code after checkout before the build is initiated. This allows them to insert malicious code into common utility undetected. This bug.code then gets signed and deployed to all users of common utility, where it could do all sorts of things, Bitcoin mining, data exfiltration, and so on. But of course, it doesn't have to be that way. Celsa can save the day. Celsa level four includes a set of common requirements, one of which is for multi-party approval for actors. That includes approval by a second platform administrator for super user access. These common requirements raise the cost of compromise through platform and operational hardening so that malicious actors must do more than just successfully fish one of the platforms for which users. Celsa level three also requires isolated and ephemeral build environment, making persistence more difficult, and reproducible builds at Celsa level four make it easier to detect malicious code insertions before they are deployed. For example, by having parallel infrastructure which verifiably reproduces builds before signing and releasing. So denied at the build platform, our gremlin is forced to go one step further back again, and they'll now try to submit some bad code into the source code platform. So here our gremlin gains hands-on access to a laptop while the laptop's owner is distracted at a conference. They then use that laptop to force push some code into a repository, a gremlin housekeeping attack, if you will. The threat model of security keys do not include physical attackers at the machine. So those increasingly common account protections fail us, and the gremlin is successfully able to push code into a repository, which may go undetected. And innocuous change, like adding an additional third party dependency, where the dependency includes any malicious activity, could go undetected for some time. But again, it doesn't have to be that way. Salter level four requires code review by two strongly authenticated users, which significantly raises the cost to an attacker. If the code is being reviewed in this way, the compromise must be a sophisticated attack. So it has to provide both a compelling change, which a reviewer is inclined to accept, along with some kind of difficult to detect malicious change kind of embedded in it. The attacker has to craft and deliver the change in the limited time they have hands-on access to the compromised machine. They need to avoid the reviewer following up with the author, so the change has to be a fairly obvious change. And they also need to cover their tracks. For example, if the code review system sends an email to the author when a change is submitted, the attacker also has to delete that email, which may mean further access to additional systems. All of which increases the cost of the attacker significantly and the risk of being caught. And to wrap up, I'm gonna hand back over to Tom. Thanks Joshua. So these were just some examples of the tampering attacks that Salsa can protect against. To wrap up, let's start by discussing Salsa level one. Within Salsa, adopting lower levels is expected to be easy while getting to higher levels is probably hard. The journey starts at Salsa level one, now a project shouldn't stop there. We do think that level one provides value as a starting point for improving your supply chain security. For example, it sets up infrastructure for creating, communicating and using provenance. And it highlights opportunities for improvement within your supply chain. For example, I don't know what infrastructure we care about becomes, we need to improve these systems and projects. And here's a roadmap for what we need to do. Part of that roadmap is adopting higher Salsa levels. So to reiterate, projects should not stop at Salsa level one. For example, the provenance produced at level one isn't signed, so an attacker could easily tamper with it. And level one builds can still take place on individual developer workstations, which may be easier for attackers to compromise. So Salsa is still in development and your contributions are welcome. Some of the things that we're currently working on include how to communicate trust in the build and source control systems, libraries and various languages to create Salsa antistations, policy engines to evaluate those antistations and fine tuning level requirements. And we'd love your help to make Salsa a reality. Some concrete steps that you can take. Platform devs, platform devs. You can produce the Salsa provenance. Project devs, you can automate your builds and use platforms that produce the Salsa provenance. Users, you can ask for and use Salsa provenance for your dependencies. And everyone, please provide feedback on what works and doesn't. Thank you for your time. Thank you.