How Reproducible Builds Foster Security

Security-conscious organizations typically have policies in place that require all open source software to be built from source code rather than importing prebuilt components. Building from source is one of the best ways to ensure security because, compared to importing an unsigned component from a public repository that provides no guarantees of security, you know exactly what is contained in the build and how it was built. Unfortunately, if your builds are not reproducible, it’s difficult to ensure that any built artifact is actually secure. 

A reproducible build is one in which the same “bits” input should always result in the same “bits” output. If they don’t, there is no guarantee the artifacts you’re working with haven’t changed from build to build. For example, as has happened with SolarWinds, Codecov, and others, software build processes are susceptible to being compromised at multiple points, allowing attackers to inject malware that then gets built into the final product and distributed downstream to your customers, exposing them to cyberattack. 

It’s only by ensuring reproducible builds that organizations can catch compromised artifacts, but ActiveState’s supply chain security survey showed that (on average) only ~22% of organizations currently implement reproducible builds:

The problem is prevalent across all geographies and organization sizes but is worse in Small & Medium-sized Businesses (SMB) as well as Mid-Sized Businesses (MSB) where only 20% and 17% of organizations surveyed have implemented reproducible builds. The issue is twofold for these smaller organizations: 

1. Open source software is typically built as a one-off task on a per project basis for the operating system(s) used by the team.
2. Open source dependencies once added to their codebase, are rarely updated/maintained.

Simply put, since most open source components/dependencies will never get rebuilt, creating the infrastructure to support reproducible builds for the Mac, Windows and Linux systems the team uses is seen as a waste of time and resources. 

On the other hand, Large Enterprises (LE) typically have a dedicated team of experienced build engineers that centrally create, update and maintain all the open source assets required by the enterprise’s numerous projects. As a result, the cost/benefit analysis points to the advantage of creating infrastructure to support reproducible builds since each dependency is likely to be built and rebuilt multiple times both within and across multiple projects.

However, as the survey results show, only about half of all LEs have deployed reproducible build systems. The other half still rely on one-off, non-reproducible builds for their open source components due to cost, time and/or resource constraints. But what if instead of incurring the costs of creating, updating and maintaining a reproducible build system yourself, you could just leverage a service instead?

Reproducible Builds On Demand

The ActiveState Platform was created with reproducible builds as a core design principle. Its tamper-proof build service builds any open source language dependency from source code (including linked C/Fortran libraries) in just a few minutes and packages it (along with all its transitive dependencies) for deployment on Windows, Mac, and Linux. Rather than create non-reproducible artifacts, the system is designed to fail should any checksum in the build process not be verified.

In this way, the ActiveState Platform’s build service incorporates many of the principles laid out in the Supply chain Levels for Software Artifacts (SLSA) specification, which is “a security framework, a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises.” Originally proposed by Google, SLSA is an emerging standard being driven by a consortium of leaders in diverse industries that will ultimately help enterprises address the security shortcomings in their software supply chain.

Specifically, the ActiveState Platform provides:

• Secure Build Service – ActiveState’s build service is just that: a dedicated service that runs on a minimal set of predefined, locked down resources rather than a developer’s desktop or other arbitrary system that can offer a larger attack surface to bad actors. 
• Scripted Builds – build scripts cannot be accessed and modified within the build service, preventing exploits.
• Ephemeral, Isolated Build Steps – every step in a build process executes in its own container, which is discarded at the completion of each step. In other words, containers are purpose-built to perform a single function, reducing the potential for compromise.
• Hermetic Environments – containers have no internet access, preventing (for example) dynamic packages from including remote resources.
• Reproducible Builds – the build process fails safe, terminating the build if any component generated during a build step fails its checksum verification.

This lines up favorably with the current SLSA specification for its highest levels of security, SLSA level 4:

Requirement	SLSA 1	SLSA 2	SLSA 3	SLSA 4
Build – Scripted build	✓	✓	✓	✓
Build – Build service		✓	✓	✓
Build – Build as code			✓	✓
Build – Ephemeral environment			✓	✓
Build – Isolated			✓	✓
Build – Parameterless				✓
Build – Hermetic				✓
Build – Reproducible				○

○ = required unless there is a justification

Note that the SLSA specification is still in alpha, and therefore subject to change, but it’s still worth examining some of the criteria in order to compare them against your current build infrastructure. If you’re like most of our customers, you’ll quickly realize that achieving level 4 compliance in-house is cost-prohibitive: it simply demands too much in terms of time and resources, which are better spent elsewhere. 

Secure Your Software Supply Chain with a Reproducible Build Service

The idea behind the ActiveState Platform’s adoption of SLSA is a simple yet vital one: to supply the software industry with open source language dependencies built securely from source code on demand. This service has the following benefits:

• Greater security over downloading unsigned, prebuilt dependencies from public repositories that offer no guarantees as to the security and integrity of the built artifacts they supply. 
• More up-to-date dependencies than other vendors can supply since the ActiveState Platform ingests and makes available new versions of dependencies as and when they are uploaded to the public repository. 
• Eliminate the cost to create, update and maintain build infrastructure for Windows, Mac and Linux systems on-premise.

In summary:

	Prebuilt?	Secure?	Up to Date?	Time & Resources
Public Repo	Yes	No	Yes	Low
Trusted Vendor	Yes	Yes	No	Low
Build It Yourself	No	Yes	Yes	High
ActiveState Platform	No	Yes	Yes	Low

 

Next steps:

Want to find out how a single developer with no language or operating system expertise can securely build (and update/remediate/maintain) all the open source language dependencies your team needs in just a few minutes? Sign up for a free ActiveState Platform account and try it yourself, or else Contact Sales and let our experts show you how it works. 

Continue reading:

• Register for our upcoming Webinar: DevOps, SLSA And Software Supply Chain Security
• Read our Data Sheet: ActiveState Platform’s Secure Build Service
• Read our white paper: AppSec Guide: The Open Source Supply Chain Can Be Fixed