Introduction
In an increasingly digital world, software has become an integral part of almost everything. Consequently, as software systems grow in complexity and interconnectedness, so do potential risks. Even the systems where we build software, often referred to as the “software supply chain”, are no exception, often as–if not more–complex and at risk than the software produced. Therefore, ensuring the security of the software supply chain has become a critical concern for organizations worldwide. Enter SLSA, Supply-chain Levels for Software Artifacts, a framework designed to enhance the security and trustworthiness of the software supply chain. In this blog, we will take a look at SLSA, its importance, and how it can help safeguard your software.
The FRSCA Blog Series
This blog is the first in our FRSCA Blog Series, designed to cover not only the SLSA specification but also the Factory for Repeatable Secure Creation of Artifacts (FRSCA), a prototype implementation of the SLSA specification. For more on the implementation, see our next blog post on FRSCA.
The Need for Secure Software Supply Chains
Software supply chains are complex networks of people, processes, and technologies responsible for creating, distributing, and updating software. These supply chains can be vulnerable to various threats, including malicious actors attempting to compromise software, inject malware, or steal sensitive data. The SolarWinds breach in 2020 and the Codecov breach in 2021 are stark reminders of the potential consequences of supply chain attacks.
The Supply Chain Security Checklist
To address these challenges, the software industry has been increasingly focused on implementing robust security measures throughout the software development and distribution lifecycle. SLSA emerges as a pivotal player in this effort.
What is SLSA
SLSA, which stands for Supply-chain Levels for Software Artifacts, is designed to enhance the security and integrity of software supply chains. It provides a standardized way to assess and communicate the trustworthiness of software artifacts as they traverse the supply chain. The original SLSA proposal consisted of four levels, each with specific requirements and best practices. As this approach met the rigors of real-world requirements in an array of diverse organizations, a new approach was required.
In SLSA v1.0, rather than trying to solve all supply chain risks in a single progression, supply chain concerns are divided into tracks. Currently, the only track defined is the “Build” track, defining 3 levels of security for automated builds, along with a 0 level, representing an entry point with no requirements:
L0 (no requirements)
L1 – Mistakes/documentation
Requires provenance, showing how the package was built
L2 – Tampering after the build
Requires signed provenance, generated by a hosted build platform
L3 – Tampering during the build
Requires a hardened build platform
A “Source” track is contemplated for the future, to augment the above Build track. As new tracks are introduced, each will be free to define its own levels and organizations may progress to higher levels in each track independently based on their needs and priorities.
Why SLSA Matters
In collaboration with the OpenSSF, Google introduced SLSA in June of 2021, based on its internal Binary Authorization for Borg (BAB) security process. BAB was designed to protect Google’s Software Supply Chain from insider risk and evolved over the course of more than eight years, ultimately becoming a mandatory feature of all Google production workloads. Two years later, in April of 2023, the OpenSSF released version SLSA 1.0.
SLSA is a significant step forward in ensuring the security of software supply chains, supporting five key features:
Risk Mitigation: By implementing SLSA, organizations can significantly reduce the risk of supply chain attacks, data breaches, and the introduction of malicious code into their software.
Transparency: SLSA enhances transparency in the supply chain by requiring detailed provenance information and cryptographic signatures, making it easier to trace the origin and authenticity of software artifacts.
Compliance: As security and privacy regulations become more stringent, SLSA can help organizations demonstrate compliance by showcasing their commitment to secure software development practices.
Trustworthiness: SLSA provides a clear mechanism for assessing the trustworthiness of software artifacts, enabling consumers to make informed decisions about the software they use.
Industry Standardization: As more organizations adopt SLSA, it has the potential to become an industry standard, ensuring consistent security practices across the software ecosystem.
Implementing SLSA in Your Organization
Adopting SLSA may require significant changes to your organization’s software development and distribution processes. The road to SLSA maturity includes several key steps:
Assessment: Evaluate your current software supply chain processes and identify areas that need improvement in terms of security and trustworthiness.
Education: Ensure that your development and operations teams become familiar with SLSA principles and best practices.
Tooling: Invest in tools and technologies that support the implementation of SLSA, such as secure build systems and artifact management solutions.
Pilot Projects: Start with small pilot projects to test SLSA implementation before scaling it to your entire software ecosystem.
Continuous Improvement: Regularly review and update your SLSA implementation to adapt to evolving threats and technologies.
Conclusion
In an era where software is at the heart of everything we do, securing the software supply chain is paramount. SLSA, with its standardized framework and levels, offers a roadmap to achieving greater security and trustworthiness in software artifacts, in a critically important shared and open setting. By embracing SLSA, organizations can mitigate supply chain risks, enhance transparency, and grow the network of organizations building a more secure digital future.
Given SLSA is likely to play an increasingly important role in ensuring the integrity and security of software supply chains, you may be wondering where you can find some example solutions to inspect and experiment with. Fortunately, the FRSCA projects seek to provide just such a prototype. In the coming installments of this blog series, we will introduce FRSCA and walk you through the installation and operation of each of its evolving components. Check back or subscribe to read more.
Up Next
Check out Randy Abernethey’s interview with Ebenezer Don, the Founder of NewDev.io about SLSA here.
Check out the next blog in the FRSCA blog series here.
References
https://slsa.dev/
https://github.com/buildsec/frsca
https://cloud.google.com/docs/security/binary-authorization-for-borg
https://openssf.org/