“What is SLSA?” followed closely by “What does SLSA do for me?” are the two most common questions I get when people learn about SLSA. This has led to a lot of confusion as to how folks apply SLSA, and the benefits they get. You can’t just apply SLSA practices to a pipeline that runs a build, generate a SLSA attestation and magically be protected from supply chain compromise. Contrary to a lot of the hype being thrown around, SLSA is no free lunch, and we must help protect our lunch!
Source: twitter
Pummeling that analogy into the ground, SLSA isn’t even a meal, it’s a condiment. SLSA isn’t something that replaces your existing security standards and procedures. You don’t replace your static application security testing (SAST) scans or software composition analysis (SCA) with SLSA, nor do you replace your existing security controls, e.g. NIST 800-53 or CSA Cloud Controls Matrix, with SLSA based ones. If your build pipeline is the meal, SLSA is what gets poured over, to complete it.
There is no intention here to minimize the utility or importance of SLSA. SLSA has been a key framework missing from the package building process. A SAST scan might help tell you that a particular artifact is free of known vulnerabilities and a SCA might generate a software bill of materials (SBOM), however it is often difficult to determine that a particular SAST scan and SBOM refer to the same artifact. It is also difficult and sometimes impossible to know that a scan report or SBOM were generated by approved tools on approved infrastructure. You lack the provenance metadata you need to help provide confidence that your software build pipeline took some code from an approved source, transformed it into a packaged artifact and published it in approved storage along with any functional or non-functional (e.g. security) testing in between.
Provenance, one of the critical SLSA requirements, has been a key missing piece to the supply chain puzzle. SLSA through the provenance predicate format, along with its parent attestation format in-toto, solves this challenge through a few main features. These attestations generated across your build pipeline helps provide you with a story of how your software went from code to artifact and any other checks either in the pipeline or part of the broader software delivery lifecycle. This in addition to the SLSA requirements themselves help generate confidence around your provenance. It doesn’t prevent supply chain attacks on its own, but helps you ensure that your artifact has gone through all the right steps as well as make it possible to know that when something does go wrong you know where in your pipeline.
The first feature is the in-toto subject. The subject is just a reference along with its hash to the output(s) from some process that generates an artifact. This means whatever is generating the SLSA attestation is asserting that the output of that step was a particular name and a hash. In most writing and discussion about SLSA thus far the subject has referred to the software package you are building, however there is nothing to prevent this artifact from being anything else like a SBOM or a SAST scan report. When going back and validating or auditing the attestation you can know that a particular SBOM has a valid SLSA attestation referring to it and look at additional metadata as needed.
This brings us to the second feature that helps generate provenance, materials. materials are the input(s) used by a build step. It is similar to subject but uses a URI instead of just a name. The URI + hash allows consumers of the SLSA attestation to validate that a particular set of materials are what were expected to be inputs of a step. It also allows users to validate that the same materials with the same hash are used in different pipeline steps. For example if you are building an SBOM based on some source code, you want to check its SLSA attestation materials with the software package build attestation materials. If they don’t line up you know you generated an SBOM against different code than what led to the packaged artifact. A similar approach would be taken for a binary scan. If its SLSA attestation materials don’t line up with the software package build attestation subject then you know you have scanned a different binary than you intended.
A third key feature is the build related fields, in particular buildType, builder.id and invocation. These fields allow you to determine how a subject in your SLSA attestation is built. This lets you create policy around approved builders and invocations so if you see artifacts being built with unapproved tools or using unapproved inputs you know something has gone wrong. It also helps with auditing. For example if you know that a particular scanning tool had a bug and all reports generated by that version need to be rerun you can go back and check your attestations and determine which software materials need to be rescanned.
After reading the above sections on SLSA attestations, you might be asking yourself, “what if someone or something generates fraudulent attestations?” This is where the SLSA requirements themselves come in. In particular “Provenance - Authenticated,” which is under SLSA 2. The authenticated requirement means your attestations should be signed. Obviously keys can get stolen, identity credentials can be stolen, etc. however any sort of signing is a start.
The other requirements under Provenance like “Service Generated” and “Non-falsifiable” help as well. Service Generated essentially means that the data in the provenance should be generated by the build service itself as opposed to output by what is running inside the user defined build step. This is important because a build is potentially running arbitrary code and has an unbounded state space. The build service which is orchestrating the build is quite limited in scope and not running unbounded user defined builds. Most build systems today require some modification and custom configuration to support this requirement.
The “Non-falsifiable” requirement is a bit more complicated and as of writing a point of contention and confusion. It contains three sub-requirements in addition to what is defined for Service Generated. The requirements boil down to:
- Keep your signing secrets secured, safe, and only accessible to the build service itself. Use zero-trust practices for storing your signing secrets like using hardware to encrypt or store secrets, secrets based on identities, short lived secrets, etc.
- Your signing secrets should only be available to the build service and never be available to the build environment itself, e.g. infrastructure or container. This is applying the Service Generated requirement to the secrets in addition to the provenance itself.
- The provenance generated must be verified by the build service or the control plane that the builds are orchestrated through. This means that the builds themselves must be validated in some way by the build service. This is often handled through short lived identities that are granted only for lifetime of the build or even shorter based on the running workload, e.g. SPIFFE. This identity which is generated to run a specific workload once can be used to validate that the provenance generated maps back to the exact workload.
These things combined make it difficult for any individual step’s part of the provenance to be fraudulent.
Your next question after this might be now that you’re following the SLSA requirements and generating SLSA attestations, how do I know the tools like my build service that are generating my SLSA attestations are good? How do I know the control plane I’m running my build service in is good? How deep does the problem go? The short answer to that is it’s a recursive problem that can never practically be solved completely, however we can make it better iteratively by working to follow good secure build practices and providing provenance for it against our dependencies ad infinitum until we have an excellent picture from host OS to user service. Once the picture is good enough we can plug most of the holes with other controls. How we get there is an article for another time.
By following the SLSA requirements and generating SLSA attestations, it can help build a picture of what steps led to the generation of any artifact whether it is software or just some generated metadata, e.g. SBOM, about that software. It can also help build the more holistic picture of all the steps and artifacts taken in the secure generation of some end user software, i.e. provenance attestations showing downloading of source to ingestion of dependencies, scanning of source code, building of software, scanning of artifacts and publishing of the packaged artifacts.
You can use these attestations to help answer the question, “Do I trust that these build steps took in a set of inputs that led to these outputs?” If you answer yes then it helps answer the other key question “Now that I trust that the outputs came from these inputs do the outputs tell the story of a software package that doesn’t have a supply chain compromise with some confidence?”
To summarize, SLSA helps provide confidence that a set of inputs, e.g. source code, libraries, software packages, led to a set of outputs, e.g. software packages, scan reports, SBOMs. In other words it helps you trust the part of the supply chain you directly control, e.g. source code. The increased confidence in scan reports and SBOMs then helps provide confidence in your build process catching any upstream supply chain attack. In other words this helps you trust the part of the supply chain you don’t control, e.g. upstream dependencies.
Many of the challenges facing us in the supply chain space today would be easier to solve if we by and large adopted SLSA. The practices layered on top of other security practices help bridge the gaps. The interoperability that SLSA attestations bring would help producers of software better assert as to what they are providing to their consumers, and to the consumers of software it helps them make informed decisions based on who and what they trust.