再現可能なビルド

再現可能なビルドとは、同じソースコードを同じビルド環境と同じビルド手順でビルドすれば、誰がいつ行ってもビット単位で同一の成果物が得られるビルドのことです。これはReproducible Buildsプロジェクトの定義に基づいています。ここでいう成果物とは、実行ファイル、配布パッケージ、コンテナイメージやファイルシステムイメージなど、ビルドの目的となる出力です。ログは含みません。「もう一度ビルドできる」こととは違い、再現可能とはバイトが一致することを意味します。

多くのビルドが再現可能でない理由

• ビルド時の依存関係の解決。 ロックファイルがなければ、パッケージマネージャーはビルドの実行時にバージョンを選びます。PyPIでの解決は応答が届く順序によって結果が変わることがあり、バージョン範囲は新しいリリースが出ると動き、latestのような可変タグは別のものを指すようになります。
• 環境。 タイムスタンプ、ファイルパス、ロケール、ホスト自体のツールが成果物に入り込みます。
• ランダム性。 ビルドステップがIDを生成したり、ハッシュ順にファイルを並べたり、毎回異なる順序で並列処理を行ったりします。

そのため、同じコミットを続けて2回ビルドしても、同じ結果になる保証も、同じSBOMになる保証もありません。ロックファイルに記載されていないコードをダウンロードするビルド、つまり隠れた依存関係があるビルドでは、さらに悪化します。

チームがビルドを再現可能にする方法

• ベースイメージはダイジェストで、ツールはバージョンで固定するなど、すべての入力を固定・ロックします（ロックファイルを参照）。
• 時計の代わりに固定の時刻を使います。SOURCE_DATE_EPOCHは、ビルドツールが現在時刻の代わりに使うUnixタイムスタンプを保持する標準の環境変数です。
• ビルドパスを除去または正規化し、ファイル一覧をソートし、ロケールを固定します。
• ツールチェーン自体も固定された密閉環境でビルドします。Nixはその方法のひとつです。
• 検証します。同じコミットを、別のマシン、別のパス、別の日に、互いに独立して2回ビルドし、出力を比較します。ハッシュが異なる場合は、diffoscopeで何が違うのかを正確に確認できます。

Yocto Projectは、再現性が前提にするものではなく検証すべき性質であることを示しています。同プロジェクトのドキュメントによれば、プロジェクトのビルドはリリース3.1以降「タイムスタンプを含むバイナリレベルまで」再現可能であり、完全な再現性を保証するのはBitBakeとOpenEmbedded-Coreだけで、「別のレイヤーを追加した瞬間に、この保証は無効になる」とされています。プロジェクトはこれをoe-selftestで検証しています。

再現可能なビルドとSBOM

すべてのビルドが再現可能なら、古いリリースを後で再ビルドしてSBOMを生成できます。しかし多くはそうではないため、再ビルドや今日のソースコードのスキャンが示すのは似たビルドであり、出荷したビルドではありません。本番環境にあるものを示すSBOMは、そのリリースを生成したCIビルドから記録されたものです。

再現可能なビルドであっても、その記録が不要になるわけではありません。ハッシュの一致は2つのビルドが同じ出力を生んだことを証明しますが、何が入っていたかは列挙しません。インベントリと、そのSBOMの完全性の正直な表明は依然として必要です。より詳しい議論はCIがサプライチェーンセキュリティの場である理由とSBOMのベストプラクティスにあります。

SLSAは、ビルドが主張どおりのことを行ったかを検証する方法のひとつとして再現性を扱っています。

再現性は、Nix、Yocto、Debianのツールなどを使って、ビルドシステムの側で実現するものです。CRACIはビルドを再現可能にはしません。CRACIはビルドの実行中に各ビルドのSBOMを記録するため、出荷したものの記録が再ビルドに左右されません。ビルド時SBOMを参照してください。