サプライチェーン攻撃の基本と実務対策ガイド
目次[非表示]
- サプライチェーン攻撃は、自社の境界防御だけでは防ぎにくい。委託先、取引先、クラウド、ソフトウェア部品、保守回線、開発環境まで含めてリスクを見る必要がある。
- 情報システム担当者が最初に行うべきことは、全取引先を同じ強度で監査することではない。重要システムへの接続、重要情報の取扱い、障害時の事業影響で優先順位を付ける。
- 対策は「契約で求める」「技術的に制限する」「継続的に確認する」の3層で考える。質問票だけ、EDRだけ、SBOMだけでは十分ではない。
- ソフトウェアサプライチェーンでは、脆弱性管理、署名、SBOM、更新経路、開発環境の保護を組み合わせる。SBOMは万能な防御策ではなく、部品を可視化して判断を速くする材料である。
- 本記事は、IPA、NIST、CISA、NCO/NISCなどの一次情報を確認し、情報システム担当者が社内ルールと運用手順に落とし込む観点で整理した。
なぜ情シスがサプライチェーン攻撃を自分ごとにすべきか
サプライチェーン攻撃とは、最終的な標的企業を直接攻撃する代わりに、取引先、委託先、ソフトウェア、保守サービス、クラウド連携などのつながりを悪用する攻撃です。情報システム担当者にとって厄介なのは、侵入口が自社のファイアウォール内に限られない点です。委託先の端末、利用中の業務ソフト、開発委託会社のGitリポジトリ、リモート保守用アカウントが、自社システムへの踏み台になることがあります。
IPAの「情報セキュリティ10大脅威 2025」では、組織向け脅威として「サプライチェーンや委託先を狙った攻撃」が上位に位置づけられています。IPAは、取引先や委託先も含めた対策が必要な脅威として説明しており、これは大企業だけの問題ではありません。Source: IPA 情報セキュリティ10大脅威 2025
この記事では、サプライチェーン攻撃の基本を確認したうえで、情報システム担当者が実務で使える対策を整理します。対象は、社内IT、業務システム、SaaS、委託開発、保守委託、取引先接続を管理する担当者です。法律判断や契約文言の最終確認は、必要に応じて法務・購買・監査部門と連携してください。
サプライチェーン攻撃の全体像
サプライチェーン攻撃を理解するには、「誰が弱いか」ではなく「どのつながりが自社の重要資産へ届くか」を見ます。攻撃者は、セキュリティ投資が厚い本社システムを正面から破るよりも、周辺の弱い接続点を探すことがあります。
典型的な経路は次の4つです。
- 委託先経由: 運用委託先、開発委託先、コールセンター、保守会社のアカウントや端末を悪用する。
- 取引先経由: 受発注、EDI、共有ストレージ、メール添付、VPNなどの業務接続を悪用する。
- ソフトウェア経由: パッケージソフト、OSS、ライブラリ、アップデート配信、ビルド環境を悪用する。
- クラウド・SaaS経由: 連携アプリ、APIキー、管理者権限、外部共有設定を悪用する。
重要なのは、サプライチェーン攻撃が「委託先の問題」で終わらないことです。委託先で漏えいした認証情報が自社VPNに使われる、開発会社のリポジトリからシークレットが流出する、更新プログラムに不正コードが混入する、という形で自社のインシデントになります。したがって情シスは、購買や法務が契約を管理するだけでなく、接続制御、ログ監視、権限管理、脆弱性対応を一体で設計する必要があります。
まず優先順位を付ける
サプライチェーン対策で失敗しやすいのは、すべての取引先へ同じ質問票を送り、回答を集めただけで対策した気になることです。取引先の数が多い場合、同じ強度の監査は現実的ではありません。最初に、影響度で分類します。
分類 | 判断軸 | 例 | 優先対策 |
|---|---|---|---|
高リスク | 重要システムへ接続する、特権IDを持つ、個人情報や機密情報を扱う | 運用保守会社、開発委託先、クラウド管理代行 | 契約要件、MFA、最小権限、ログ取得、年次確認、インシデント通知義務 |
中リスク | 業務データを扱うが特権接続はない | BPO、業務SaaS、外部倉庫、販売代理店 | アカウント棚卸し、共有設定確認、脆弱性対応窓口、バックアップ確認 |
低リスク | 公開情報中心、システム接続が限定的 | 一般購買先、単発制作会社 | 基本的な情報管理ルール、メール・ファイル授受ルール |
この表で見るべき点は、企業規模ではなく接続と情報の重要度です。小規模な委託先でも、管理者アカウントや本番データを扱うなら高リスクです。逆に大企業の取引先でも、自社システムに接続せず公開情報だけを扱うなら、過剰な監査より基本ルールの明確化が有効です。
NIST SP 800-161 Rev. 1は、サイバーセキュリティサプライチェーンリスク管理を、組織、ミッション・業務プロセス、システムの各階層に組み込む考え方を示しています。つまり、購買時だけでなく、設計、導入、運用、廃棄まで継続して扱うべきリスクです。Source: NIST SP 800-161 Rev. 1
委託先・取引先管理で確認すること
委託先管理では、相手に完璧なセキュリティを求めるより、自社に影響する経路を明確にし、最低限守るべき条件を合意することが重要です。特に高リスク先では、契約、運用、技術制御を分けて確認します。
確認項目は、次のように整理できます。
領域 | 確認する内容 | 情シスが持つべき証跡 |
|---|---|---|
契約・ルール | 情報の取扱い、再委託、事故時連絡、ログ保存、終了時返却・削除 | 契約書、覚書、セキュリティ要件表 |
ID・アクセス | MFA、共有ID禁止、特権IDの範囲、退職者削除 | アカウント一覧、権限棚卸し記録 |
接続経路 | VPN、閉域、SaaS連携、APIキー、保守端末 | 接続構成図、許可IP、証明書、鍵管理台帳 |
脆弱性対応 | パッチ方針、緊急脆弱性時の連絡、SLA | 脆弱性通知先、対応期限、例外承認 |
インシデント対応 | 初動連絡、影響範囲調査、証跡保全、再発防止 | 連絡網、訓練記録、報告テンプレート |
取引先へセキュリティ対策を求めることについては、NCO/NISCのサイバーセキュリティ関係法令Q&Aが実務上参考になります。同資料は、取引条件として一定のサイバーセキュリティ対策を求めることが、社会全体の対策に資すると説明しています。ただし、優越的地位の濫用や下請法などに留意すべき場合があるため、情シスだけで一方的に条件を押し付ける運用は避けるべきです。Source: NCO/NISC サイバーセキュリティ関係法令Q&A
「原則として、我が国の何らかの法令に抵触するおそれはない」
この引用は、セキュリティ要件を求めてよいという免罪符ではありません。実務では、要求水準の妥当性、費用負担、取引上の立場、再委託の有無を確認し、法務・購買と一緒に設計する必要があります。
ソフトウェアサプライチェーン対策
ソフトウェアサプライチェーン攻撃では、ソースコード、依存ライブラリ、ビルド、署名、配布、更新のどこかが狙われます。情シスが市販ソフトやSaaSを利用する立場でも、何を調達し、どのように更新し、どの権限で動かしているかを把握しなければなりません。
まず、利用ソフトウェアの棚卸しをします。端末管理ツールやSaaS管理台帳を使い、製品名、提供元、用途、管理者、利用部門、データ分類、認証方式、外部連携、更新方法を記録します。ここで重要なのは、台帳を作ること自体ではなく、緊急脆弱性が出たときに「どこで使っているか」「誰が止められるか」「代替手段があるか」をすぐ判断できる状態にすることです。
SBOM（Software Bill of Materials）は、ソフトウェアに含まれる部品表です。CISAはSBOMを、ソフトウェアセキュリティとサプライチェーンリスク管理の重要な構成要素として位置づけています。Source: CISA SBOM
“SBOM has emerged as a key building block”
"「SBOMは重要な構成要素として浮上してきた」"
SBOMは、導入すれば攻撃を止める製品ではありません。部品の透明性を高め、脆弱性情報との照合、影響調査、調達時の説明責任に使うものです。したがって、SBOMを要求する場合は「受け取る形式」「更新頻度」「脆弱性が見つかったときの通知」「自社でどう保管・検索するか」まで決めなければ運用に乗りません。
開発委託や内製開発がある場合は、次の対策を優先します。
- リポジトリのMFAと権限分離を必須にする。
- CI/CDのシークレットを平文で置かない。
- 本番反映はレビュー、署名、承認を通す。
- 依存ライブラリの脆弱性スキャンを自動化する。
- ビルド成果物と配布物の改ざん検知を行う。
- 開発委託先の退職者・契約終了者のアクセスを即時削除する。
これらは高度な対策に見えますが、実際にはアカウント管理と変更管理の延長です。情シスが開発部門や委託先に丸投げせず、社内標準として求めることが重要です。
技術的な防御は「つながり」を絞る
サプライチェーン攻撃は、つながりを悪用します。したがって技術的な対策では、つながりをなくすのではなく、必要な範囲に絞り、異常を見つけられるようにします。
最初に見直すべきは、外部委託先のアクセス権です。保守会社のVPNアカウントが常時有効、共有IDで誰が作業したか分からない、接続元IPが制限されていない、ログ保存期間が短い、という状態はリスクが高いです。最低限、MFA、個人別ID、作業時間帯の制限、接続元制限、特権操作ログの保存を実施します。
次に、SaaS連携を確認します。OAuthアプリ、APIキー、Webhook、外部共有リンクは、業務部門が便利さを優先して増やしがちです。情シスは、利用中の連携アプリ一覧、付与スコープ、管理者、最終利用日、データ分類を定期的に確認します。不要な連携は削除し、高権限アプリは承認制にします。
さらに、メールとファイル授受も見直します。取引先を装ったメール、侵害済み取引先アカウントからの正規メール、共有ストレージへの不正ファイル配置は、境界型対策だけでは見逃すことがあります。DMARCなどの送信ドメイン認証、添付ファイルの隔離、クラウドストレージの外部共有制限、取引先との緊急連絡経路の確認を組み合わせます。
バックアップもサプライチェーン対策の一部です。委託先やSaaS経由で侵害された場合、復旧の可否が事業継続を左右します。バックアップは、取得しているかだけでなく、復元手順、復元時間、隔離保管、権限分離、復旧訓練まで確認します。
インシデント対応で決めておくこと
サプライチェーン攻撃では、第一報が自社からではなく、委託先、製品ベンダー、業界団体、公的機関から来ることがあります。情シスは、連絡を受けてから慌てて影響調査を始めるのではなく、平時に判断材料をそろえておきます。
緊急時に必要な情報は次のとおりです。
- 対象製品・サービスを社内のどこで使っているか。
- 重要情報や個人情報を扱っているか。
- 外部接続や管理者権限を持っているか。
- 停止した場合の業務影響はどれくらいか。
- 暫定回避策、遮断、パッチ適用、監視強化のどれを選ぶか。
- 経営、法務、広報、個人情報保護担当へいつ報告するか。
この判断を速くするには、資産台帳、取引先台帳、システム構成図、ログ基盤がつながっている必要があります。完璧なCMDBを目指すより、重要システムから順に「外部接続」「委託先」「利用ソフト」「データ分類」を紐づけるほうが現実的です。
また、委託先からの事故連絡を受ける窓口を契約書に書くだけでは不十分です。夜間休日の連絡先、暗号化された連絡手段、初報に含める項目、続報頻度、証跡保全、顧客通知の役割分担を、訓練で確認します。訓練は大規模でなくても構いません。年1回、重要委託先を1社選び、脆弱性悪用や認証情報流出を想定した机上演習を行うだけでも、連絡網と判断手順の穴が見えます。
情シス向け実務チェックリスト
次のチェックリストは、最初の90日で着手しやすい順に並べています。すべてを一度に完了させる必要はありません。重要システムと高リスク委託先から始めてください。
- 重要システムに接続する委託先と保守会社を一覧化する。
- 外部アカウントにMFA、個人別ID、最小権限を適用する。
- 常時VPNや共有IDを廃止し、作業時間・接続元・承認フローを制限する。
- 高リスク委託先の契約に、事故時連絡、再委託、ログ、削除・返却、脆弱性対応を含める。
- 利用ソフトウェアとSaaSの台帳に、用途、管理者、データ分類、外部連携を追加する。
- 重大脆弱性が出たときの影響調査手順を作る。
- 開発リポジトリ、CI/CD、シークレット管理、依存ライブラリスキャンを確認する。
- SBOMを要求する対象製品を限定し、受領後の保管・検索・脆弱性照合方法を決める。
- 重要委託先とのインシデント連絡訓練を行う。
- 経営・購買・法務・監査と、取引先に求める最低セキュリティ要件を合意する。
このチェックリストの目的は、監査資料を増やすことではありません。攻撃が起きたときに、侵入口を狭め、影響範囲を早く特定し、復旧と説明責任を果たせる状態を作ることです。
90日で進める現実的なロードマップ
対策を継続させるには、年度計画に載せやすい単位へ分けることが重要です。最初の30日は、棚卸しと優先順位付けに集中します。対象は全取引先ではなく、重要システムに接続する委託先、本番データを扱う委託先、管理者権限を持つ外部アカウントです。この段階では、未整備を責めるより、誰が何を管理しているかを可視化します。
31日目から60日目は、高リスク接続の技術対策に移ります。MFA、個人別ID、不要アカウント削除、常時接続の見直し、接続元制限、ログ保存を優先します。契約更新を待たないと進まない項目と、情シス権限で即日改善できる項目を分けると、進捗が止まりにくくなります。
61日目から90日目は、委託先との連絡・復旧手順を確認します。脆弱性情報を受け取ったとき、委託先事故の第一報が来たとき、自社からサービス停止を判断するときの責任者を決めます。ここまで進めると、サプライチェーン攻撃対策は単発の監査ではなく、資産管理、ID管理、契約管理、インシデント対応をつなぐ運用になります。
よくある誤解
大手ベンダーなら安全と言えるか
言えません。大手ベンダーは対策水準が高いことが多い一方、攻撃者にとって価値の高い標的でもあります。重要なのは、ベンダーの知名度ではなく、自社データへのアクセス範囲、認証方式、脆弱性通知、障害時の代替策です。
セキュリティ質問票を取れば十分か
十分ではありません。質問票は出発点です。高リスク先では、回答内容を契約条件、接続制御、ログ、訓練、定期レビューに結びつける必要があります。質問票だけで技術的な接続が放置されていれば、実効性は限定的です。
SBOMをもらえば安全か
安全とは言えません。SBOMは部品の可視化に役立ちますが、脆弱性への対応、修正版提供、悪用有無の確認、運用判断が必要です。SBOMは「何が入っているか」を知るための材料であり、「どう守るか」は別途設計します。
ゼロトラストを導入すれば解決するか
ゼロトラストの考え方は有効ですが、製品導入だけでは解決しません。ID、端末、ネットワーク、アプリ、ログ、委託先接続を継続的に検証する運用が必要です。まずは高リスク接続のMFA、最小権限、ログ監視から始めるのが現実的です。
まとめ
サプライチェーン攻撃への対策は、自社だけを堅くする発想から、つながり全体を管理する発想への転換です。情報システム担当者は、委託先やソフトウェアを「外部のもの」として扱うのではなく、自社の攻撃面の一部として見なす必要があります。
最初にやるべきことは明確です。重要システムに接続する委託先を洗い出し、権限と接続経路を絞り、利用ソフトウェアとSaaSを台帳化し、重大脆弱性や委託先事故の連絡・判断手順を作ることです。NISTのC-SCRM、CISAのSBOM、IPAの脅威情報、NCO/NISCの法令Q&Aは、いずれも情シスが社内ルールへ落とし込む際の根拠になります。
この分野では、完璧な対策を待つより、影響度の高い接続から継続的に改善するほうが現実的です。次の会議では、まず「重要システムに外部から接続できる委託先は誰か」「そのアカウントは個人別か」「事故時の連絡先は機能するか」を確認してください。そこから、サプライチェーン攻撃対策は実務に落ち始めます。
