Open-source security: Google has a new plan to stop software supply chain attacks
To tackle the growing threat of attacks on the software supply chain, Google has proposed the Supply chain Levels for Software Artifacts framework, or SLSA which is pronounced “salsa”.
Sophisticated attackers have figured out that the software supply chain is the soft underbelly of the software industry. Beyond the game-changing SolarWinds hack, Google points to the recent Codecov supply chain attack, which stung cybersecurity firm Rapid7 via a tainted Bash uploader.
While supply chain attacks aren’t new, Google notes they’ve escalated in the past year, and has shifted the focus from exploits for known or zero-day software vulnerabilities.
SEE: Network security policy (TechRepublic Premium)
Google describes SLSA as “an end-to-end framework for ensuring the integrity of software artifacts throughout the software supply chain.”
It takes its lead from Google’s internal “Binary Authorization for Borg” (BAB) – a process Google has been using for more than eight years to verify code provenance and implement code identity.
The goal of BAB is to reduce insider risk by ensuring that production software deployed at Google is properly reviewed, especially if the code has access user data, Google notes in a white paper.
“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,” said Kim Lewandowski of Google’s open-source security team and Mark Lodato, from the BAB Team.
SLSA looks to lockdown everything in the software build chain, from the developer to source code, the build platform and CI/CD systems, the package repository, and dependencies.
Dependencies are a major weak point for open-source software projects. In February, Google proposed new protocols for critical open-source software development that would require code reviews by two independent parties, and that maintainers use two-factor authentication.
It reckons the higher SLSA levels would have helped prevent the attack on SolarWinds’ software build system, which was compromised to install an implant that injected a backdoor during each new build. It also argues SLSA would help in the CodeCov attack because “provenance of the artifact in the GCS bucket would have shown that the artifact was not built in the expected manner from the expected source repo.”
SEE: GDPR: Fines increased by 40% last year, and they’re about to get a lot bigger
While the SLSA framework iis just a set of guidelines for now, Google envisages that its final form will go beyond best practices via 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,” Google said.
The scheme consists of four levels of SLSA, with four being the ideal state where all software development processes are protected, as pictured below.
