Cloud Native Computing Foundation SupplyChainSecurityCon hosted by CNCF + CDF 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: An Overview on SLSA - Tom Hennen, Google & Joshua Lock, VMware

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

An Overview on SLSA - Tom Hennen, Google & Joshua Lock, VMware

SLSA – Supply-chain Levels for Software Artifacts – introduces a comprehensive methodology to prevent tampering with the software supply chain. To illustrate the impact of SLSA, we follow a few gremlins as they try to introduce malicious code into a container image used by thousands of projects. At each step of the supply chain we show how SLSA controls raise the cost of attack, preventing the gremlins from causing any harm.

A

Hello, everyone and welcome to our talk uh today we're going to provide an overview of salsa. My name is joshua lock and I'm an open source engineer at vmware, a camera trainer of the update framework and steering committee member for the salsa project, which is what we're here to talk about today.

B

And I'm tom hennan a software engineer at google and contributor to the salsa project.

A

At this stage in the conference, uh 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.

A

But, let's start with the definition, what is salsa? Obviously this is an acronym. It's for stands for supply chain levels for software, artifacts and salsa is a security framework for securing a software supply chain against tampering.

A

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 they are using and salsa consists of a set of requirements which caps are effectively what have become the recognized best practices in the industry and through a leveling system.

A

Those requirements can be adopted incrementally um and with an improved security posture for each additional level that you attain, but the realization, okay, that makes us shine for me- is that as more software components produce and publish sales of provenance users of those software components can automatically verify artifact before including them in their own software supply chain.

A

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 um the salsa requirements are arranged into levels and 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 sales levels.

A

Each new level builds on the work achieved in prior levels, with higher 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.

A

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. uh The tables taken from salsa.levels the urls on the slide here. So you can read the detailed explanation of each level and find the full list of requirements uh for each level on that page.

A

But by now you've already heard me say tempering a few times and you might be wondering exactly what we mean by that word. Well, I think this picture indicates uh our scope and it's similar to this special take 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 part of the software supply chain.

A

Salsa is not trying to solve all problems. It's focused on protecting against modifications which were not authorized by the software producer.

A

B

A

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.

A

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 we, how the earthquake was produced uh and then the authenticating actor who generated the f station. So typically that's going to be um a cryptographic key and some kind of key identifier, sorry, a cryptographic, signature and some kind of key identifier.

A

These attestations are generated throughout the supply chain and, as the conveyor belt is 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 other stations.

A

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, um we can see that a providence, lesser station captures information about the artifact, the builder that generated it. The recipes used to generate the artifact and additional materials that contributed to the artifact and provenance letter stations in an ideal world will be published alongside the associated software, so that those making use of the artifacts can do automatic verification of the artifacts.

A

And then, along with the added stations, the other major technique for salsa to meet its goals is through hardening the platforms that form the software supply chain, social requirements, capture best practices for securing source control and build orchestration systems to prevent them from being effected for temporary so effectively. Salsa has these three trust boundaries, the source, control systems, the 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 tempered with or prevent tampered artifacts from being used and through these three trust boundaries.

A

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 uh use of software, which has been tampered with, which is h on the diagram. Here.

A

Compromise of the build platform thread d on the diagram and an attack which submits bad code to the repository through a on the diagram so to introduce our first attack. I'd like to hand over to tom thanks.

B

B

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 credits to upload a malicious version of the fetcher image, and now they wait for people to download it.

B

Then, during a routine update the bax trial analysis cluster runs the latest version of the fetcher container image. This gives the grandma access to all the data in the trial analysis cluster, but it doesn't have to be that way.

B

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 source of 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 admission controller blocks use of the evil fetcher.

B

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?

B

So to start, there are always some implicit policy checks, so here here we see the the uh 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.

B

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.

B

In this case, if you're trying to use the fetch 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.

B

uh Does the builder does the builder in the province meet the corresponding salsa build requirements?

B

Does the source listed in the providence meets all the corresponding source requirements um and, more so um beyond that policies can specify what builders are allowed to produce these these artifacts, and in this case the policy only allows images created by zuul cicd.

B

So an attacker would need to get zuul to build the malicious image that they want to publish. This gets checked against the builder identified in the province.

B

Policies can also specify what top level source repos can be used to build the artifacts. In this case, the policies specified in the image are permanent. The policy specifies that the image must have been built from source in the fetcher docker github repo this this gets checked against the associated material listed in the providence.

B

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 providence, 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 and reviewer don't need to care about the details.

B

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.

B

And with that I'll hand, it back to joshua.

A

Thanks tom, so um at this point the gremlin has been denied uh tampering at time of use, so it needs to go back one step further into the supply chain. uh So let's see the gremlin try and compromise the other platform, so imagine our grimmer has gained uh managed to gain access to the system that builds releases for a common utility. Perhaps they successfully fished for super user credentials uh for the build platform they use this privileged access to replace source code after checkout, but before the build is initiated.

A

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. You know bitcoin mining data, exfiltration and so on, but of course it doesn't have to be that way. Salsa can save the day. um Salsa level 4 includes a set of common requirements, one of which is for multi-purple multi-party approval for alexis.

A

That includes approval by a second platform administrator for super user access.

A

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 platform's privileged users.

A

Sales level 3 also requires isolated and female, build environments, making persistence more difficult and reproducible builds at cells level. 4 make it easier to detect malicious code insertions before they are deployed, for example, by having a parallel infrastructure which verifiably reproduces, builds before signing and releasing.

A

So denied that the build platform agreement 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 hero romain gains hands-on access to a laptop. While the laptop's owner is distracted at a conference.

A

They then use that laptop to force push some code to a repository, a gremlin housekeeping attack. If you will, the threat model of security keys, uh do not include physical attackers at the machine. So those uh increasingly common account protections failures and the grandmother is successfully able to push code into the repository which may go undetected. An innocuous change like adding an additional third-party dependency. Whether dependency includes any malicious activity could go undetected for some time, but again it doesn't have to be that way starts starter level.

A

4 requires code review by two strongly authenticated users, which significantly raises the cost to an attacker.

A

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 um which a reviewer is inclined to accept, along with some kind of difficult to detect malicious change kind of embedded in it.

A

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 review of following up with the author, so the change has to be a fairly obvious change and they also need to cover their tracks.

A

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 called.

A

And to wrap up I'm going to hand back over to tom.

B

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 1. within salsa, adopting lower levels is expected to be easy, while getting to higher levels is probably hard. The journey starts. It's also level one now 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 it sets up infrastructure for creating communicating and using provenance, and it highlights opportunities for improvement within your supply chain.

B

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, for example, the providence produced at level one isn't signed, so an attacker could easily tamper with it now 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.

B

uh Some of the things that we're currently working on include how to communicate trust in the build and source control systems, libraries in various languages, to create salsa and to stations policy engines to evaluate those attestations and fine-tuning level requirements and we'd love your help to make salsa a a reality.

B

uh Some concrete steps that you can take platform dubs platform devs. You can produce salsa providence project devs. You can automate your builds and use platforms that produce salsa profits, users. You can ask for and use salsa provenance for your dependencies and everyone. Please provide feedback on what works and doesn't.

B

Thank you for your time.