Reproduzierbare Builds
Was ist Reproduzierbare Builds?
Reproduzierbare BuildsBuild-Praktiken, die sicherstellen, dass das Übersetzen desselben Quellcodes mit denselben Anweisungen ein bitgleiches Artefakt erzeugt - unabhängig davon, wann und wo gebaut wird.
Reproduzierbare Builds entfernen Nichtdeterminismus, sodass jede Person mit Quellcode und Rezept das identische Binary unabhängig erzeugen und Byte für Byte mit einer Veröffentlichung vergleichen kann. Voraussetzungen sind kontrollierte Zeitstempel, Build-Pfade, Umgebungsvariablen, Zufallsquellen, Locale, Dateireihenfolge und Compileroptionen. Das Reproducible-Builds-Projekt, Debian, NixOS, Arch Linux, Tor, F-Droid und Bazel investieren stark in diesem Bereich. Kombiniert mit signierter Provenance erlauben sie unabhängigen Rebuildern, die Herkunft eines Binaries aus dem veröffentlichten Quellcode zu bestätigen - hilfreich, um eine Kompromittierung einzelner Builder (wie bei SolarWinds) zu erkennen. Sie sind Voraussetzung für die höchsten SLSA-Levels und stützen das Vertrauen in kritische Open-Source-Software.
● Beispiele
- 01
Unabhängiger Rebuild einer Tor-Browser-Release, der bitgleich zum offiziellen Binary ist.
- 02
Bazel-Service, der aus demselben Commit auf jedem Worker denselben SHA-256-Digest erzeugt.
● Häufige Fragen
Was ist Reproduzierbare Builds?
Build-Praktiken, die sicherstellen, dass das Übersetzen desselben Quellcodes mit denselben Anweisungen ein bitgleiches Artefakt erzeugt - unabhängig davon, wann und wo gebaut wird. Es gehört zur Kategorie Anwendungssicherheit der Cybersicherheit.
Was bedeutet Reproduzierbare Builds?
Build-Praktiken, die sicherstellen, dass das Übersetzen desselben Quellcodes mit denselben Anweisungen ein bitgleiches Artefakt erzeugt - unabhängig davon, wann und wo gebaut wird.
Wie funktioniert Reproduzierbare Builds?
Reproduzierbare Builds entfernen Nichtdeterminismus, sodass jede Person mit Quellcode und Rezept das identische Binary unabhängig erzeugen und Byte für Byte mit einer Veröffentlichung vergleichen kann. Voraussetzungen sind kontrollierte Zeitstempel, Build-Pfade, Umgebungsvariablen, Zufallsquellen, Locale, Dateireihenfolge und Compileroptionen. Das Reproducible-Builds-Projekt, Debian, NixOS, Arch Linux, Tor, F-Droid und Bazel investieren stark in diesem Bereich. Kombiniert mit signierter Provenance erlauben sie unabhängigen Rebuildern, die Herkunft eines Binaries aus dem veröffentlichten Quellcode zu bestätigen - hilfreich, um eine Kompromittierung einzelner Builder (wie bei SolarWinds) zu erkennen. Sie sind Voraussetzung für die höchsten SLSA-Levels und stützen das Vertrauen in kritische Open-Source-Software.
Wie schützt man sich gegen Reproduzierbare Builds?
Schutzmaßnahmen gegen Reproduzierbare Builds kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Reproduzierbare Builds?
Übliche alternative Bezeichnungen: Deterministische Builds, Bitgenaue Builds.
● Verwandte Begriffe
- appsec№ 1053
SLSA Framework
Supply-chain Levels for Software Artifacts: ein vom OpenSSF veröffentlichter stufenweiser Anforderungskatalog, der Erstellung, Signatur und Verifikation von Software gegen Lieferketten-Manipulation zunehmend härtet.
- appsec№ 1069
Software-Supply-Chain-Sicherheit
Disziplin zum Schutz jedes Glieds der Software-Produktion - Quellcode, Abhängigkeiten, Build, Signatur, Distribution und Deployment - gegen Manipulation, bösartigen Code und Integritätsverlust.
- appsec№ 870
Provenance-Attestation
Signierte, maschinell verifizierbare Aussage darüber, wie ein Software-Artefakt entstanden ist - Quelle, Build-System, Parameter und Abhängigkeiten - damit Konsumenten dem Ursprung vertrauen können.
- appsec№ 305
Dependency Pinning
Die Praxis, Software-Abhängigkeiten auf exakte Versionen festzuschreiben, häufig zusammen mit kryptografischen Hashes, damit Builds stets dieselben Artefakte verwenden und resilient gegen Lieferketten-Manipulation sind.
- appsec№ 166
CI/CD-Sicherheit
Kontrollen, die Continuous-Integration- und Continuous-Delivery-Pipelines vor Kompromittierung, Code-Injektion, Secret-Leakage und unautorisierten Deployments schützen.
- appsec№ 784
Paketsignatur
Anbringen einer kryptografischen Signatur an einem Softwarepaket, damit Konsumenten Veröffentlicher und Unversehrtheit des Artefakts überprüfen können.