ソフトウェアサプライチェーン防御：SBOM・SLSA・署名検証の実装手順

イントロダクション：なぜ今、ソフトウェアサプライチェーン防御か

ライブラリ依存・CI/CDパイプライン・公開アーティファクトといった要素が複雑化する現代において、ソフトウェア供給網（Software Supply Chain）の可視化と整合性担保は必須です。本記事では「SBOM（Software Bill of Materials）で可視化」「SLSAでプロセスを硬化」「署名検証で配布の一貫性を担保」という3つの柱を、実務レベルの手順とチェックリストで示します。参考：CISA の最新SBOM指針（草案）や業界仕様を踏まえた実践的手順を解説します。

このガイドは開発チーム／CI運用者／セキュリティチームがすぐ使える実装手順を意図しています。各セクションは導入の目的、推奨ツール、CI統合例、運用上の落とし穴と対応策を含みます。

SBOM（部品表） — 可視化と実装の基本

目的：ソフトウェアに含まれるコンポーネント（直接・間接）を機械可読で記録し、脆弱性対応・ライセンス管理・サプライチェーンリスク評価を高速化します。

主なフォーマットと最新動向

• SPDX：業界の事実上の標準仕様（最新版は SPDX v2.3 が公開され、セキュリティ情報やハッシュアルゴリズムの拡張が行われています）。
• CycloneDX：セキュリティ向けに広く使われるフォーマット。フォーマット選定は受け手（サプライチェーンの参加者）との相互運用性を優先してください。

実装ステップ（短縮版）

1. 生成ポイントを決める：ビルド前（ソース解析）、ビルド時（バイナリ組立）、ビルド後（配布パッケージ）—どの段階でSBOMを出すかを定義します。
2. ツールを選ぶ：代表的なSBOMジェネレータ（例：Syft / CycloneDX CLI / SPDX互換ツール等）を選定。自動化スクリプトを用意してCIのビルドステップに組み込みます。
3. 出力フォーマットと署名：受け手に合わせてSPDX/CycloneDXなどを出力。生成物（SBOMファイル）に対して署名・一意ハッシュを付与して改ざん防止します。
4. VEX/Vulnerability Exchange：脆弱性影響情報（VEX）やパッチ情報と紐づけて自動的に脆弱性の影響度判定を行う仕組みを整備します。

運用のポイント

SBOMは "作って終わり" にしてはいけません。CIでの自動生成・アーティファクトとの紐付け、SBOMの保管場所（アーティファクトストアやSBOMリポジトリ）、更新ルールを運用ポリシーとして定義してください。CISAの2025年版ガイダンスは最小要素の更新を進めており、実装時にその指針を参照することを推奨します。

SLSA（Supply-chain Levels for Software Artifacts）でプロセスを硬化する

目的：ビルド工程とアーティファクトの信頼性をレベル化して段階的に強化し、改ざんや不正な挿入を防ぎます。

SLSAの要点

SLSAはビルドトラックを中心にレベル（L1〜L3など）で保証の強さを示します。低レベルは導入しやすい一方、高レベルはハードニングや署名されたプロビナンス（provenance）を要求します。SLSAの公式ドキュメントとレベル定義を参照し、自社のリスクに応じた到達目標を設定します。

実務的な導入手順

1. スコープ定義：どのプロジェクト／パイプラインを最初にSLSA化するかを決め、小さく始める（クリティカルなコンポーネント優先）。
2. プロビナンスを取得：ビルドごとに誰が、いつ、どの入力でビルドしたかを記録する仕組みを導入（例えば在室の署名・CI実行者のID、使用したソースのコミットIDなど）。
3. ビルド環境の分離と自動化：専用のビルドサービスやランナーを使い、アクセス制御とイミュータブルなビルド環境を用意します。
4. 検証/監査：外部／内部の検証によりSLSAレベルが満たされているかを定期チェック。レベルを段階的に上げる計画を立てます。

CI統合の指針

CIのビルドステップで必ずプロビナンス（attestation）とSBOMを出力し、アーティファクトに署名してアーティファクトレジストリへ格納します。SLSAコミュニティはv1.x 系の仕様と導入ガイドを公開しているため、実装要件とレベル定義を参照してください。

署名検証とアテステーション（Sigstore / Cosign / in-toto の活用）

目的：配布アーティファクト（コンテナイメージ、バイナリ、アーカイブ）に対する改ざん防止と発行者確認を自動化します。

Sigstore / Cosign の基本

Sigstore エコシステムは、キー管理や透明性ログ（Rekor）を組み合わせ、現代的なキー管理と "keyless"（OIDCに基づく）署名をサポートします。Cosign CLI を使った検証は現場で広く使われています。以下は検証の代表的なコマンド例です（実運用ではCIのステップに組み込んで自動化してください）。

cosign verify [--key <key path>|<key url>|<kms uri>] <image uri>

鍵レス署名（OIDC）やバンドル（transparency log の SET を含む）を使った検証方法、KMSキーの公開鍵取り出し方法などは公式ドキュメントを参照してください。

アテステーションと in-toto

ビルド工程の各ステップに関するアテステーション（誰がいつ何をしたか、どのツールを使ったか等）を in-toto などで記録し、署名と一緒に保管すると、SLSAの要件を満たす上で強力です。in-toto は CNCF のプロジェクトとして整備が進み、採用事例やガバナンスが成熟しつつあります。

CI実装例（高レベル）

1. ビルドジョブ: 依存解決 → バイナリ/イメージ作成 → SBOM生成（SPDX/CycloneDX）
2. アテステーション生成: in-toto/attestation を作成し、ビルドのメタデータを含める
3. 署名: cosign 等でアーティファクトを署名し、署名とアテステーションを透明性ログへ送信（または内部TUF等で管理）
4. 配布/デプロイ前検証: デプロイツールは配布前に署名とアテステーションを検証してから進める

運用上の注意点

• 検証ロジックはデプロイ側（受け手）に必ず組み込む。署名があっても検証を省略すると意味がありません。
• 鍵管理とローテーション、失効の設計を忘れないこと（KMS 連携を推奨）。
• 透明性ログ／TUF を併用すると、供給側・受領側双方の信頼性が向上します。

実践チェックリストと結論

以下は導入ロードマップと最低限のチェックリストです。

まとめ：SBOMで "何が入っているか" を把握し、SLSAで "どう作ったか" を強化、署名検証で "それが改ざんされていないか" を確認することで、実用的なサプライチェーン防御が成立します。最新の標準・ガイダンス（SPDX / CISA / SLSA / Sigstore）を参照して実装を進めてください。

追加資料や具体的なCIスニペットの要望があれば、対象の言語（例：GitHub Actions / GitLab CI / Jenkins）を指定してリクエストしてください。すぐにサンプルを作成します。