Google wants to bring “salsa” to drive enforcement at the software supply chain security party.
The U.S. tech giant this week unveiled SLSA (Supply chain Levels for Software Artifacts), a new end-to-end framework the company hopes will drive the enforcement of standards and guidelines to ensuring the integrity of software artifacts throughout the software supply chain.
The framework, released as part of the OpenSSF Foundation, is essentially a set of security guidelines being established by industry consensus but the long-term play is for SLSA to 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. Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source—something that is difficult, if not impossible, to do with most software today,” Google explained in a statement.
“The goal of SLSA is to improve the state of the industry, particularly open source, to defend against the most pressing integrity threats. With SLSA, consumers can make informed choices about the security posture of the software they consume.”
[ READ: New Code Execution Flaws In Solarwinds Orion Platform ]
The company said the SLSA framework was inspired by its mandatory internal “Binary Authorization for Borg” enforcement checker that ensures production software is properly reviewed and authorized, especially if the code has access to user data.
Binary For Borg has been in use at Google for the past eight years and is mandatory for all of Google’s production workloads.
The long-term goal is for SLSA to 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. “Once an artifact qualifies at the highest level, consumers can have confidence that it has not been tampered with and can be securely traced back to source — something that is difficult, if not impossible, to do with most software today,” the company said.
[ ON DEMAND: Sessions From SecurityWeek’s 2021 Supply Chain Security Summit ]
The company said the framework consists of four levels — SLSA 1-4 — with incremental milestones corresponding with incremental integrity guarantees.
For example, the SLSA 1 requirement calls for the build process to be fully scripted/automated and generate provenance (metadata about how an artifact was built, including the build process, top-level source, and dependencies); while SLSA 2 would require using version control and a hosted build service that generates authenticated provenance.
At the higher levels, SLSA 3 would require the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance; and the SLSA 4 would mandate two-person review of all changes and a hermetic, reproducible build process.
“Two-person review is an industry best practice for catching mistakes and deterring bad behavior,” Google said.
The proposed framework, available here on GitHub, currently consists of an attempt to find consensus on the definition of a “secure” software supply chain; an accreditation process for organizations to certify compliance with adopted standards; and technical controls to record provenance and detect or prevent non-compliance.
“A minimum, SLSA can be used as a set of guiding principles for software producers and consumers. More importantly, SLSA allows us to talk about supply chain risks and mitigations in a common language. This allows us to communicate and act on those risks across organizational boundaries,” Google argued.
Related: Codecov Dev Tool Compromised in Supply Chain Hack
Related: Remote Hacker Caught Poisoning Florida City Water Supply
