Skip to content

MASWE-0075: Non-Reproducible Builds

MAS Requirement

The app offers reproducible builds.

Mappings

MASVS V2: MASVS-PRIVACY-3

CWE: CWE-1357: Reliance on Insufficiently Trustworthy Component, CWE-494: Download of Code Without Integrity Check

Overview

This weakness occurs when compiling the app's source with the same build environment does not yield a bit-for-bit identical binary, making it impossible to independently verify that a distributed binary was built from the claimed, unmodified source.

Reproducible builds allow third parties, and the developers themselves, to detect tampering or injected malicious code by rebuilding from source and comparing the result with the released artifact. Without reproducibility, this verification is impossible, weakening supply-chain integrity. Together with build provenance and attestation frameworks (e.g. SLSA), reproducible builds let stakeholders verify the integrity of released artifacts.

Modes of Introduction

  • Source Code Not Available: Not making the source code used to build the app available.
  • Non-Deterministic Build Outputs: Embedding timestamps, absolute paths, environment data, or unstable orderings in build artifacts, so identical inputs produce differing outputs.
  • Unpinned Build Environments: Building with undocumented or unpinned toolchains and dependencies, so it's impossible to recreate the environment that produced a release.
  • No Provenance or Attestation: Publishing releases without provenance describing what was built, from which source, and by which pipeline.
  • Applying Non-Deterministic Obfuscation Controls: By applying non-deterministic obfuscation controls, each build will generate a new random binary which cannot directly be compared with previous builds from the same code.

Impact

  • Execution of Unauthorized Code: Attackers can inject code during the build or distribution process without straightforward detection, since no independent party can verify the binary against the source, resulting in malicious code shipping to the entire user base.
  • Loss of User Trust: Users and auditors cannot verify that the shipped app matches the published source, resulting in weakened trust in the app, particularly for security- and privacy-sensitive apps.

Mitigations

  • Make Source Code Available: Make the source code used to build the app available, including any build scripts, so third parties can attempt to reproduce the build.
  • Make Builds Deterministic: Eliminate timestamps, absolute paths, environment-dependent data, and unstable orderings from build outputs, following reproducible-builds.org guidance.
  • Pin and Document the Build Environment: Define the exact toolchain and dependency versions in version control so any party can recreate the build environment.
  • Publish Provenance and Attestations: Generate build provenance (e.g. per SLSA) and, where feasible, publish verification instructions so third parties can reproduce and compare releases.
  • Use Deterministic Obfuscation Techniques: Use obfuscation techniques which will always generate the same deterministic result.

Tests

No Tests Yet

The MASTG doesn't contain any tests for this weakness yet. If you have proposals or would like to work on some, please open an issue in https://github.com/OWASP/mastg/issues indicating the MASWE-0075 mapping, the test titles and a summary of the tests.