SLSA vs. Software Supply Chain Attacks

SLSA vs. Software Supply Chain Attacks

Past Attacks and How SLSA Helps

More than a condiment or dance style, SLSA is a framework for strengthening the security of the software supply chain. SLSA, or supply-chain levels for software artifacts, provides an incremental series of defensive measures that prevents tampering and improves the integrity of a software artifact. Companies and open source projects can adopt SLSA to provide confidence in their software supply chain security.

Our blog recently outlined the history and goals of SLSA. In this next post, we describe two past software supply chain attacks and how the security controls prescribed by SLSA either helped or, if implemented, could have helped.

For context, the SLSA security controls–the technical term for defensive measures–can be divided into four categories: source, build, provenance, and common. Table one provides an overview of each category of controls and their purpose.

Table 1. SLSA Security Control Categories and Purpose

Category

Purpose

Source Code

Stymie attacks that attempt to bypass code review or compromise the source code system

Build System

Protect against threats such as a compromised build platform or unauthorized modifications to source code after the code leaves the source code management system

Provenance

Provide verifiable information about where, when, and how a software artifact was produced

Common

A set of baseline security controls for all computer systems that are part of writing, building, and distributing a piece of software

A detailed explanation of the requirements can be found on the SLSA website.

The next two sections describe software supply chain attacks on the PHP source code and the build process of Apple apps, illustrating some of the ways in which SLSA’s security controls either helped or, if implemented, could have helped. We chose these two particular attacks not only because they are high profile but because they represent two different types of supply chain attacks: source code compromise and build system compromise.

Malicious Commits Pushed to PHP Repository

In March 2021, someone snuck a backdoor, a way of gaining unauthorized access, into the open source programming language PHP’s source code. PHP powers nearly 80 percent of websites. A backdoor placed into PHP is like a master key for the internet. If that sounds bad, it’s because it is. Someone, still unidentified, impersonated core software developers associated with the PHP project and added the malicious code. Fortunately, PHP developers noticed these malicious commits before they could propagate.

This near-disaster illustrates the ability of SLSA controls to frustrate attackers. See table one for a summary of the controls that either helped or, if implemented, could have helped prevent or mitigate this attack. The analysis below mentions a few of the controls in conjunction with this event.

PHP’s source code was stored in a Git version control system, providing an opportunity for core PHP developers to notice and remediate the attack. Other controls, apparently not implemented or unenforced, could have helped prevent the attack. For instance, these commits were merged into the source code without two-person review, where at least two trusted parties review the new code. Two-factor authentication, part of the verified history requirement, could also have helped. Additionally, one of the key PHP developers conceded that the source code system, which was independently run rather than hosted via GitHub or GitLab, was “​​very old code on a very old operating system/PHP version, so some kind of vulnerability would not be terribly surprising.” Without knowing the details, it’s nonetheless safe to say the “very old code” is inconsistent with a properly patched source code management system, a requirement of the common security control.

Table 1. How SLSA Controls Helped with the PHP Source Code Attack

Source

Build

Provenance

Common

Version controlled

Scripted build

Available

Security

Verified history

Build service

Authenticated

Access

Retained indefinitely

Build as code

Service generated

Superusers

Two-person reviewed

Ephemeral environment

Non-falsifiable



Isolated

Dependencies complete



Parameterless




Hermetic

Reproducible



Color-coding explanation

Control helped

Control could have helped if implemented.

Apple’s “Walled Garden” Breached Due to Malicious Compiler

Software developers building applications for Apple iPhones and other Apple hardware use an Apple-specific tool, Xcode, to write and build software. Apple expects software developers to download Xcode from an Apple-controlled website. It sounds simple.

Unfortunately, sometimes internet users don’t download files through official channels, especially when a firewall makes large file downloads painfully slow. In this case, in 2015 someone placed a backdoored copy of Xcode on a Chinese hosting platform, tricking countless numbers of software developers hoping to avoid slow downloads. This version of Xcode, dubbed XcodeGhost, infected the software build process, covertly adding malicious functionality to apps built with XcodeGhost. Dozens of these backdoored apps then landed in Apple’s app store, evading Apple’s code review measures and enabling the attacker to, for instance, phish credentials from app users.

The build-related security controls in SLSA could have prevented or at least complicated the job of the attackers behind XcodeGhost. For instance, the hermetic build requirement requires software teams to declare their sources, presumably including the build tool, fetch the artifacts within a “trusted control plane,” and to check the cryptographic hash of any downloaded artifact. Although engineering details on the affected software teams are scant, the use of XcodeGhost suggests that these practices were either absent or neglected. The requirement for a reproducible build–which dictates that identical software inputs result in bit-for-bit identical output–could have provided fast remediation, allowing teams to know confidently if their application was built with XcodeGhost.

Table 2. How SLSA Controls Could Have Helped with XCodeGhost

Source

Build

Provenance

Common

Version controlled

Scripted build

Available

Security

Verified history

Build service

Authenticated

Access

Retained indefinitely

Build as code

Service generated

Superusers

Two-person reviewed

Ephemeral environment

Non-falsifiable



Isolated

Dependencies complete



Parameterless




Hermetic

Reproducible



Color-coding explanation

Control helped

Control could have helped if implemented.

Conclusion

In short, SLSA’s defensive measures either helped or, if implemented, could have helped with both attacks. Of course, there are many other attacks, either hundreds or thousands depending on how one counts. A more thorough analysis would analyze each attack and determine which controls would or would not have aided defenders. SLSA is admittedly a work-in-progress and there is active discussion about what measures ought to be within scope. Analytical approaches like the one above can shed some light on whether a given framework is adequate for any particular class of compromises.

For companies and open source projects interested in understanding and improving their SLSA level, please reach out to us via this link.

Also, stay tuned for more SLSA-related blog posts. If you’d like to learn more, or get involved with the SLSA community, we have a slack channel, biweekly meetings, email list and the repo itself for issues and discussions. This information can be found at the SLSA GitHub page.

Show Comments