Reproducible Builds as a Supply Chain Control

Introduction

Cuprate, an alternative implementation of Monero's node software, faced a significant supply chain risk as it approached its beta release without reproducible builds. This meant users downloading Cuprate binaries had no way to verify that the executable matched the source code. Although no breach occurred, this gap highlighted the need for stronger controls.

Addressing the Gap

Cuprate's maintainers recognized the issue and initiated a three-month project to implement reproducible builds using StageX. This effort also aimed to improve dependency management and address book functionality, such as missing ban list support and peer bucketing.

Timeline of Actions

Here's how Cuprate addressed the control gap:

• Pre-beta state: No reproducible builds; binaries couldn't be independently verified.
• Recognition: The team identified reproducible builds as essential for the beta release.
• Commissioned work: A project was scoped to implement StageX-based reproducible builds and review dependency policies.
• Target outcome: Users will be able to build identical Cuprate binaries independently, enabling distributed verification.

The urgency was heightened by the FCMP++ hard fork deadline, but the need for control was clear regardless.

Missing Controls

1. Build Reproducibility

Without reproducible builds, users couldn't verify that distributed binaries matched the source repository. This left the project vulnerable to:

• Compromised CI pipelines injecting malicious code
• Rogue contributors inserting backdoors
• Supply chain attacks targeting the build toolchain

Monerod previously used collaborative building sessions and later Guix-based builds, but Cuprate lacked both.

2. Dependency Management

Cuprate operated without documented policies for:

• Vetting new dependencies
• Monitoring existing dependencies for compromise
• Updating dependencies regularly
• Evaluating the security of transitive dependencies

3. Network Integrity Controls

The address book component was missing:

• Ban lists compatible with Monerod's format
• Peer bucketing to prevent subnet-based Sybil attacks
• Complete RPC command implementation

These gaps could allow attackers to control multiple nodes in the same subnet, increasing the risk of eclipse attacks.

Standards and Requirements

ISO 27036-3

ISO 27036-3 requires verifying the integrity of software components. Reproducible builds meet this requirement by enabling distributed verification.

SR 23-4

SR 23-4 mandates Continuous Monitoring of Active Arrangements of third-party arrangements. For open-source dependencies, this means:

• Maintaining a dependency inventory
• Monitoring for vulnerabilities
• Tracking maintainer changes
• Defining update policies

NIST SP 800-161r1

NIST SP 800-161r1 emphasizes build environment security. Key controls include:

• Isolated build environments
• Cryptographic verification of build inputs
• Reproducible build processes
• Distributed verification

Action Items for Your Team

If you distribute binaries from open-source code:

1. Implement reproducible builds. Use tools like Guix for C/C++ projects, StageX for Rust, and reprotest for validation.
2. Document dependency criteria. Require criteria like maintainer count and vulnerability scan results before adding dependencies.
3. Automate dependency monitoring. Use tools like Dependabot or cargo-audit and define SLAs for patching vulnerabilities.
4. Version-pin dependencies. Lock to exact versions and update deliberately after testing.

If you're assessing an open-source project as a dependency:

1. Check for reproducible builds. Ensure you can verify distributed binaries.
2. Review dependency tree depth. Projects with many transitive dependencies carry higher risks.
3. Check for update policies. Look for documented processes in SECURITY.md or guidelines.
4. Verify network protections. Ensure peer bucketing, ban lists, and eclipse attack mitigations are in place.

The Cuprate case study shows the importance of pre-emptive control implementation. Identify your reproducible build gap today, scope the work, and ensure it's addressed before your next release.