Google Releases New Framework to Prevent Software Supply Chain Attacks

As software supply chain attacks emerge as a point of concern in
the wake of SolarWinds^[1]
and Codecov^[2]
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^[3]
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^[4], 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^[5]
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^[6]
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^[7]
and Build^[8]
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.