Google has proposed a solution to the growing concern related to the rising attack on the supply chain integrity with unauthorized modification to software packages in the past two years. These malicious threats are proving to be common and affecting all consumer software with reliable attack vectors. The recent security incidents of SolarWinds and Codecov appeared as the face of an eye-opening breach that resulted in a multi-billion dollar attack, which according to Google, could be averted had the proposed framework been adopted by software developers and consumers.
“The software development and deployment supply chain is quite complicated, with numerous threats along the source ➞ build ➞ publish workflow. While point solutions do exist for some specific vulnerabilities, there is no comprehensive end-to-end framework that both defines how to mitigate threats across the software supply chain and provides reasonable security guarantees,” said Google.
Introducing the solution through a blog post, the tech giant stated, “our proposed solution is Supply chain Levels for Software Artifacts (SLSA, pronounced “salsa”), an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain.”
The SLSA is said to be inspired by Google’s internal, “Binary Authorization for Borg”, which is mandatorily used for all of Google’s production workloads. SLSA is aimed at improving the open-source state of the industry to defend against the most pressing integrity threats. It can help consumers to make an informed choice about the security posture of the software. It helps to protect against common supply chain attacks.
What is SLSA
“In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus,” said Kim Lewandowski of Google Open Source Security Team and Mark Lodato of the Binary Authorization for Borg Team.
“In its final form, SLSA will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give “SLSA certification” to a particular package or build platform. SLSA is designed to be incremental and actionable, and to provide security benefits at every step.”
The SLSA is designed with four levels, where SLSA 4 represents the ideal end state. The incremental milestones with corresponding incremental integrity guarantees, are represented in the lower levels. When an artefact will qualify the highest level in the design of SLSA, consumers will be more confident about its safety and can be able to securely trace it back to the source- a difficult but not impossible in most software today.
Kim Lewandowski of Google Open Source Security Team and Mark Lodato of the Binary Authorization for Borg Team in their blog post have mentioned each level of SLSA design with its requirements. The design levels as per the team are defined as follows.
SLSA 1: The first level requires a fully scripted/automated build process be generating provenance. Provenance is metadata about how an artifact was built, including the build process, top-level source, and dependencies.
It let the software consumers make risk-based security decisions although. At SLSA 1 provenance does not protect against tampering, but it offers a basic level of code source identification and may aid in vulnerability management.
SLSA 2: At this level, it requires generating authenticated provenance using version control and a hosted build service. It makes the consumer a little more confident in the origin of the software. Unlike SLSA 1, at this level, provenance will prevent tampering to the extent that the build service is trusted. SLSA 2 also provides an easy upgrade path to SLSA 3.
SLSA 3: Further moving to level 3, the requirement advances as the source and build platforms meet specific standards to guarantee the auditability of the source, and the integrity of the provenance, respectively. “We envision an accreditation process whereby auditors certify that platforms meet the requirements, which consumers can then rely on.”
SLSA 3 is said to prevent specific classes of threats, such as cross-build contamination, to provide much stronger protections against tampering than earlier levels.
SLSA 4: This is the end state and currently the highest level in SLSA design. It requires a two-person review of all changes and a hermetic, reproducible build process. A two-person review is known as an industry best practice, to catch any mistakes and deterring bad behaviour. Whereas hermetic builds guarantee that the provenance’s list of dependencies is complete. Although reproducible builds are not strictly required, they may provide many auditability and reliability benefits.
Thus, SLSA 4 offers the consumer a high degree of confidence indicating the software has not been tampered with.
“Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence,” Lewandowski and Lodato noted.
The company is planning to work with popular source, build, and packaging platforms to make reaching higher levels of SLSA an easier process. They are looking forward to automatically generate provenance in build systems, propagating it natively in package repositories, and adding security features across the major platforms. The company’s long-term goal is to raise the security bar across the industry, making the higher-level SLSA security standards the default expectation, minimising the effort on the part of software producers.
Google claims SLSA to be a practical framework for end-to-end software supply chain integrity ensuring its security. The SLSA solution is based on a model proven to work at scale in one of the world’s largest software engineering organizations.
“Achieving the highest level of SLSA for most projects may be difficult, but incremental improvements recognized by lower SLSA levels will already go a long way toward improving the security of the open-source ecosystem,” the company said.
“We look forward to working with the community on refining the levels as we begin adopting SLSA for our own open-source projects. If you are a project maintainer and interested in trying to adopt and provide feedback on SLSA, please reach out or come join the discussions taking place in the OpenSSF Digital Identity Attestation Working Group,” concluded Google in the blog post.