存在証明と Sigstore：両方とも必要なのか

Sigstore と存在証明（Proof of Existence）は、実のところ競合する関係にはありません。Sigstore が答えるのは「このソフトウェアの成果物に誰が署名したのか、その署名イベントは公開ログに残っているのか」という問いです。Label 309 が答えるのは「これらのバイト列が公開された時刻までに存在していたか、しかも特定のサービスを信頼せずに証明できるか」という問いです。ほとんどのソフトウェアチームにとって最も強固な構成は、その両方を使うことです。リリースには Sigstore で署名してログに残し、そのリリース証跡を Label 309 でチェーン上に記録します。

Sigstore は、ソフトウェア署名と透明性のためのエコシステムです。Label 309 は、コンテンツのハッシュ、マニフェスト、封印付きファイル、あるいは Merkle ルートを Cardano 上に記録します。これにより、そのデータが特定のブロック時刻までに存在していたことを、後から誰でも検証できます。必要なのはトランザクションと公開エクスプローラーだけで、発行者のサーバーは一切介在しません。

Sigstore とは何か

Sigstore は、ソフトウェアサプライチェーンの成果物に署名し、その署名イベントを公開ログに記録するためのオープンソースのエコシステムです。

一般的なキーレスのワークフローでは、OpenID Connect (OIDC) の ID、Fulcio が発行する短命の証明書、クライアント側で生成される署名、そして Rekor トランスペアレンシーログへのエントリを使います。その狙いは、成果物への署名をより容易にしつつ、誰が何に署名したかを監査可能な公開記録として残すことです。

Sigstore は、次のような用途に適しています。

コンテナイメージ
バイナリおよびパッケージ
ソフトウェア部品表（SBOM）
来歴の証明
CI/CD およびリリース署名のワークフロー
成果物が想定された ID によって署名されたことの検証

Sigstore は、ソフトウェアサプライチェーンの信頼のために作られています。

Label 309 とは何か

Label 309 は、Cardano 上の存在証明レコードのための、オープンでベンダー中立な標準です。この提案は Cardano の CIP プロセスに提出され、CIP エディターによる審査を受けています。オンチェーンの識別子はメタデータラベル 309 です。

Label 309 レコードは、1 つ以上のコンテンツハッシュ、多数のファイルにまたがる Merkle ルート、任意のレコードレベルの署名、受信者の鍵に宛てた封印付きペイロード、そしてコンテンツアドレス指定ストレージの URI をコミットできます。証明の核となる部分は、Cardano トランザクションと検査対象のバイト列だけから独立に検証できます。アカウントもログインも不要で、単一のプロバイダーに依存することもありません。

ソフトウェアチームにとって、これはリリース証跡をチェーン上に記録するのに役立ちます。

成果物のダイジェスト
Sigstore のバンドル
SLSA の来歴および in-toto ステートメント
SBOM
リリースマニフェスト
ビルドログおよびテスト結果
インシデント証跡

Label 309 は、公開された、タイムスタンプ付きのコミットメント層です。

実際の違いは何か

Sigstore は、ソフトウェアに関する ID と署名の問いに答えます。Label 309 は、あらゆるバイト列に関する存在と時刻の問いに答えます。

Sigstore が答える助けになるのは、次のような問いです。

このコンテナイメージは署名されていたか。
署名証明書にはどの OIDC ID が紐づけられていたか。
署名イベントはトランスペアレンシーログに記録されたか。
成果物の署名は検証できるか。
これは信頼する署名者に関する自分のポリシーに合致するか。

Label 309 が答える助けになるのは、次のような問いです。

この成果物のダイジェストは、この Cardano のブロック時刻までに存在していたか。
この SBOM は、コミットされたリリース証跡の一部だったか。
このリリースマニフェストは、インシデントの前に存在していたか。
既知のプロジェクトのアイデンティティがレコードに署名したか（任意）。
受信者は、封印された証跡バンドルを後から復号できるか。

この 2 つの問いの集合は、重なり合うのではなく、互いに補い合います。

Rekor がすでにこれをやっているのでは

Sigstore を使っているなら、Rekor を使ってください。Rekor は、その仕事にうってつけのツールです。

Rekor は、署名とソフトウェアメタデータのためのトランスペアレンシーログであり、署名イベントを発見可能かつ監査可能にするよう設計されています。Sigstore のドキュメントでは、これを追記専用で改ざん耐性のある台帳と説明しており、監査者が整合性を監視できるとしています。その設計目標は、エントリを変更したり削除したりしようとするあらゆる試みを、見えないまま放置するのではなく検出できるようにすることです。

Label 309 は、Rekor を置き換えるものではありません。それとは別の種類のアンカーを提供します。

サービスが運用するログではなく、Cardano のコンセンサスに根ざした公開タイムスタンプ
メタデータラベル 309 のもとで定義されたレコードスキーマ
機微な証跡の、任意の封印による保全
特定の受信者への配信
大規模な証跡集合のための Merkle バッチ処理
特定のプロバイダーがオンラインであり続けることに依存しない検証

リリースにすでに Sigstore の証跡があるなら、その証跡をチェーン上に記録してください。捨てる必要はありません。

組み合わせたワークフローはどのようになるか

CI/CD パイプラインは、リリース証跡のフォルダーを組み立て、それをコミットできます。

そのフォルダーには、リリースマニフェスト、成果物のダイジェスト、Cosign の署名やバンドル、Rekor エントリの参照、SLSA の来歴、in-toto の証明、SBOM、ビルドログ、テストレポート、デプロイマニフェストなどが含まれるかもしれません。

パイプラインは各ファイルをハッシュ化し、Merkle ツリーを構築し、その Merkle ルートを保持する 1 つの Label 309 レコードを公開します。ルートは単一の 32 バイトの値なので、1 つのトランザクションが任意の大きさの証跡集合を代表できます。そして後から包含証明によって、特定のファイルがそのルートの一部だったことを示せます。レコードには、プロジェクトや会社のアイデンティティによる任意の署名も持たせられます。多数のファイルを 1 つのルートにまとめる仕組みについては、何千ものファイルを 1 つのレコードにを参照してください。エンドツーエンドのパイプラインのパターンについては、CI/CD のビルド証跡をチェーン上に記録するを参照してください。

後になって、監査者は独立した 2 つのことを検証します。

Sigstore：誰が何に、どの ID とトランスペアレンシーログのコンテキストのもとで署名したか
Label 309：どの証跡集合が、公開された Cardano の時刻までに存在していたか

Label 309 はソフトウェアの署名を検証するのか

いいえ。Label 309 は、Cosign の署名が有効かどうか、OIDC の ID が信頼できるかどうか、ポリシーが満たされているかどうか、ビルドが SLSA の期待を満たすかどうかを知りません。

Label 309 が証明できるのは、署名ファイル、バンドル、証明、SBOM、リリースマニフェストが「公開された時刻までに存在していた」ことです。それぞれのフォーマットは、ソフトウェアサプライチェーンのツールが自らのルールに従って検証し続けます。

この役割分担は健全です。存在証明が、ソフトウェア署名のポリシーエンジンのふりをすべきではありません。

Sigstore は証跡集合全体を保全するのか

それだけでは保全しません。Sigstore は、ソフトウェアの成果物に対する署名と透明性に焦点を当てています。実際のリリースプロセスでは、ビルドログ、SBOM、テストレポート、デプロイマニフェスト、インシデントのタイムライン、非公開の証跡バンドルもあわせて保全する必要が生じることがよくあります。

Label 309 は、これらの資料を 1 つの集合としてコミットできます。一部の資料が機微である場合、それらは非公開のまま、内容を公開せずに Merkle ルートを通じてコミットできます。あるいは封印して、暗号文をコンテンツアドレス指定ストレージに置き、鍵の保有者だけが復号できるようにもできます。封印付きレコードは、平文を読める相手を意図された受信者だけに限ります。ただしそれ自体が匿名性を保証するわけではなく、受信者は復号した後に平文を漏らすこともできます。

これにより、Label 309 は監査、インシデント対応、調達、顧客のセキュリティレビュー、そして長期のリリース証跡に役立ちます。

いつ Sigstore を使うべきか

ソフトウェアの成果物への署名と、ID に裏付けられた検証が必要なときは、Sigstore を使ってください。コンテナイメージ、バイナリ、パッケージへの署名、公開のオープンソースリリースのワークフロー、OIDC の ID を用いたキーレス署名、サプライチェーンの透明性、想定された署名者に基づく検証ポリシー、既存の配布ツールとの統合に、Sigstore はうってつけです。

Sigstore は、現代のソフトウェア署名のための強力な既定の選択肢です。

いつ Label 309 を使うべきか

証跡をめぐる、公開された、タイムスタンプ付きのコミットメントが必要なときは、Label 309 を使ってください。リリースマニフェストをチェーン上に記録する、脆弱性の公表よりも前に SBOM が存在していたことを証明する、リリース証跡集合にまたがる Merkle ルートをコミットする、封印したインシデント資料を保全する、顧客に納品した成果物一式を証明する、あるいは CI プロバイダーや成果物レジストリのダッシュボードがオンラインであり続けることに依存しない証明を保持する、といった用途です。

Label 309 は、署名の代わりではありません。それは時刻アンカーであり、証跡をコミットするためのフォーマットです。オープンソースの cardanowall CLI は、まさにこの種の自動化のために作られています。ゲートウェイに依存せず、生のシード（raw seed）を前提とする設計なので、ウェブサイトを介さずにパイプラインに組み込めます。全体の流れについては、自動化のなかで CLI を使うを参照してください。

どちらのシステムも証明しないことは何か

どちらのシステムも、ソフトウェアが安全であることは証明しません。

署名済みの成果物にも、依然として脆弱性が含まれていることはあります。タイムスタンプ付きの SBOM も、不完全なことがあります。ビルドログが、設定を誤ったパイプラインを記録していることもあります。リリースは、十分に文書化されていてもなお安全でないことがあります。

Sigstore と Label 309 は、完全性、ID、透明性、時刻、そして証跡の連続性を証明する助けになります。安全性そのものは、依然としてソースレビュー、ビルドの隔離、依存関係の管理、テスト、脆弱性対応、そして運用上の統制に依存します。証明が確立できることとできないことの一般的な限界については、証明が証明しないことを参照してください。

まとめ

ソフトウェアに署名し、署名イベントを透明にするには Sigstore を使ってください。リリース証跡（マニフェスト、ログ、各種の証明）を、どのベンダーもひそかに動かせない公開された Cardano の時刻にチェーン上で記録するには、Label 309 を使ってください。両者を組み合わせれば、ソフトウェアの来歴を後から検証することが格段に容易になります。

さらに読む

CI/CD のビルド証跡をチェーン上に記録する：ビルド証跡をハッシュ化し、バッチ処理し、公開するための完全なパイプラインのパターン。
何千ものファイルを 1 つのレコードに：単一の Merkle ルートが、任意の大きさの証跡集合をどのようにコミットするか。
自動化のなかで CLI を使う：cardanowall CLI を使って、パイプラインから公開と検証を実行する。
証明が証明しないこと：存在証明の、正直な限界。
Sigstore とそのドキュメント：キーレス署名、Fulcio の証明書、そして Rekor トランスペアレンシーログ。