Content last updated 2026-02-06

再現可能ビルド

GitLab がビルドプロセスにおいて再現可能ビルドをどのように実装しているかについて学びます

再現可能ビルドとは何か

再現可能ビルド（Reproducible Builds、RB）とは、特定のリリースで公開されたビルドが、ローカルにデプロイされたビルドと十分に類似している1、または同一であることをエンドユーザーが検証できるようにするための、ソフトウェアのビルド手法です。

RB の手法は、3 つの主要な原則から構成されます。

  • 密閉性 (Hermetic): すべてのビルド入力が曖昧さのない方法で指定されること。ビルドに含まれる各項目には、完全に解決されたバージョン番号や暗号学的ハッシュが付与されます。密閉性はビルドプロセスの一部として検証されます。
  • 再現性 (Reproducible): ビルドプロセスを実行すると、開発者と同じビット単位の出力が得られなければなりません。非決定性や差異を生じさせる要素はすべて取り除き、ビルドを再現するために必要なすべての情報を buildinfo などのロックファイルに事前に提示する必要があります。
  • 検証可能性 (Verifiable): 信頼できる方法で、最終バイナリがビルド元のソースに対して暗号学的に検証できる仕組みを採用するべきです。

なぜ再現可能ビルドが重要か

RB により、エンドユーザーはビルドされたコンポーネントのソフトウェアサプライチェーンに対して信頼を持つことができます。配布ミラー、サードパーティのホスティングなどから生じうるバックドアやその他の輸送中の脆弱性のような脅威から、ソフトウェアのビルドプロセスを堅牢化します。また、デバッグにも役立ちます。RB の類似度スコアが低い問題のあるビルドは、より容易にトリアージできます。

密閉性の技術的要件は何か

ビルドはバイナリ来歴 (Binary Provenance、BP) を実装する必要があります。バイナリ来歴とは、特定のバイナリ成果物がどのようにビルドされたかについての記述を、ビルドシステムが持つべきだと言うことを言い換えたものです。これには、入力、変換、およびビルドを実行したエンティティが含まれます。BP は次のフィールドを含むファイルです。

  • 真正性証明 (Authenticity Attestation): BP を生成したシステムを記述し、ファイルの真正性を保証するための暗号学的署名を含みます
  • 期待される出力 (Expected Outputs): ビルドプロセスのすべての期待される出力を記述し、各成果物の暗号学的ハッシュを提供します。
  • 期待される入力 (Expected Inputs): ビルドに含まれるすべてのものを記述します。このフィールドにより、検証者はソースを成果物と関連付けることができます
    • ソース: 期待される入力フィールド内。これは「https://gitlab.com/gitlab-org/gitlab の git commit 291e...494d」、あるいは SHA256 ハッシュ「75a4...9982」付きの「gitlab-ee-17.0.1」のような形になるかもしれません
    • 依存関係: あらゆる暗黙の依存関係は上記の形式でリンクされる必要があります。各入力はビルドの完全性に影響を与えます。
  • コマンド (Commands): ビルドの開始に使用された各コマンドは、自動分析を可能にするように整理する必要があります
    • 例: {"gitlab-omnibus": {"command": "build", "target": "//main:hello_world"}}"
  • 環境 (Environment): アーキテクチャの詳細、環境変数、ツール／コンパイラのバージョンなどの情報。
  • バージョニング (Versioning): ビルドのタイムスタンプ

他のフィールドも有益である可能性があり、上記のリストは網羅的ではないことに注意してください。各 BP は、適切な脅威ランドスケープに合うように修正する必要があります。より高い忠実度を必要とするビルドには、検証を支援する追加のフィールドを含めるべきです。

再現性の技術的要件は何か

上述の通り、異なる再現可能ビルドは異なる必要類似度スコアを持つ予定です。一部の非決定論的要因が緩和できない場合があるため、100% の再現性を強制することは必ずしも実現可能ではありません。再現性の基準を満たすために、ビルドは次のものでなければなりません。

  • バイト単位で検証可能 (Byte-by-byte verifiable): これは通常、認証されたソースと比較できる暗号学的ハッシュの形を取ります
  • 自動化可能 (Automatable): ソース入力、期待される出力、証明などのビルドハッシュは、自動化により容易に検証できる形式で提供されるべきです

  1. 十分な類似性 (Sufficient similarity) は、100% の検証可能性が必ずしも実現可能ではないことを強調しています。コンパイラのバージョン、OS ハードウェア、タイムスタンプ、ファイルシステム上のファイルの順序、その他の非決定性ソースの違いは、類似性の指標を低下させます。十分な類似性の目標は、ソースコードのメンテナーによって設定されるべきものです。 ↩︎

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License