SolarWinds Embraces SLSA
The Secure by Design initiative at SolarWinds encompasses a host of security-related changes, including multi-factor authentication enforcement, tighter firewall policies, and an expanded Security Operations Center. One major component of Secure by Design is our sharpened focus on supply chain security. We’re using SLSA, an emerging industry standard for supply chain security, to guide our thinking and measure our success.
Supply Chain Security
For physical goods, the supply chain is the set of raw materials and activities required to produce a finished product. In the world of software, raw materials are replaced by software libraries, compilers, and computer hardware. The activities in a software supply chain include everything from developers checking in code to the scripted operations of a build server. The ingredients and activities in the supply chain must be secured to produce a safe final product.
What Is SLSA?
In response to the rising risk of supply chain attacks, several organizations have launched the Supply chain Levels for Software Artifacts (SLSA). It’s pronounced “salsa,” which is more fun to say. SLSA defines a set of security controls that make it harder to tamper with the supply chain. The v0.1 specification is still considered alpha level, but it’s a useful framework for understanding the threat model and appropriate software build process countermeasures.
SLSA Security Levels
The SLSA framework defines four security levels, much like Carnegie Mellon’s five-level Software Capability Maturity Model (CMM). Technically, there is also a SLSA 0 level which provides no guarantees. SLSA 1 is the first noteworthy level. It requires a fully automated build that generates provenance: metadata about the source code, dependencies, and build process. At the high end of the scale, SLSA 4 requires two reviewers for every code change and a hermetic, reproducible build. “Hermetic” means the build steps can be run without network access once the dependencies have been retrieved. A hermetic build proves the manifest of dependencies is complete.
SLSA Requirements
To achieve one of the SLSA levels, your build process must satisfy a defined set of requirements. Each level expands on the set of requirements from the level below. These requirements fall into broad categories: source, build, provenance, and common.
Source requirements specify how the source code must be handled. This includes using a version control system, verified commits, and retention policies. Build requirements include build automation, hermetic builds, and bit-for-bit reproducibility. Another example is the use of ephemeral build environments, which makes it harder for an attacker to establish a lasting foothold on a build agent. The provenance requirements deal with authenticating and cataloging all the build dependencies. Finally, the common requirements are a catch-all category for physical security, IT security, and access control.
SLSA at SolarWinds
Like many organizations, SolarWinds does not fit neatly into one of the SLSA levels. The maturity of the build process varies somewhat from product to product within the organization. We have satisfied many of the requirements of SLSA 4, but some gaps still need to be filled. Ultimately, what matters is building software our customers can use with confidence. SLSA provides a useful framework for thinking about the software supply chain, identifying threats, and prioritizing improvements. We’re working hard to achieve full compliance with SLSA 4.
