A relatively new way of strengthening your software supply chain security is to apply Supply Chain Levels for Software Artifacts (SLSA) in tandem with other tools such as software bills of materials (SBOMs), software composition analysis (SCA) for open source, and static application security testing (SAST) for proprietary code. Let’s take a look at what SLSA is and how its different levels work.
Supply Chain Levels for Software Artifacts (SLSA) is a security framework, a specification, and a common language designed to describe and improve software supply chain security. When deployed, it automates decisions about the integrity of the artifacts you are using and evaluates the trustworthiness and security of source code used in software packages.
Released in June 2021, SLSA is a cross-industry collaboration, maintained as part of the Open Source Security Foundation (Open SSF). It is based on a framework inspired by Google’s “Binary Authorization for Borg,” which has been used by Google for nearly a decade and is required for all of its production workloads. Representatives from other companies such as Intel, VMware, and Datadog collaborate with colleagues at Google to develop and maintain SLSA.
SLSA’s design is based on automatically creating verifiable metadata, which helps implement security by getting the data needed to justify your policy decisions. It is organized into a series of levels that describe increasing security guarantees. We’ll look at these levels a little further on.
SLSA is necessary because the number of attacks against the software supply chain continues to escalate, and the gravity of those attacks is worsening. Hence, the need to safeguard the integrity of your source code, strengthen security, and avoid future breaches.
SLSA meets this particular need by providing a clear, consensus-based industry standard of compliance requirements and protection measures. As such, it’s a significant element of software supply chain security strategy, when working alongside other security tools and practices.
SLSA delineates four key tracks and levels of software supply chain security, each of which provides increasingly strict and hardened security benchmarks and guarantees. To effectively implement SLSA, it is important to understand and address the security considerations at each level:
Level 1: Source code build process documentation
Users start by identifying the provenance of the sources and dependencies of code in use and documenting the processes for building artifacts. Doing so provides a list of what is in the code, enabling users to better assess security risks and make security decisions. This information helps teams conduct code reviews, implement version control systems, track changes, and mitigate the risk of unauthorized modifications.
Level 2: Protection against tampering using a hosted build service
This level ensures that the build process is tamper resistant. It involves version control and the use of a hosted build service that creates “authenticated provenance.”
Using a version control service like GitHub or GitLab to track, manage, and record changes to code builds a clear understanding of how an artifact was built and how it has changed. Using a hosted build service provides independent, third-party documentation of code provenance. This is more thorough than Level 1 because it verifies the build process and confirms the provenance by supplying an attestation to confirm adherence to the SLSA requirements.
An attestation is metadata that describes the artifact’s name, what it is, how it was produced, who produced it and generated the attestation, the event that started the build, and execution information that includes a record of the steps that were executed during the build. It also lists artifacts that were used as input.
This information is published alongside the associated software so that anyone who wants to use the artifacts can automatically verify them. Producing unsigned provenance satisfies Level 1 criteria because it offers basic code source identification and can aid in vulnerability management. However, you need verification and a cryptographic signature if you want to protect yourself from tampering and reach Level 2.
For example, if attackers try to get users to download a malicious package or a contaminated update, Level 2 involves a controller component that checks policy. This requires verification of provenance signed by the builder before the package can run. Attackers can’t fake provenance with stolen container registry credentials, so the controller blocks the use of the package and the attack is prevented.
Level 3: Hardening builds with extra protection
Implementing Level 3 means that a package has a verified source and build. It prevents tampering during the build and significantly reduces the impact of compromised package upload credentials by requiring attackers to perform a difficult exploit of the build process. It offers stronger protections than levels 1 and 2 by preventing specific classes of threats, such as cross-build contamination.
Level 3 applies more stringent standards that ensure provenance integrity and that the source can be audited.These standards include:
Level 4: Two-person review for the highest level of trust
This level requires two people to review all changes. The build process must be secure (hermetic) to guarantee that the list of dependencies is complete. Ideally, the process should also be reproducible because this attribute provides many auditability and reliability benefits, although it isn’t mandatory. This combination provides the highest level of trust and confidence.
Securing the software supply chain is vital. Organizations should employ secure build practices, such as using trusted build servers, verifying the integrity of source code and dependencies, and employing code signing to guarantee the authenticity and integrity of the resulting artifacts. Implementing the levels of SLS provides a thorough framework to address security considerations and should form part of a suite of software and application security best practices.
These best practices should include secure coding, dependency management, enforcing secure build processes, software composition analysis (SCA) for open source, static application security testing (SAST) for proprietary code, and ensuring secure distribution and delivery. By combining these tools and processes with SLSA, organizations can significantly enhance the security and integrity of their software systems. Proactive measures at each level help mitigate risks, safeguard against vulnerabilities, and ensure the trustworthiness of software artifacts throughout the software supply chain.
The software supply chain is the network of software components and dependencies used in the creation, maintenance, and delivery of software and applications.
Software artifacts are items that are produced and used in the development process when creating a software product or application, such as a data model, a prototype, a workflow diagram, a design document, or a setup script. Software artifacts help developers retrace their steps when creating a software product, therefore serving as a guide that outlines the software development process.
Insecure software artifacts can cause vulnerabilities that attackers can use to infiltrate your code, software, and applications. They can also enable attackers to introduce malicious packages into your code which could disrupt or disable your software, steal data, and cause significant reputational and financial damage.
Apply dependency management best practices by using a combination of tools and processes that together will ensure comprehensive visibility and security. These should include secure coding, secure build processes, SCA for open source, SAST for proprietary code, SLSA for software supply chain security, and secure distribution and delivery.