サプライチェーンセキュリティは、委託先と依存関係の把握から

委託先の一覧はあっても、「どの業務が、何に依存しているか」まで答えられるでしょうか。サプライチェーンセキュリティでは、取引先や利用サービス、ソフトウェアの依存を通じて自社へ及ぶ影響を考えます。すべての相手を同じ深さで調べるより、止められない業務と機密性の高い情報から確認する方が、着手する対象を絞れます。

この記事では、公式資料の考え方を踏まえ、企業内で確認する項目を編集部の実務例として整理します。

重要な業務から依存先をたどる

NIST SP 800-161 Rev.1（2024年11月1日の更新を含む版）は、調達する製品やサービスの開発・統合・運用への可視性が不足するリスクを扱っています。相手のセキュリティだけでなく、自社が何を任せているかも評価の出発点です。

まず一つの重要業務を選びます。受注なら販売管理、認証、クラウド、運用委託先というように、停止や侵害で影響する依存先をたどります。委託先の社名だけの一覧に、情報と権限、社内の責任者を加えてください。

この表は整理用の例です。契約条件や機密性に応じて、共有する範囲を決めてください。

チェックシートは証跡とセットにする

取引先の質問へ「実施済み」と答えるときは、いつ、誰が、何を確認したかも説明できる状態にします。多要素認証なら対象アカウントと例外、バックアップなら取得設定と復元確認の記録が確認材料になります。規程の有無と、現場での運用は別々に確かめます。

NIST CSF 2.0のサプライチェーン向けクイックスタートガイド（SP 1305）は、供給者との関係をリスク管理へ組み込む手掛かりになります。以下は、その考え方を社内の確認へ落とすための提案です。

• 事故の連絡先と、連絡する条件を確認する。
• 調査、封じ込め、復旧、顧客への説明を誰が担うか整理する。
• 契約変更・終了時に、アクセス権を止め、データの返却・削除を確認する。
• 不明な回答は「未確認」と残し、確認する人と期限を決める。

国内の制度を調べる場合は、IPAのSCS評価制度の公式ページで更新された資料を確認してください。ここでは取得義務や特定の評価への適合を判断しません。取引先の要請、契約、最新の制度資料を分けて確認することが必要です。

ソフトウェアの依存も運用に組み込む

開発組織では、外部のライブラリや配布物、ビルド環境も依存先です。ソフトウェアの構成を記録した一覧であるSBOMは、脆弱性情報と照合する材料になります。ただし、一覧を作るだけでは、利用箇所や修正担当、実際の影響は決まりません。

主要なライブラリの利用箇所、更新担当、サポート状況、更新を検証する手順を結び付けます。依存更新の通知が開発者の個人メールで止まるなら、チームの確認場所と担当を決めることから始められます。具体的な優先順位は脆弱性対応の実務ガイドで扱います。

最初の一社・一業務から始める

最初に確認する委託先を一社選び、扱う情報、アクセス権、停止時の影響、事故時の連絡先、契約終了時の処理を一枚にまとめてみてください。未知の項目が残ったら、担当者と確認期限を付けます。

「チェックシートは担当任せになっている」「委託先への確認事項を絞れない」という場合は、その状況が相談の材料になります。初回は取引先の機密資料を送らず、業務と課題の概要をお知らせください。

参照資料と確認日

資料確認：2026年10月9日。NIST SP 800-161は更新版を参照しています。SCS評価制度は資料が更新されるため、要請を受けた時点で再確認してください。

• NIST SP 800-161 Rev.1：サプライチェーンリスク管理
• NIST SP 1305：CSF 2.0 サプライチェーン向けガイド
• IPA：サプライチェーン強化に向けたセキュリティ対策評価制度