ISCサイバーサプライチェーン攻略｜供給者DD・SBOM・集中リスクを整理

1｜Third-party riskとC-SCRMの範囲を区別する

third-party risk managementは、委託先による情報漏えい、停止、法令違反、財務悪化など幅広いリスクを扱います。cybersecurity supply chain risk managementは、その中でもICT製品・サービスが設計、開発、統合、配布、導入、保守、廃棄される経路から生じるサイバーリスクへ焦点を当てます。

供給者が一社でも、その製品にはオープンソース部品、開発委託先、クラウド基盤、署名鍵、更新配布網など複数階層があります。契約先だけを評価し、下位依存を見ない方法では、悪意ある部品、脆弱な開発、偽造品、更新経路の侵害を捉えられません。

2｜最初に重要度と評価範囲を決める

すべての供給者へ同じ質問票を送るのではなく、扱うデータ、権限、ネットワーク接続、業務停止影響、代替可能性、規制要件を使って重要度を分類します。特権アクセスや本番データを持つ供給者、単一障害点となる製品には深い評価が必要です。

評価範囲には、親会社だけでなく、提供製品、重要コンポーネント、開発・配布拠点、下請先、クラウドリージョン、保守終了日を含めます。スコープが曖昧なまま大量の証拠を集めても、重要な依存を見落とします。

• データの機密性・完全性・可用性
• 管理者権限とネットワーク接続
• 停止時の業務影響とRTO・RPO
• 代替供給者への切替可能性と所要時間
• 下位供給者・地域・共通基盤への集中

3｜NIST SP 1326の5要素でDue diligenceを作る

NISTが2026年7月に公開したSP 1326は、ICT供給者のデューデリジェンスを、Foreign Ownership, Control, or Influence（FOCI）、Provenance、Resilience、Foundational Cyber Practices、Supply Chain Tiersの5要素で整理しています。

FOCIでは所有・支配構造と関連リスク、Provenanceでは製品・部品・開発経路の来歴、Resilienceでは供給中断への耐性、Foundational Cyber Practicesでは基礎的なセキュリティ実務、Supply Chain Tiersでは下位供給網の可視性を調べます。一項目だけで合否を決めず、取得目的とリスク許容度に照らして総合判断します。

• FOCI：所有・支配・影響と関連する法域・主体
• Provenance：製品・部品・開発・流通の来歴
• Resilience：中断・侵害・供給不足からの回復力
• Foundational Cyber Practices：安全な開発、脆弱性対応、アクセス・更新管理
• Supply Chain Tiers：直接契約先より下の依存関係

4｜認証・SOC・質問票を「目的に合う証拠」へ変える

SOC報告書、ISO認証、侵入テスト要約、方針、質問票は有用ですが、一つだけで供給網全体のリスクを証明しません。対象システム、対象期間、例外、subservice organization、利用会社相補統制を読み、取得対象と一致するか確認します。

回答だけでなく、構成一覧、パッチ履歴、インシデント通知例、事業継続テスト、アクセスレビュー、secure developmentの実施記録など、主張を裏付ける証拠をリスクに応じて求めます。証拠の古さと対象範囲も記録します。

5｜SBOMを受け取った後のプロセスまで設計する

SBOMは、ソフトウェアに含まれる部品、バージョン、依存関係の可視化を助けます。しかしSBOMがあるだけで各部品が安全になるわけではなく、新しい脆弱性が公表された後も自動的に是正されるわけではありません。

受領したSBOMを資産・構成管理へ取り込み、脆弱性情報と照合し、影響する製品と業務を特定し、供給者の修正計画を追跡します。版更新時に新しいSBOMを取得し、差分を確認します。完全性、鮮度、形式、アクセス制限、保存期間も統制対象です。

6｜契約へ実行可能な統制を落とし込む

デューデリジェンスで発見したリスクは、契約条件、補完統制、受容、回避などの対応へつなげます。契約には、最低セキュリティ要件、脆弱性修正期限、インシデント通知、監査・証拠提出、データ所在地、下請先変更、BCPテスト、データ返却・消去などを、重要度に応じて定めます。

『業界標準を守る』だけでは履行を検証しにくいため、対象、期限、責任者、証拠、例外承認を具体化します。ただし契約権があっても実際に証拠を受け取り、例外を追跡しなければ運用統制にはなりません。

• 重大インシデントの通知時間と連絡経路
• 重大度別の脆弱性是正期限と例外承認
• SBOM・構成変更・下請先変更の通知
• アクセス権、ログ、暗号化、バックアップの責任分担
• 終了時のデータ返却・消去証明とアクセス失効

7｜契約後は変化を監視し、再評価へ戻す

供給者の買収、財務悪化、重大脆弱性、製品のEOL、下請先変更、データ所在地変更、統制例外などは契約期間中に起こります。重要供給者について、脅威情報、外部評価、SOC報告書、SLA、パッチ状況、インシデント、例外是正を継続監視します。

指標は件数だけでなく、重大脆弱性の期限内是正率、未解決例外の経過日数、バックアップ復元テスト、インシデント通知の適時性など、統制目的へ結び付けます。基準超過時のエスカレーションと、リスク受容の期限も定めます。

8｜集中リスクとExitを個別供給者評価から分ける

各供給者が単独では許容可能でも、複数の重要サービスが同じクラウド地域、ID基盤、ネットワーク、ソフトウェア部品へ依存すると相関障害が起きます。供給者台帳を集約し、共通依存と単一障害点を可視化します。

終了計画では、データ移行、代替製品、設定・鍵・ログの引継ぎ、アクセス失効、媒体消去、並行稼働、復旧テストを確認します。契約終了日になってから代替策を考えるのではなく、取得時にexit feasibilityを評価し、重要サービスでは定期的に切替手順をテストします。

9｜ISC問題を解く7ステップ

供給者認証や契約条項が一つ見つかっても、その選択肢だけで安心と判断しません。取得前から終了までのどの段階が欠けているかを確認します。

• ① 対象業務・データ・権限・停止影響を特定する
• ② 供給者、製品、下位供給網の評価範囲を決める
• ③ FOCI・Provenance・Resilience・基礎実務・供給網階層を確認する
• ④ 証拠の対象・期間・例外が取得対象と一致するか
• ⑤ 契約要件と自社の補完統制へ落とし込む
• ⑥ 変更・脆弱性・SLA・例外を継続監視する
• ⑦ 集中リスクと安全な終了・移行を集約評価する