ソフトウェアサプライチェーンセキュリティ入門：何を学び、どのツールで検証するか

ソフトウェアサプライチェーンセキュリティは、自分が書いたコードだけを検査するものではありません。外部ライブラリ、ビルドサーバー、CI/CDワークフロー、コンテナイメージ、レジストリ、デプロイポリシーに至るまで、コードが製品となり運用環境に到達するまでのすべてのつながりの信頼を管理することです。

そのため、脆弱性スキャナーを一つ導入しただけで終わりではありません。何が導入されたかのリストを作成し、誰がどのような環境でビルドしたかを証明し、承認された成果物のみがデプロイされるように阻止し、問題が発生した際には影響を迅速に追跡する必要があります。この記事では、その流れを学習順序と小さな実習プロジェクトに結びつけます。

ソースと依存関係がビルド・署名・レジストリ検証を経て安全にデプロイされるソフトウェアサプライチェーン

まず、誤解を解く：サプライチェーンセキュリティは脆弱性スキャンではない

Log4Shellのように、すでに知られている脆弱なライブラリを見つけることは重要です。しかし、正規のライブラリの配布アカウントが乗っ取られたり、名前が似た悪意のあるパッケージを開発者がインストールしたり、ビルド段階で成果物が改ざんされたりした場合、CVEリストだけでは検出が困難です。

NISTは、サイバーセキュリティサプライチェーンリスク管理（C-SCRM）を、設計・開発・デプロイ・取得・運用・廃棄に至る全ライフサイクルにおけるリスクを特定・評価・軽減する活動と説明しています。ソフトウェアに絞ると、次の5つの質問が核心となります。

何が入ったか？ 直接・間接の依存関係とライセンスを把握しているか？
どこから来たか？ ソース、パッケージ、ベースイメージ、サプライヤーを追跡できるか？
どのように作られたか？ ビルドプロセスと入力を証明できるか？
改ざんされていないか？ 成果物の署名とダイジェストをデプロイ前に検証しているか？
問題が発生した場合に見つけられるか？ 影響を受けるサービスとデプロイ版を迅速に特定できるか？

まず全体像を描いてみよう

サプライチェーンは、ソース → 依存関係 → ビルド → 成果物 → レジストリ → デプロイと続きます。各段階には異なる証拠が必要です。


段階	代表的なリスク	残すべき証拠	代表的な制御

—	—	—	—
ソース	アカウント乗っ取り、不正な変更	コミットとレビュー記録	ブランチ保護、MFA、CODEOWNERS
依存関係	悪意のあるパッケージ、依存関係の混乱	Lockfile、SBOM	バージョン固定、プライベートレジストリの優先順位
ビルド	CI権限の誤用、ビルド中の改ざん	ビルドログ、Provenance	隔離されたビルド、最小権限、ワークフロー固定
成果物	イメージの置き換え、タグの再利用	ダイジェスト、署名、Attestation	Cosignによる署名・検証
デプロイ	未承認イメージの実行	承認・ポリシーログ	Admission Policy、ダイジェストデプロイ
運用	後から公開された脆弱性	デプロイ版とSBOMの連携	再スキャン、VEX、影響分析

SBOM（Software Bill of Materials）は、ソフトウェアに含まれる構成要素のリストです。SPDXとCycloneDXが代表的な形式です。Provenanceは、「この成果物がどのようなソースとビルドプロセスで作られたか」を説明する証明資料です。両者は代替関係ではありません。SBOMが材料表だとすれば、Provenanceは製造履歴に近いものです。

何をどのような順序で学ぶべきか

ステップ1：依存関係グラフと信頼境界

まず、直接依存関係と推移的依存関係の違い、パッケージリポジトリの優先順位、Lockfileの役割を理解します。npm、PyPI、Mavenのような公開リポジトリと社内リポジトリが交わる点が重要な信頼境界です。バージョンを固定しても、すでに悪意のあるバージョンを固定してしまう可能性があるため、「固定したから安全だ」という結論は禁物です。

ステップ2：SBOMと脆弱性情報

ソースディレクトリと最終コンテナイメージからそれぞれSBOMを作成し、その違いを比較します。Syftは、ディレクトリ・イメージ・アーカイブから構成要素を識別し、SPDXやCycloneDX形式でエクスポートできます。Grype、Trivy、OSV-Scannerは、これらの構成要素を既知の脆弱性情報と照合するために使用できます。

スキャン結果は判決文ではなく、調査リストです。実行パスに到達するか、実際にデプロイイメージに含まれているか、補完的な制御があるかを確認し、例外には担当者・理由・有効期限を記録する必要があります。

ステップ3：ビルドの完全性とSLSA

SLSA（Supply-chain Levels for Software Artifacts）は、サプライチェーン保証を段階的に高めるための仕様です。2026年9月現在承認されているSLSA 1.2のBuild Trackは、Provenanceの存在、ホストされたビルドプラットフォームが生成した署名付きProvenance、強化されたビルド環境によって保証レベルを分けています。

最初から最高レベルを宣言するのではなく、「どのような脅威を防ぐためにどのレベルの証拠が必要か」を定めます。CI内でアプリケーションが自分自身に関する証明書を自由に作成させず、信頼できるビルド制御レイヤーがProvenanceを生成する理由もここにあります。

ステップ4：署名と検証

SigstoreのCosignは、OCIイメージやその他の成果物の署名・検証、Attestation作業に使用されます。重要なのは署名コマンドよりも検証ポリシーです。デプロイ段階で信頼できる発行者、OIDC発行者、リポジトリ、ワークフロー条件を確認しなければ、署名ファイルがあっても承認制御は機能しません。

運用では、変更可能なタグよりもイメージDigestを基準にデプロイし、署名検証が失敗した場合は実行を拒否するようにします。Kubernetesであれば、KyvernoやOPA Gatekeeperのようなポリシーエンジンをデプロイゲートに接続できます。

ステップ5：CI/CDと対応手順

ワークフロートークンは、デフォルトの読み取り権限で開始し、必要なタスクにのみ書き込み権限を付与します。外部CIアクションは、変更可能なタグではなく、レビュー済みのコミットSHAに固定し、長期的な秘密鍵の代わりに、可能な範囲で短命の資格情報を使用します。

最後の学習テーマはインシデント対応です。新しいCVEや悪意のあるパッケージが発見された際に、どの製品とデプロイ版が影響を受けるかをSBOMで探し、修正ビルドを作成し、新しい署名とProvenanceを検証した後に再デプロイするプロセスを練習する必要があります。

ツールは役割別に選ぶ


目的	ツール・標準	得意なこと	注意点

—	—	—	—
SBOM生成	Syft, Trivy	ディレクトリ・イメージの構成要素リスト化	欠落の有無と生成時点を検証する必要がある
SBOM形式	SPDX, CycloneDX	組織・ツール間で交換可能な表現	形式だけ作成し保管しなければ有用性が低い
脆弱性検出	Grype, Trivy, OSV-Scanner	パッケージと既知の脆弱性のマッチング	実行可能性・環境コンテキストは別途判断
リポジトリ衛生	OpenSSF Scorecard	ブランチ保護、トークン権限などヒューリスティックチェック	合計点だけで安全性を判断しない
署名・検証	Sigstore Cosign	OCI成果物の署名とIDベースの検証	デプロイ時点での検証ポリシーも必要
ビルド証明	SLSA, in-toto	ビルド入力・過程・成果物のProvenanceとAttestation	宣言と実際のビルドプラットフォーム保証を区別
デプロイポリシー	Kyverno, OPA Gatekeeper	未署名・ポリシー違反成果物のブロック	緊急例外手順と監査ログが必要

一つの製品で表全体を埋めようとしない方が良いでしょう。例えば、Trivyが複数の検査をサポートしていても、SBOM標準、ビルドProvenance、署名信頼ポリシーまで自動的に解決してくれるわけではありません。

4週間の実習プロジェクト：小さなコンテナを最後まで保護する

学習用プロジェクトには、API一つとコンテナイメージ一つで十分です。目標は、多くのツールをインストールすることではなく、検証可能な証拠と遮断ポイントを一つずつ追加することです。

1週目：ベースラインの作成

アプリケーションのソース、パッケージリポジトリ、CI、レジストリ、デプロイ環境を一枚の図に描く。
直接・推移的依存関係とベースイメージを記録する。
保護ブランチ、レビュー規則、CIトークン権限と外部アクションの固定状況を点検する。
完了基準：任意の変更がどの経路で運用イメージに到達しうるかを説明できること。

2週目：SBOMと脆弱性ゲート

SyftまたはTrivyでソースと最終イメージのSBOMをそれぞれ生成する。
Grype、Trivy、またはOSV-Scannerで結果をスキャンする。
深刻度だけでなく、実際の含まれ方、到達可能性、修正バージョン、例外の有効期限を記録する。
完了基準：特定のパッケージを入力すると、どのイメージとサービスにデプロイされたかを見つけられること。

3週目：署名とProvenance

イメージをタグではなくDigestで識別する。
CIが作成したイメージにCosignで署名し、別途検証段階で発行者条件を確認する。
ビルド入力とビルダーを説明するSLSA Provenanceまたはin-toto Attestationを保管する。
完了基準：ローカルで任意に作成された同名のイメージは検証を通過できないこと。

4週目：デプロイ遮断とインシデント訓練

テストKubernetesクラスターに未署名イメージを拒否するポリシーを適用する。
正常なイメージ、未署名イメージ、署名後に改ざんされたイメージの3種類をデプロイし、結果を比較する。
脆弱なパッケージが新たに公表されたと仮定し、影響調査から修正・再署名・再デプロイまでの時間を計測する。
完了基準：遮断ログと承認例外が監査可能な形式で残ること。

実習は別途テストリポジトリとクラスターで実施します。公開レジストリに秘密情報や内部SBOMをアップロードせず、自動修正コマンドは信頼できないプロジェクトでパッケージインストールスクリプトを実行する可能性があるため、まず動作を確認してください。

CIパイプラインに含めるべき最小限のゲート

소스 검증
  → 의존성 설치와 테스트
  → 이미지 빌드
  → SBOM 생성
  → 취약점 정책 평가
  → 이미지 Digest 확정
  → 서명·Provenance 발행
  → 배포 전 신원·서명 검증
  → 승인된 Digest만 배포

スキャン失敗をすべてビルド失敗にすると、例外が乱発される可能性があります。逆に警告だけが積み重なるとゲートとは言えません。例えば、「悪用可能性が確認された致命的な脆弱性は遮断し、残りは期限付きの例外チケットで管理する」のように、組織のリスク基準を機械が判定できるルールに変換する必要があります。

よくある失敗パターン

SBOMを一度作成して終わりにする。 デプロイ版と連携しなければ、後で影響を追跡するのが難しい。
スキャナーのスコアだけを信じる。 パッケージの出所、ビルドの改ざん、アカウント乗っ取りには別途の制御が必要。
イメージタグを信頼する。 タグは変更される可能性があるため、Digestと署名検証が必要。
CIに広範な権限を与える。 ビルドシステムはサプライチェーンの強力なハブであるため、最小権限と隔離が重要。
署名するだけで検証しない。 ポリシー施行地点がなければ、署名は参考資料にとどまる。
例外に有効期限がない。 一時的な許可が恒久的なポリシーとして定着する。

現実的な出発点

サプライチェーンセキュリティの最初の目標は、「完璧な製品」ではなく、どのようなソースと依存関係がどのようなビルドを経て現在どこにデプロイされたかを証明できる状態です。その上に、脆弱性対応、署名検証、デプロイ遮断を順次追加していきます。

今週は、サービスを一つ選び、ソースと最終イメージのSBOMを作成し、その違いを比較してみましょう。来週は、同じイメージのDigestを固定し、署名検証を付加します。最後に、未署名イメージが実際のデプロイ段階で拒否されるかを確認します。この3つのステップが連結されれば、サプライチェーンセキュリティは抽象的なスローガンではなく、反復可能なエンジニアリング手順となります。

公式参考資料

カテゴリ: 一般IT/ITセキュリティ

タグ: サプライチェーンセキュリティ, ソフトウェアサプライチェーン, SBOM, SLSA, Sigstore, Cosign, DevSecOps