The integrity of software supply chains has become a major talking point in recent years, with attacks on software supply chains becoming more frequent in the last two years. It has become imperative for developers to carefully choose external software and products to include in their software systems while also putting measures in place to ensure the integrity of their software artifacts.
The process of building and deploying software is quite complicated, with many potential points of vulnerabilities across the chain. Instead of relying on specific fixes for each vulnerability, it makes more sense for developers to adopt a more comprehensive end-to-end framework that can help mitigate threats during the development phase.
One such framework is the Supply chain Levels for Software Artifacts (SLSA). This framework is a comprehensive checklist of security controls and standards that ensure the integrity of software packages and infrastructure.
The newly introduced SLSA security framework is a product of a collaboration between OpenSSF, Google, and other cybersecurity stakeholders. It serves as an agreed-upon industry standard that can be adopted by developers, businesses, and enterprises to help them make informed choices about the security of the software they’re building or consuming and secure the entire software development lifecycle.
How SLSA Helps Defend Against Software Supply Chain Attacks
More than a set of rules, the SLSA security framework is a standard framework that can potentially strengthen the integrity of the components of a software artifact. This end-to-end guideline acts as a set of defensive measures that incrementally prevents tampering or any type of unauthorized modification to the software packages that make up a software product. Adopting the SLSA framework can help protect your software against common supply chain attacks such as the following:
PHP’S Malicious Commit Repository Attacks
In March 2021, Nikita Popov announced that malicious actors attempted to attack PHP’s source code by creating a backdoor that would allow them to get unauthorized access to the code platform. If successful, the attack would have been devastating, since PHP powers about 80% of websites on the internet. Fortunately, the attack was caught on time—but this incident still illustrates how SLSA controls can help prevent attacks like this in the future. Following SLSA protocols such as a two-person review and two-factor authentication would have protected the source code platform and made it a much more difficult target for attackers.
Apple’s Malicious Compiler Breach
In 2015, software developers building apps for Apple products downloaded a version of Xcode (a code-writing tool for Apple devices) from an unverified hosting platform. The version of Xcode known as XcodeGhost had been infected with malicious code which was covertly carried over to apps built with it. It created a backdoor to several apps that evaded Apple’s code review process and the apps offered on the app store. The SLSA framework contains build-related security protocols that would have prevented an attack like this or made it more difficult. One such measure is the hermetic build requirement which would have forced developers to declare all their sources including the built tool they used.
Uploaded Malicious Artifacts
On April 1, 2021, the Codecov team uncovered attacks affecting its Bash Uploaders, which included Codecov GitHub Action, The Codecov CircleCI Orb, and the Codecov Bitrise Step. The attacker gained unauthorized access by extracting an HMAC key that provided access to the Google Cloud Storage service account of an intermediate layer of one of Codecov’s public Self-Hosted Docker images. This key allowed them to modify the Bash Uploader to upload malicious codes directly to end users. The SLSA framework would have caught this action by showing when artifacts are built in a manner different from the expected form in their source repository.
Event-stream bad dependency
In 2018, hackers published a malicious package flatmap-stream to npm and this was later added as a dependency to the platform’s widely used event-stream package. After adding the dependency, the attackers updated it with malicious behavior. Since the update did not match the code submitted to GitHub, the SLSA framework would have caught the attack and prevented the vector. Tracking the provenance of the malicious code would have revealed that it did not come from GitHub or from the proper builder. Either way, the attack could have been prevented.
The Four Security Levels of the SLSA Cybersecurity Framework
The SLSA framework is an incremental and actionable protocol. It consists of four levels, with Level 4 representing the ideal end state of a secured system. Artifacts at the highest level fulfill all the requirements to gain consumer confidence that it has not been tampered with in any way and that all their components can be traced back to their sources. Artifacts at the lower levels are ones that have also achieved incremental milestones with specific integrity guarantees depending on their rank.
Level 1—laying the foundation
You can consider Level 1 of the SLSA framework as a sort of foundation for the entire framework to create secure software. At this stage, developers or organizations adopting the SLSA have to do two things. First, they have to fully automate their build process. This can be done in different ways, but the conventional way to automate builds is by using a makefile. GitHub Actions can also be used to achieve the same results.
The second part of achieving SLSA Level 1 is to generate full provenance documentation. This is metadata that shows how a software artifact was built. It should detail the entire build process, all the dependencies, and top-level sources used in building it.
Scripting the build process and showing the provenance of a software artifact in this manner makes it easier for consumers to make informed decisions about using a software product. Although having SLSA 1 verification does not mean the software is fully protected against tampering, it makes it easier to identify the components of the software. This is the first stage in managing vulnerabilities.
Level 2—Make sure your build process is tamper-resistant
Level 2 of the SLSA framework is where you start putting measures in place to ensure your build process is as tamper-resistant as can be. Achieving Level 2 of the SLSA framework also gives the consumer more confidence about the origin of the software.
Again, this is done in two steps, the first being using version control and the second involving using a hosted build service to authenticate provenance. For the first step, GitHub, GitLab, or any other similar service is used to store the code and record any changes made to it. Tracking any version changes this way makes it easier to understand any alterations performed on the artifact in the process of building it.
Although Level 2 requires provenance documentation just like Level 1, the difference here is that the software artifact has to be authenticated by a hosted build service. The hosted service serves as a trusted third party that can confirm that the build process detailed in the initial provenance document is accurate. GitHub Actions is a type of hosting service that can provide authenticated provenance.
Level 3—SLSA’s security controls
Level 3 is where you start implementing the specific security control as highlighted in the SLSA framework. To achieve this level, the source and build platforms for your software artifacts must meet specific standards that guarantee that the source is auditable and the provenance of the code can be trusted. SLSA Level 3 provides a much stronger guarantee that the artifact is well protected against tampering and specific classes of threats.
Some of the specific requirements of Level 3 include:
- Source code verified history and retention—A source code verified history ensures that any change made to the software source code is accompanied by an authenticated identity of the author, reviewer, or uploader that made the change with specific timestamps of the change. This change history must also be stored for at least 18 months.
- Isolated builds in ephemeral environments—To fulfill this requirement, the software builds must be implemented in ephemeral environments where they’re completely independent of any other build instances. You can use a service like GitHub Actions, which uses a virtual build machine to produce your build on demand, to achieve this..
- Builds as code—These criteria require you to treat your build files like code. This means they are to be stored in a version control system that makes it possible to recreate build processes when necessary.
- Non-falsifiable provenance—The purpose of this requirement is to prevent users from tampering with the provenance documentation generated by the build service.
Level 4—Consumer confidence
Level 4 of the SLSA framework is intended to ensure the software has not been tampered with in any way. Only software artifacts that have fulfilled the following requirements can achieve Level 4 of the framework:
Two-person review of all changes
This criterion requires organizations to assign two qualified reviewers to thoroughly review any proposed changes to the software code and components. This two-person review process ensures that only trusted and authenticated developers can make changes to software artifacts.
A hermetic and reproducible build process
A build process is said to be hermetic when all inputs are specified upfront and outside the build process. This rule applies to the source code as well as all the compilers, libraries, and tools used in the build. This helps to guarantee the integrity of all third-party imports. The reproducible build criteria are not a compulsory requirement, but are also recommended. The criteria require the build process to produce the same output regardless of where or when it’s run.
Technical Requirements to Meet the SLSA Levels
The SLSA framework has specific technical requirements for the different levels. These requirements are classified into five main categories: source requirements, build process requirements, common requirements, provenance content requirements, and provenance generation requirements. Each of these requirement categories is highlighted below.
Source Requirements
This refers to requirements that are meant to ensure the integrity of your source code. Following these sets of protocols prevents tampering and malicious changes to your code. It also ensures that any nefarious actions don’t go unnoticed. The source requirements are laid down in the table below.
| Source Requirements | Description | SLSA Level |
| Version control | All changes to the source code should be tracked. | 2 |
| Verified history | Comprehensive history detailing the “who,” “what” and “when” of every version revision should be recorded. | 3 |
| Retained indefinitely | All version changes and history information should be stored indefinitely and must not be deleted. | 4 |
| Two-person reviewed | Two trusted and highly authenticated people must authorize any version change. | 4 |
Build Requirements
The SLSA framework highlights build requirements meant to improve the safety of the build platform and maintain the integrity of the build process.
| Build Requirements | Description | SLSA Level |
| Scripted build | All the steps of the build process should be fully automated. | 1 |
| Build service | All the steps of the build process must run on a dedicated build service. | 2 |
| Ephemeral & isolated environment | The build process must run in an ephemeral environment provided specifically for the build. The steps must also run in an isolated environment free from other build instances.
|
3 |
| Parameterless & hermetic | The build process should rely entirely on the build script instead of user parameters. All the transitive build steps should be hermetic, meaning all sources and dependencies should be fully declared upfront and outside the build process. | 4 |
Provenance Generation Requirements
These requirements are meant to verify the source of all the components of a software asset. The provenance generation requirement are highlighted in the table below.
| Provenance Generation Requirements | Description | SLSA Level |
| Available | The consumer should have access to the provenance information in an acceptable format. | 1 |
| Verifiable | The consumer should be able to verify the authenticity of the provenance information provided. | 1 |
| Service-generated | All the provenance information must be generated by the build service.
|
2 |
| Non-falsifiable | Users cannot falsify provenance data. | 3 |
| Complete dependencies | The provenance data should include all dependencies used during the build steps. | 4 |
Provenance Content Requirements
The provenance content requirements verify the identity and source of all the artifacts, dependencies, and build restrictions that were used in the build process. They’re highlighted in the table below.
| Provenance Content Requirements | Description | SLSA Level |
| Identifies artifact, builder, source and entry point. | ● Identifies the output artifact
● Identifies the build entity ● Identifies the source via an immutable reference ● Identifies the command that invoked the build script |
1 |
| Includes all build parameters | All the build parameters should be identified.
|
3 |
| Includes transitive dependencies & reproducible info | ● Includes all transitive dependencies
● If build is reproducible, all the information necessary to reproduce it must be provided
|
4 |
| Includes metadata | All meta-data should be included to aid investigations. | 0 |
Common Requirements
The common requirements apply to software artifacts on SLSA’s Level 4. Every trusted artifact is expected to meet these requirements. They include baseline security requirements and logs that detail all physical and remote access. The common requirements also stipulates a small number of platform admins that can override the stipulations in the SLSA documentation.