情シス向けサプライチェーン攻撃リスク入門

• サプライチェーン攻撃は、自社の境界防御だけでは見えにくい「委託先、クラウド、SaaS、開発ツール、OSS、保守運用」の弱点から波及するリスクです。
• IPAの「情報セキュリティ10大脅威 2026」では、組織向け脅威の2位に「サプライチェーンや委託先を狙った攻撃」が挙げられています。
• 情報システム担当者は、取引先にチェックシートを送るだけでなく、重要業務とのつながり、アクセス権、データの流れ、インシデント時の連絡経路を棚卸しする必要があります。
• 委託先への要求は、強く求めればよいわけではありません。NCOの法令Q&Aが示すとおり、セキュリティ要求は社会全体に資する一方、優越的地位の濫用や下請法への配慮も必要です。
• まずは「重要な委託先を特定する」「契約と運用の責任分界を確認する」「アクセス権を最小化する」「検知と連絡の手順をそろえる」ことから始めるのが現実的です。

この記事の前提と読み方

この記事は、情報システム担当者がサプライチェーン攻撃のリスクを初めて体系的に整理するときの入門ガイドです。対象は、大企業のセキュリティ専任部門だけではありません。兼任情シス、社内IT、ベンダー管理、クラウド管理、委託先との契約更新に関わる担当者も想定しています。

ここで扱う「サプライチェーン」は、製造業の部品調達だけを意味しません。IT分野では、SaaS、業務委託先、保守ベンダー、開発会社、クラウド基盤、OSSライブラリ、CI/CD、リモート保守、データ連携先まで含めて考える必要があります。NCOのサイバーセキュリティ関係法令Q&Aも、IT分野では設計、運用、保守、廃棄を含めてサプライチェーンと呼ばれることがあると説明しています。Source: NCO

本記事は、IPA、NIST、NCO、経済産業省の一次情報を確認し、情報システム部門が実務で使いやすい判断軸に整理したものです。特定の製品やサービスの導入可否を断定するものではなく、各社の業務重要度、契約条件、法務判断、セキュリティ体制に合わせて調整してください。

なぜ今、サプライチェーン攻撃リスクを見るべきか

サプライチェーン攻撃が厄介なのは、攻撃者が必ずしも自社を正面から狙わない点です。自社のVPN、メール、Webサイトを固めていても、委託先の保守端末、SaaSの管理者権限、ソフトウェア更新経路、開発パイプライン、外部連携APIが侵害されれば、自社の業務や情報に影響が及びます。

IPAは「情報セキュリティ10大脅威 2026」で、組織向け脅威の2位として「サプライチェーンや委託先を狙った攻撃」を掲載しています。公開日は2026年1月29日、最終更新日は2026年4月10日です。同ページでは、この脅威が2019年に初選出され、8年連続で取り扱われていることも示されています。Source: IPA

サプライチェーンや委託先を狙った攻撃

出典: IPA 情報セキュリティ10大脅威 2026

この短い脅威名から読み取るべき点は、「サプライチェーン」と「委託先」が分けて表現されていることです。つまり、攻撃経路は購買先や外注先だけではありません。社内システムに接続する保守会社、利用中のクラウドサービス、ソフトウェア更新を担うベンダー、開発工程に入る外部ライブラリなど、IT運用のあらゆる依存関係が対象になります。

経済産業省のサイバーセキュリティ経営ガイドラインVer.3.0でも、サプライチェーンを介した被害拡大を踏まえ、サプライチェーン全体を通じた対策推進の必要性が説明されています。情報システム担当者にとっては、「自社の資産管理」から「自社が依存する外部の管理」へ視野を広げることが求められていると言えます。

サプライチェーン攻撃の典型経路を整理する

最初に行うべきことは、攻撃手口を細かく暗記することではありません。自社のどこに外部依存があり、そこから何が起きるかを分類することです。以下の表は、情報システム部門が棚卸しで使いやすいよう、主要な経路を業務影響と確認観点に分けたものです。

この表で重要なのは、委託先の「会社名」ではなく、「どの業務にどの権限で関与しているか」を見ることです。たとえば、同じ保守会社でも、年1回の帳票修正だけを行う場合と、常時VPNで基幹DBに接続できる場合ではリスクがまったく違います。

また、攻撃者の目的は情報窃取だけではありません。NCOは、マルウェア混入、情報流出、部品調達への支障、情報システムの停止、他社の二次被害誘発などをサプライチェーン・リスクの例として整理しています。Source: NCO
情報システム担当者は、機密性だけでなく、可用性、完全性、取引先への波及も同時に見なければなりません。

リスク評価は「重要業務から逆算」する

サプライチェーン攻撃対策で失敗しやすいのは、全委託先に同じ質問票を送り、回答の有無だけで管理した気になることです。質問票は入口として有効ですが、業務影響と結びついていなければ優先順位がつきません。

NIST SP 800-161 Rev.1は、組織がサプライチェーン全体のサイバーセキュリティリスクを識別、評価、軽減するためのガイダンスです。同文書は、C-SCRMをリスク管理活動に統合し、戦略、方針、計画、製品・サービスのリスク評価へつなげる考え方を示しています。Source: NIST

情シスが実務で使うなら、次の順で考えると整理しやすくなります。

1. 止められない業務を決める
   受注、出荷、決済、顧客対応、認証基盤、会計、医療・公共系サービスなど、停止時の影響が大きい業務を先に特定します。

2. 業務を支える外部依存を洗い出す
   SaaS、クラウド、保守会社、開発会社、ネットワーク事業者、データ処理委託先、OSS、認証連携先を並べます。

3. 外部依存ごとの権限とデータを確認する
   閲覧だけか、更新できるか、管理者権限があるか、個人情報や機密情報を扱うか、リモート接続があるかを見ます。

4. 事故時の検知と遮断を確認する
   ログが取れるか、異常を誰が見るか、連絡先が最新か、接続停止やアカウント停止を何分でできるかを確認します。

5. 契約と運用のギャップを埋める
   契約上は通知義務があっても、現場の連絡先が古い、夜間対応がない、再委託先が見えない、といったギャップを潰します。

この流れなら、サプライチェーン攻撃リスクを「全社的で大きすぎる問題」ではなく、「重要業務に紐づく外部依存の管理」に分解できます。CISOや経営層へ説明するときも、抽象的な脅威ではなく、止まる業務、漏れる情報、復旧に必要な判断として伝えやすくなります。

委託先管理はセキュリティ要求と取引配慮を両立する

委託先にセキュリティ対策を求めること自体は、サプライチェーン全体のリスクを下げるうえで重要です。ただし、情報システム部門だけで一方的な要求を設計すると、購買、法務、事業部、委託先の実務負荷との衝突が起きます。

NCOのサイバーセキュリティ関係法令Q&Aは、一定のサイバーセキュリティ対策を取引条件としたり、取引先に求めたりすることは社会全体のサイバーセキュリティ対策に資する一方、優越的地位の濫用や下請法に留意すべき場合があると説明しています。Source: NCO

実務では、次のように段階を分けると無理が少なくなります。

ここでのポイントは、委託先を「監査対象」としてだけ見るのではなく、自社の業務継続を支えるパートナーとして扱うことです。重要委託先には要求水準を明確にする一方、中小の委託先には代替策や段階的な改善計画を提示する方が、実効性が高い場合があります。

内閣サイバーセキュリティセンター側でも、SCS評価制度の検討資料が公開されています。同資料では、★3、★4、★5の成熟度や、評価スキームの考え方が整理されています。Source: NISC/NCO
制度の詳細は今後も更新される可能性がありますが、取引先の対策状況を共通のものさしで見える化する流れは、情シスの委託先管理にも影響します。

まず整えるべき技術対策と運用対策

サプライチェーン攻撃対策は、専用製品を入れれば終わる話ではありません。むしろ、既存のID管理、ログ管理、資産管理、契約管理、インシデント対応を外部依存まで広げる取り組みです。

最初に優先したい技術対策は、外部から自社環境へ入る経路の可視化です。保守VPN、リモートデスクトップ、SaaS管理画面、クラウドIAM、APIキー、CI/CDのシークレット、ファイル共有の外部ユーザーを一覧化します。そのうえで、MFAの有無、共用IDの有無、権限の強さ、ログ取得の有無、停止手順を確認します。

次に、ソフトウェア供給網の管理です。自社開発や委託開発がある場合、OSSや外部ライブラリの依存関係を把握しなければ、脆弱性対応の優先順位がつきません。SBOMは万能ではありませんが、少なくとも「どの部品を使っているか」を説明するための基礎になります。外部公開システム、認証処理、決済、個人情報処理に関わる部品から優先して管理するとよいでしょう。

運用対策としては、連絡経路の整備が軽視されがちです。委託先でインシデントが起きたとき、自社は誰から、どの経路で、何時間以内に、どの情報を受け取るのか。逆に自社で異常を検知したとき、委託先の誰に接続停止や調査依頼を出すのか。契約書に書かれていても、現場の担当者表や夜間連絡先が古ければ機能しません。

以下は、初期対応で使える簡易チェックリストです。

• 重要委託先と重要SaaSを、業務影響順に10件程度まで絞って一覧化する。
• 各委託先が扱うデータ、接続先、権限、再委託の有無を記録する。
• 管理者権限、保守権限、APIキー、共有リンクを棚卸しする。
• 外部接続にMFA、接続元制限、個人別ID、ログ保存があるか確認する。
• 契約にインシデント通知、再委託通知、データ削除、ログ協力が含まれるか確認する。
• 委託先障害時の代替手順、手作業手順、停止判断者を決める。
• 年1回ではなく、重要委託先は担当者変更や構成変更のタイミングでも確認する。

これらは地味ですが、攻撃を完全に防げない場合でも、侵害範囲を狭め、検知を早め、復旧判断を速くする効果があります。

経営層・事業部へどう説明するか

情報システム担当者がサプライチェーン攻撃リスクを社内で説明するとき、「危険です」「対策が必要です」だけでは予算や協力を得にくいのが現実です。経営層や事業部には、セキュリティ用語ではなく、事業影響で説明する必要があります。

たとえば、次のように言い換えると伝わりやすくなります。

• 「委託先が侵害されるリスク」ではなく、「出荷管理システムに外部保守経路があり、停止すると翌営業日の出荷に影響する」
• 「SaaSの管理者権限が危険」ではなく、「顧客情報を扱うSaaSで管理者が5名おり、退職者確認とMFA強制が未完了」
• 「OSS脆弱性が怖い」ではなく、「外部公開サービスで利用中のライブラリ更新責任が委託契約に明記されていない」
• 「インシデント通知が必要」ではなく、「委託先事故時に当社が顧客へ説明するための一次情報を何時間で受け取れるか未定」

経済産業省のサイバーセキュリティ経営ガイドラインは、経営者のリーダーシップの下でサイバーセキュリティ対策を推進するため、経営者が認識する3原則と担当幹部に指示すべき重要10項目をまとめたものです。情シスは、経営判断が必要な事項と、現場で改善できる事項を分けて提示すると、議論を前に進めやすくなります。

特に、取引条件の見直し、追加費用、監査対応、代替ベンダー検討、重要委託先への要求水準設定は、情報システム部門だけでは決められません。購買、法務、事業責任者、経営層を巻き込み、リスクを受け入れるのか、低減するのか、移転するのか、回避するのかを明確にする必要があります。

情シス向けの導入ステップ

初めて取り組む場合は、全社一斉の大規模プロジェクトにしない方が成功しやすいです。まずは重要業務を1つ選び、その業務を支える外部依存を洗い出す小さな範囲から始めます。

1. 対象業務を1つ決める
   例として、販売管理、EC、顧客管理、認証基盤、給与、受発注などを選びます。基準は「止まると困る」「漏れると困る」「改ざんされると困る」です。

2. 外部依存マップを作る
   対象業務に関係するSaaS、クラウド、保守会社、開発会社、データ連携先、外部ライブラリを線でつなぎます。図がなくても、表で十分です。

3. リスクを3段階で仮評価する
   高、中、低で構いません。権限が強い、個人情報を扱う、停止影響が大きい、代替がない、ログがない、再委託が見えない場合は高めに置きます。

4. すぐ直せる統制を実施する
   退職者アカウント削除、MFA必須化、共有ID廃止、接続元制限、管理者権限削減、APIキー更新、連絡先更新など、契約変更なしでできるものから始めます。

5. 契約・体制が必要な課題を分ける
   通知義務、再委託管理、監査協力、ログ提供、セキュリティ要求水準、費用負担は、購買や法務と一緒に扱います。

この進め方なら、セキュリティ部門がない組織でも取り組みやすくなります。最初の成果物は、立派な規程ではなく「重要業務ごとの外部依存一覧」と「高リスク依存先への改善チケット」で十分です。

よくある質問

十分とは言えません。チェックシートは現状把握には役立ちますが、回答の真正性、運用実態、業務影響、事故時の対応力までは確認しきれません。重要委託先については、契約、アクセス権、ログ、連絡訓練、変更管理まで見る必要があります。

一律要求は現実的でない場合があります。重要度の高い業務やデータに関わる委託先には強い要求が必要ですが、要求水準は業務影響、権限、データ種別、代替可能性で変えるべきです。NCOが示す法的留意点も踏まえ、購買・法務と連携して進めることが重要です。

まずは外部接続と管理者操作のログです。VPN、クラウドIAM、SaaS管理画面、保守アカウント、API利用、CI/CD、ファイル共有の外部アクセスを優先します。ログを取っていても、保存期間が短い、誰も見ていない、委託先にしかない場合は対応が遅れます。

待つべきではありません。制度開始前でも、重要委託先の把握、権限管理、契約確認、インシデント連絡体制の整備は進められます。制度は共通尺度として参考にしつつ、自社の業務影響に基づく管理を先に始めるのが安全です。

まとめ

サプライチェーン攻撃リスクは、特別な大企業だけの課題ではありません。情報システム担当者が日々管理しているSaaS、保守接続、委託開発、クラウド、OSS、データ連携の延長線上にあります。

まず見るべきものは、外部依存の数ではなく、重要業務との結びつきです。止まると困る業務、漏れると困る情報、改ざんされると困る処理から逆算し、外部の誰が、どの権限で、どのデータやシステムに触れているかを把握します。そのうえで、MFA、最小権限、ログ、接続停止、連絡経路、契約条項を整えます。

IPA、NIST、NCO、経済産業省の一次情報を見ると、共通しているのは「サプライチェーンリスクを単発の技術対策ではなく、リスク管理、契約、運用、経営判断に組み込む」という考え方です。情シスの役割は、すべてを一人で背負うことではありません。リスクを見える形にし、事業部、購買、法務、経営層が判断できる材料をそろえることです。

最初の一歩として、重要業務を1つ選び、外部依存を10件以内で棚卸ししてください。そこから高リスクな接続、権限、データ、連絡不備を洗い出せば、サプライチェーン攻撃対策は抽象論ではなく、明日から進められる運用改善になります。