As software supply chain attacks emerge as a point of concern in the wake of SolarWinds and Codecov security incidents, Google is proposing a solution to ensure the integrity of software packages and prevent unauthorized modifications.
Called “Supply chain Levels for Software Artifacts” (SLSA, and pronounced “salsa”), the end-to-end framework aims to secure the software development and deployment pipeline — i.e., the source ➞ build ➞ publish workflow — and mitigate threats that arise out of tampering with the source code, the build platform, and the artifact repository at every link in the chain.
Google said SLSA is inspired by the company’s own internal enforcement mechanism called Binary Authorization for Borg, a set of auditing tools that verifies code provenance and implements code identity to ascertain that the deployed production software is properly reviewed and authorized.
“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.”
The SLSA framework promises end-to-end software supply chain integrity and is designed to be both incremental and actionable. It comprises four different levels of progressive software security sophistication, with SLSA 4 offering a high degree of confidence that the software has not been improperly tinkered.
- SLSA 1 — Requires that the build process be fully scripted/automated and generate provenance
- SLSA 2 — Requires using version control and a hosted build service that generates authenticated provenance
- SLSA 3 — Requires that the source and build platforms meet specific standards to guarantee the auditability of the source and the integrity of the provenance
- SLSA 4 — Requires a two-person review of all changes and a hermetic, reproducible build process
“Higher SLSA levels require stronger security controls for the build platform, making it more difficult to compromise and gain persistence,” Lewandowski and Lodato noted.
While SLA 4 represents the ideal end state, the lower levels provide incremental integrity guarantees, at the same time making it difficult for malicious actors to stay concealed in a breached developer environment for extended periods of time.
Along with the announcement, Google has shared additional details about the Source and Build requirements that need to be satisfied, and is also calling on the industry to standardize the system and define a threat model that details specific threats SLSA hopes to address in the long term.
“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.