記事一覧

監査担当者が歓迎するビット単位で再現可能なソフトウェアファクトリー

AGELAIOS

エンジニアリング

同じリビジョンから始まる2本の並行ビルドチェーンがビット単位の比較へ収束し、監査成果物を生成する図。

ソースコードはレビュー済みです。アーキテクチャも文書化され、セキュリティ統制も承認されました。それでもシステムが現場へ届くと、1つの問いが残ります。配備されたイメージを、その正確なソースリビジョンまで追跡できるでしょうか。

従来のソフトウェアでは、答えはビルドサーバーから収集した記録に依存しがちです。AGELAIOSはより直接的な方法を採ります。同じリビジョンを別々の環境で2回ビルドし、生成された成果物をバイト単位で比較し、相違があればパイプラインを失敗させます。

これは単なる品質指標ではありません。ソースコード、システムイメージ、監査証拠の間に検証可能なつながりを作ります。また、セキュリティチーム、運用者、監査担当者がリリース判断に使える共通基盤になります。

すべての重要システムが答えるべき問い

リリースから6か月後に、監査担当者が配備済みノードを調べる場面を想像してください。ソースリポジトリには承認済みリビジョンがあります。更新サービスは公開済みイメージを識別します。デバイス内のバイナリには固有の暗号学的ダイジェストがあります。文書はこれらが対応すると主張できますが、主張と再現可能な結果は同じではありません。

Reproducible Buildsプロジェクトが技術標準を示しています。同じソースコード、ビルド環境、ビルド手順が与えられた場合、別の当事者が指定成果物のビット単位で同一なコピーを生成できなければなりません [1]。

AGELAIOSへ適用すると、検証経路は明快です。

1つの承認済みリビジョン → 2回の完全ビルド → 2組の成果物 → 1回の暗号学的比較

公開システムイメージ、モジュール、そのアーカイブが比較対象です。1バイトでも変わればダイジェストが変わり、パイプラインは停止します。この比較付き二重ビルドは、参照プロジェクトが説明する9本のCIパイプラインの1つです。

この統制はリビジョンごとに実行されます。依存関係がタイムスタンプを埋め込み始めた、アーカイブ内のファイル順が不安定になった、ツールチェーン更新が出力を変えたといった問題は、回帰が入った時点で検出されます。数か月後の認定レビューで問題を再構築せず、該当コミットを調査できます。

再現性は宣言ではなく設計する

ビルドへの入力はソースツリーだけではありません。時刻、パス名、アカウント識別子、言語設定さえ、ソフトウェアの意図した挙動を変えずに最終バイト列を変える可能性があります。再現可能なファクトリーは、こうした周辺変数を露出させ、制御しなければなりません。

AGELAIOSは、代表的な5つの要因に対処します。

  1. タイムスタンプを正規化します。 ビルドツールは現在時刻を記録しがちです。Reproducible Buildsプロジェクトが確立した規約SOURCE_DATE_EPOCHによって、リビジョン由来の安定した日時を与えます [2]。
  2. ファイル順を決定的にします。 ファイルシステムはディレクトリ走査の順序を保証しません。アーカイブ作成前にファイル一覧を明示的にソートします。
  3. ビルドパスを制御します。 絶対作業パスは、デバッグ情報、マクロ、生成ファイルへ漏れることがあります。固定値へマッピングします。
  4. ロケールとタイムゾーンを固定します。 ソートと文字列書式はマシン間で変わる可能性があります。両方をビルド用に固定します。
  5. ユーザー・グループ識別子を正規化します。 アーカイブは各ファイルの作成アカウントを記録する場合があります。固定識別子によってマシン固有の差を除きます。

これらの対策は、隠れていた環境変数を明示的なビルド入力へ変えます。新しい依存関係が新しい変動要因を持ち込む可能性があるため、この一覧は意図的に完結したものとして扱いません。二重ビルドが安全網です。見落とした差を、成果物の受入前に可視化します。

1回のビルド、1つのイメージ、1組の証拠

再現性は本質的な問いに答えますが、監査担当者には一致するダイジェスト以上の情報が必要です。イメージに何が含まれ、どう生成され、リリース時にどの既知リスクが特定されていたかを知る必要があります。

そのため、AGELAIOSファクトリーはイメージと裏付け証拠を同じビルドで生成します。

  • ISO/IEC 5962:2021として標準化されたSPDX形式のSBOM。ソフトウェアコンポーネントを一覧化し、NTIAが定めた最低要素をカバーします [3] [7]。
  • 公開脆弱性データベースとSBOMを照合して生成するCVEレポート。不利な一致も含めて報告します。
  • 依存関係のライセンスを一覧化し、プロジェクトのApache-2.0ライセンスとの互換性を確認するライセンスレポート。
  • SLSAとin-totoが形式化した原則に従い、ソースリビジョン、ビルド環境、入力を記録する署名済み来歴マニフェスト [5] [6]。
  • cargo-auditableで情報を付加したRustバイナリ。配備済みバイナリから直接、依存関係情報を検査できます [4]。

来歴マニフェストは、TUF更新リポジトリ内でイメージに付随します。証拠は正確なリビジョンに結び付き、そのリビジョンが変わるたびに更新されます。監査専用の別ビルドも、配備システムから静かに乖離し得る手作業の証拠パックもありません。

機密システムを運用する組織にとって、この方式には実務上の価値があります。工学チームがリリース履歴を再構築する時間を減らせます。セキュリティチームは最新のコンポーネント情報と脆弱性情報を得ます。監査担当者は、要件からメカニズムへ、メカニズムから生成証拠へ、文書化された連鎖をたどれます。より広い考え方は、ビルドごとに生成される証拠による継続的な認定で説明しています。

証明できることと、できないこと

ビット単位の再現性は、確立されたソフトウェアサプライチェーン手法であり、発明品でも独自ラベルでもありません。Reproducible BuildsプロジェクトとDebianなどの貢献者は、規約を定義し、SOURCE_DATE_EPOCHやdiffoscopeなどのツールを開発し、ディストリビューション規模でこの方式が機能することを実証してきました [1] [2]。AGELAIOSは、イミュータブルなシステムイメージ、署名済みモジュール、関連監査成果物という自らの管理範囲にこの手法を適用します。

出力の一致は、宣言された入力とビルド工程が公開成果物を生成したという強い証拠になります。また、単一のビルド結果への依存を減らします。それだけで、ソースコードに脆弱性がないことや、ツールチェーンの全コンポーネントが信頼できることを証明するものではありません。

3つの限界を明示しています。

  1. 独立した再ビルド実施者は、引き続き未達の目標です。 比較対象のビルドは現在、プロジェクトのCI内で実行されています。外部組織による再ビルドは、より強い組織的独立性を提供します。
  2. ツールチェーンのブートストラップは現在の範囲外です。 コンパイラーとビルドツールはバージョンとダイジェストで固定していますが、それらのツール自体をソースから再現することは別の課題です。
  3. 対象範囲は公開成果物に集中しています。 現在はイメージとモジュール成果物を比較しています。すべての二次成果物へ保証を広げる作業は進行中です。

これらの境界は重要です。購入者と保証チームが、現在存在する統制を、未実証の広い主張と混同せず評価できます。

結果を疑い、確かめられるから信頼できる

安全なプラットフォームの商業的価値は、顧客へより強い約束を受け入れるよう求めることからは生まれません。より強い検証手段を提供することから生まれます。

AGELAIOSの再現性統制は、検査して反復できます。適格なチームはApache-2.0の参照リポジトリをクローンし、リビジョンを選び、ビルド文書に従い、得られた暗号学的ダイジェストを比較できます。リポジトリは、比較付き二重ビルドを含む9本の公開CIパイプライン全体で、約930件の自動テストも報告しています。

認定準備、ソフトウェアサプライチェーンリスクの評価、主権的なインスタンスの運用を行うプログラムにとって、議論の前提が変わります。イメージは、静的な書類に支えられた不透明な納入物ではありません。最新の証拠を生成し、不一致を露出させ、顧客自身が検証できる工程とともに納入されます。

参考文献

  1. Reproducible Builds, “Definition”, accessed 2026, https://reproducible-builds.org/docs/definition/
  2. Reproducible Builds, “SOURCE_DATE_EPOCH”, accessed 2026, https://reproducible-builds.org/docs/source-date-epoch/
  3. SPDX, Linux Foundation, “The Software Package Data Exchange (SPDX) Specification”, ISO/IEC 5962:2021, https://spdx.dev/
  4. rust-secure-code, “cargo-auditable”, accessed 2026, https://github.com/rust-secure-code/cargo-auditable
  5. OpenSSF, “SLSA: Supply-chain Levels for Software Artifacts”, accessed 2026, https://slsa.dev/
  6. in-toto, “A framework to secure the integrity of software supply chains”, accessed 2026, https://in-toto.io/
  7. NTIA, “The Minimum Elements For a Software Bill of Materials (SBOM)”, 2021, https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom