CI/CD のビルド証跡を公開タイムスタンプに固定するには

はい、CI/CD パイプラインは「何を、いつビルドしたか」の証明を公開できます。やり方は、重要な出力（成果物、SBOM、ログ、リリースマニフェスト）をハッシュ化し、それらのハッシュを 1 つの Merkle ルートに畳み込み、そのビルド・リリース・あるいは特定の時間帯について単一の Label 309 レコードを公開することです。後から誰でも、特定の成果物やマニフェストがそのコミット済みバッチの一部であったこと、そしてそのバッチが公開ブロック時刻までに存在していたことを証明できます。

これは SLSA、Sigstore、GitHub Artifact Attestations、in-toto を置き換えるものではありません。これらが直接は提供しない要素を 1 つ補完します。それは、どのベンダーも管理せず、独立していて公開かつ発行者非依存のタイムアンカーです。

CI/CD パイプラインは実際に何を証明すべきか

1 年後に提出が必要になるかもしれない証跡を起点に考えてください。

CI/CD 証明は、次のものにコミットできます。

リリース成果物
コンテナイメージのダイジェスト
SBOM（ソフトウェア部品表）ファイル
SLSA プロベナンス・アテステーション
in-toto のリンクメタデータ
ビルドログ
テストレポート
デプロイメントマニフェスト
変更履歴のスナップショット
ソースコミットの参照
依存関係のロックファイル
署名付きチェックサム
リリースノート

存在するからといって、すべてをハッシュ化しないでください。セキュリティ、監査、インシデント対応、顧客の信頼、あるいはリリースの完全性にとって重要な成果物をハッシュ化します。

優れた証明は、将来の 1 つの具体的な問いに答えます。「この成果物やマニフェストは、当時コミットしたリリース証跡の一部だったのか」という問いです。

Merkle バッチ処理のパターンはどう機能するのか

単一の成果物であれば、ハッシュ証明 1 つで十分です。

しかしリリースでは通常、成果物が多数あり、それぞれを独立したトランザクションとして公開するのは無駄です。Merkle ルートがそれを解決します。各証跡項目をリーフへとハッシュ化し、順序付けされたリーフを 1 つの 32 バイトのルートに畳み込み、ルートだけを公開します。リリース全体をカバーする、1 つのオンチェーンレコードになります。

パイプラインの流れは次のとおりです。

成果物をビルドします。
SBOM、アテステーション、ログ、マニフェストを生成または収集します。
各証跡項目をリーフへとハッシュ化します。
順序付けされたリーフリストを組み立てます。
Merkle ツリーを構築し、ルートを計算します。
ルートを保持する Label 309 レコードを 1 つ公開します。
リーフリストと包含証明をリリース証跡とあわせて保存します。

後から検証ツールは、1 つのファイルまたはダイジェストを取り、その包含証明を確認し、その項目が Label 309 レコード内のルートに属することを確認します。包含証明はバッチサイズの対数でしか増えないため、数千のリーフにわたるルートでもミリ秒単位で検証できます。完全にオフラインで、ゲートウェイもネットワークも不要です。仕組みの全体は数千のファイルを 1 つのレコードにをご覧ください。

既存のアテステーションに頼るだけではいけないのか

既存のアテステーションは使ってください。そのうえで、それらを固定するのです。

SLSA プロベナンスは、ソフトウェア成果物がどこで、いつ、どのように生成されたかを記述します。GitHub Artifact Attestations は、バイナリやコンテナイメージといった成果物のビルドプロベナンスを確立します。Sigstore は、署名済みのサプライチェーンメタデータを Rekor と呼ばれる公開・追記専用の透明性ログに記録します。in-toto は、サプライチェーンの各ステップが計画どおりに、正しい主体によって、正しい入力に対して実行されたことを検証するためのフレームワークです。

これらはいずれも実在する問題を解決します。Label 309 が解決するのは別の問題です。すなわち、特定の証跡セットが特定の公開時刻の時点で存在していたことを、Cardano に固定された独立検証可能な証明として公開することです。優れたパイプラインは「アテステーションか存在証明か」を選びません。両方を使います。

ビルドプロベナンスには SLSA または GitHub アテステーション
署名と透明性ログのワークフローには Sigstore
サプライチェーンのステップ検証には in-toto
証跡セット全体にわたる公開タイムアンカーには Label 309

Label 309 は何を上乗せするのか

Cardano 上の、耐久性のある公開コミットメントを加えます。

そのコミットメントは、単一のリリースマニフェストでも、多数の証跡項目にわたる Merkle ルートでもカバーできます。プロジェクトや企業のアイデンティティで署名することもできます。そして、トランザクションメタデータと公開された Cardano エクスプローラーだけで検証でき、アカウントもログインも不要で、元の CI プロバイダーのダッシュボードがオンラインであり続けることにも依存しません。

その独立性が最も重要になるのは、チームが、後の何らかの出来事よりも前に証跡が存在していたことを証明する必要がある場面です。

脆弱性の開示
セキュリティインシデント
顧客によるセキュリティレビュー
調達監査
コンプライアンスの期限
リリースをめぐる紛争
サプライチェーン調査

この証明は、関係者の誰もこっそり動かせないアンカーをタイムラインに与えます。

監査人は何を検証するのか

監査人は、単一の成果物からオンチェーンレコードまで、チェーンをたどれるはずです。

レビュー対象の成果物または SBOM を取り出します。
そのハッシュを計算します。
リリースの Merkle ルートに対して包含証明を確認します。
そのルートが Label 309 レコードに現れることを確認します。
Cardano トランザクションを参照し、そのブロック時刻を読み取ります。
レコードの署名があれば検証します。
周辺のプロベナンスやアテステーションを、それぞれ自身のルールのもとで確認します。

これは 2 つの問いをきれいに切り分けます。Label 309 証明が答えるのは「この証跡はこの公開時刻までにコミットされたのか」です。SLSA、Sigstore、GitHub、in-toto の層が答えるのは「この証跡は、その成果物がどのようにビルド・署名・配布されたかについて何を語るのか」です。どちらも相手の仕事をしようとはしません。

リリースマニフェストには何を含めるべきか

リリースマニフェストは、退屈で完全であるべきです。次のような項目を含められます。

リリース名とバージョン
リポジトリ URL
ソースコミット
ビルドワークフローの識別子
ビルド実行 ID
成果物の名前とダイジェスト
コンテナイメージのダイジェスト
SBOM ファイルのダイジェスト
アテステーションファイルのダイジェスト
テストレポートのダイジェスト
ビルドログのダイジェスト
CI システムが報告したタイムスタンプ
Label 309 トランザクション参照（公開後に追加）

マニフェスト自体もハッシュ化してリーフとして含められます。また、バッチ内の他のすべてのリーフを説明する、人間が読めるインデックスも兼ねます。フォーマットは安定させてください。証跡の構造がリリースごとに予測できるほど、証明は検証しやすくなります。

パイプラインはレコードに署名すべきか

たいていの場合、はい。

Merkle ルートは、あるリストがコミットされたことを証明します。署名はそれに加えて、プロジェクト・企業・リリースシステム・あるいは承認されたアイデンティティがそのコミットメントを 保証した ことを示します。Label 309 では、これは任意のレコードレベルの署名です。存在の主張を検証するうえで作成者が示されている必要は決してありませんが、説明責任が欲しいときには利用できます。

署名鍵は意図的に管理してください。長期間有効なアイデンティティのシードを、任意の CI ランナーにばらまかないでください。脅威モデルに応じて、専用のリリースアイデンティティ、管理された署名サービス、ハードウェアに裏付けられたワークフロー、あるいはアクセス制御を厳格にしたセルフホストランナーを使ってください。オープンソースの cardanowall CLI は、まさにこの用途のために作られています。ゲートウェイ非依存かつ生のシード優先で、ウェブサイトを介さずに自動化へ組み込めます。エンドツーエンドの流れは自動化のなかで CLI を使うをご覧ください。

署名は説明責任を加えます。しかしそれ自体が、脆弱なビルドパイプラインを安全にするわけではありません。

リーフリストはどこに置くべきか

リリース証跡とあわせて保存してください。

リーフリストと包含証明こそが、後で個々の項目を証明するための手段です。ルートだけを公開してリーフリストを失うと、何らかの リストが存在したことは依然として証明できますが、特定の 成果物がそこに含まれていたことはもはや証明できなくなる場合があります。

適切な保存先はワークフローによって異なります。

リリースアーカイブに添付する
成果物リポジトリに保存する
内部の証跡用バケットに保管する
機密性のある証跡は暗号化コンテンツとして封印する
公開しても安全な場合はコンテンツアドレス指定ストレージで公開する

ルートはアンカーです。リーフリストは地図です。

パイプラインはどのくらいの頻度で公開すべきか

証明の頻度はリリースの頻度に合わせてください。よくある選択肢は次のとおりです。

リリースごとに 1 つの証明
ビルドごとに 1 つの証明
デプロイメントごとに 1 つの証明
継続的なログには 1 日 1 つの証明
セキュリティ上重要なイベントごとに 1 つの証明

公開が稀すぎるとタイムラインが弱まり、公開が頻繁すぎるとコストと運用上のノイズが増えます。Merkle バッチ処理を使えば、ビジネス上の問いに合った頻度を選べます。顧客が「バージョン 2.3.1 では正確に何が出荷されたのか」と尋ねるなら、リリースごとに 1 つの証明で十分です。規制当局や監査人が監視が 継続的 だったかを問うなら、日次や時間単位のコミットメントのほうが役立ちます。

公開には費用がかかります。ゲートウェイが実際の Cardano トランザクション手数料に加えてストレージ費用を支払うからです。したがって頻度は、無料で回せるつまみではなく、コストと証跡のあいだの実質的なトレードオフです。

CI/CD 証明が証明しないものは何か

ビルドが安全だったことは証明しません。

存在証明が示せるのは、成果物・SBOM・ログ・マニフェストが公開時刻までに存在していたこと、その項目がコミット済みバッチに含まれていたこと、そしてある鍵がレコードに署名したことです。この証明が裏付けるのは、それがすべてです。

ソースコードが安全だったことは証明しません。ランナーが侵害されていなかったことも証明しません。依存関係に脆弱性がなかったことも証明しません。SBOM が完全であることも証明しません。そしてアテステーション自身の検証ルールが通らないかぎり、そのアテステーションが信頼できることも証明しません。だからこそ Label 309 は、サプライチェーンのセキュリティツールを置き換えるのではなく、それらの 傍らに 位置します。一般的な限界については証明が証明しないことをご覧ください。

最初の実装として何が良いか

リリース証明から始めてください。各リリースで次を行います。

通常の成果物を生成します。
SBOM とアテステーションを生成または収集します。
リリースマニフェストを作成します。
各証跡ファイルをリーフへとハッシュ化します。
Merkle ルートを構築します。
署名付きの Label 309 レコードを公開します。
トランザクション参照をリリースノートに保存します。
マニフェスト、リーフリスト、包含証明をリリースとあわせて保存します。

これだけで、初日からビルドシステムを再設計しなくても、実用的な証跡が手に入ります。そこから日次ログ、デプロイメントマニフェスト、あるいはより大量の自動化へと広げていけます。

要点

CI/CD 証明とは、リリース証跡へのタイムスタンプ付きコミットメントです。

重要な成果物・SBOM・ログ・アテステーション・マニフェストをハッシュ化します。それらを 1 つの Merkle ルートにまとめます。そのルートを Label 309 レコードで公開します。プロジェクトや企業のアイデンティティに保証させたいなら、レコードに署名します。

プロベナンスとサプライチェーンメタデータのためには、SLSA、Sigstore、GitHub Artifact Attestations、in-toto を引き続き使ってください。そして、証跡セット全体を、どのベンダーも動かせない 1 つの瞬間に結びつける独立した公開タイムアンカーとして、Label 309 を加えてください。

さらに読む

数千のファイルを 1 つのレコードに — Merkle バッチ処理がどのようにセット全体を単一のルートのもとに固定するか。
自動化のなかで CLI を使う — パイプラインから公開と検証を駆動する方法。
存在証明と Sigstore の比較 — この 2 つの層がどう異なり、どこで組み合わさるか。
SLSA ビルドプロベナンス — SLSA プロベナンスの仕様。
Sigstore と Rekor 透明性ログ — 公開・追記専用ログによるキーレス署名。
GitHub Artifact Attestations — GitHub でビルドした成果物のビルドプロベナンス。
in-toto — ソフトウェアサプライチェーンの完全性フレームワーク。