ソフトウェアサプライチェーン来歴

ソフトウェアの「来歴（Provenance）」とは、「誰が・何のソースから・どのビルドシステムで・どの時点に」アーティファクトを生成したかを証明するメタデータである。来歴を暗号的に署名して配布することで、ダウンストリームの利用者はアーティファクトが改ざんされていないことを独立に検証できる。SLSA v1.0（2023 年公開）・in-toto・Sigstore の三層がこの技術スタックの中核を成す。情報カットオフ ~2025-08 のため、各仕様の最新バージョンや採用状況は 2026-05 時点で要確認。

Provenance（来歴）の重要性

従来のコード署名はアーティファクトの「出所（誰が署名したか）」を証明するが、「どのビルド環境で生成されたか」は保証しない。xz utils バックドア（ CVE-2024-3094、2024-03）は、信頼されたメンテナが正規のビルドプロセスを通じて悪意あるコードを注入した事例であり、出所の証明だけでは不十分であることを示している。

Provenance が必要とする情報の最小セット:

• Builder: ビルドを実行したシステム・プラットフォームの識別子
• Source: コミット SHA などビルド元のソース参照
• Dependencies: ビルドに使用した依存関係のダイジェスト
• Build environment: 環境変数・ツールチェーンのバージョン

SLSA v1.0（Supply-chain Levels for Software Artifacts）

SLSA（「サルサ」と発音）は 2023 年に v1.0 が公開されたビルド完全性フレームワークで、ビルドプロセスの信頼性をレベル 1〜3 で段階的に定義する。

SLSA v1.0 は Build Track と Source Track の 2 トラックに分離しており、まず Build Track（ L1〜L3）から実装するのが一般的。Provenance の記述形式として in-toto Attestation Framework を採用している。

in-toto Attestation Framework

in-toto はソフトウェアサプライチェーンの各ステップを暗号的に証明する attestation フレームワークで、CNCF プロジェクトとして標準化されている。

各ステップ（ソースチェックアウト・依存解決・ビルド・テスト・パッケージング）の実行者・入力・出力・コマンドを記述した「リンクメタデータ」を JSON 形式で生成し、署名する。ダウンストリームの利用者はポリシーを定義して「全ステップが期待通りに完了したか」を検証できる。

SLSA Provenance は in-toto Attestation の Predicate フィールドに slsa.dev/provenance/v1 として格納される形式を採る。

Sigstore（Cosign / Fulcio / Rekor）

Sigstore は PKI 管理の複雑さをなくした「keyless 署名」エコシステムで、3 つのコンポーネントから構成される。

Cosign

コンテナイメージ・アーティファクト・attestation の署名と検証を行う CLI ツール。OCI レジストリに署名をアーティファクトの隣に保存する。

keyless 署名では OIDC プロバイダ（ GitHub Actions / Google / Microsoft）のトークンを提示し、短命証明書で署名する。cosign sign --yes ghcr.io/org/image:tag の形で呼び出し、cosign verify で検証する。

Fulcio

OIDC ID トークンを提示することで、短命の X.509 証明書（有効期限 10 分）を発行する CA。長期的な秘密鍵の管理が不要になる（keyless の本質）。GitHub Actions では OIDC トークンが自動提供される。

Rekor

署名イベントを記録する不変の透明性ログ（ Merkle Tree ベース）。Certificate Transparency の署名版に相当し、署名が事後に削除・改ざんされていないことを証明する。Rekor への記録なしでは署名の否認が可能になる。

ビルド Provenance の実運用

GitHub Actions では actions/attest-build-provenance アクションで SLSA L2 相当の Provenance を生成できる。生成された attestation は GitHub の attestation API に保存され、gh attestation verify で検証可能。

Google Cloud Build・AWS CodeBuild などのホステッドビルドサービスも SLSA Provenance 生成の組み込み対応を進めており、SLSA L2 の達成が容易になっている（詳細な対応状況は 2026-05 時点で要確認）。

npm / PyPI / Maven Central など主要パッケージレジストリも Sigstore による署名検証の統合を進めており、pip install 時に自動的に Provenance を検証する仕組みが整いつつある。

Reproducible Builds（再現可能ビルド）

Reproducible Builds は「同一のソースとツールチェーンから常に同一バイト列のアーティファクトが生成される」ことを保証するビルド設計原則。タイムスタンプ・乱数シード・ファイルシステム順序などの非決定的要素を排除することで、第三者が独立してビルドを再現・比較できる。

Debian・ FreeBSD・ Tor Browser・ Nix/NixOS などが採用。ソースコードは公開されているがバイナリ配布を使う場合の完全性検証手段として機能する。SLSA と組み合わせることで「Provenance あり + 再現可能」という二重の保証が得られる。

アンチパターン