サプライチェーン攻撃とは、取引先・委託先・ソフトウェアなどを経由して企業を侵害するサイバー攻撃です。自社に直接侵入されなくても、委託先からの情報漏洩や、依存するサービスの停止によって業務に影響が及ぶことがあります。

企業の対策は、自社のアクセス管理、委託先の評価、ソフトウェアの管理を組み合わせて進めます。情シスは、委託先に付与した権限、未承認SaaS、更新が必要なソフトウェアを把握し、調達・法務・開発部門と確認の担当を決めるところから着手してください。

国内事例を確認する際も、侵入経路と被害が広がった経路を分けて読み、自社のどの取引やシステムに同じ管理上の弱点があるかを点検します。

サプライチェーン攻撃とは？3種類の攻撃手口

サプライチェーン攻撃とは、標的企業に直接侵入するのではなく、その企業が依存する取引先・委託先・ソフトウェアベンダーを経由して侵害する手法です。セキュリティが強固な大企業を正面から狙うよりも、対策が手薄な周辺企業を足がかりにするほうが攻撃者には容易なため、近年急増しています。

ビジネス型（委託先・取引先経由）

最も広く見られる形態です。標的企業の委託先や取引先のシステムに侵入し、そこを踏み台として本来の標的に接続します。委託先企業はターゲット企業のネットワークに接続する権限を持っていることが多く、その信頼関係が悪用されます。

2022年のトヨタ・小島プレス工業事件が典型例です。トヨタの部品サプライヤーである小島プレス工業がランサムウェアに感染したことで、トヨタの国内全14工場28ラインが停止しました。影響台数は約1万3千台。トヨタ自身は攻撃を受けていなかったにもかかわらず、サプライヤーとの接続を遮断せざるを得ない状況に追い込まれた事例です。

ソフトウェア型（OSS汚染・アップデート悪用）

ソフトウェアの開発・配布プロセスに悪意あるコードを混入させる手法です。企業が利用するソフトウェアのアップデートファイル自体に攻撃コードが含まれるため、利用企業は正規のアップデートを適用したつもりで感染します。

代表的な事例が2020年のSolarWinds事件です。米国のIT管理ソフトウェアOrionのアップデートに悪意あるコードが混入され、米国政府機関を含む約18,000組織が影響を受けました。オープンソースソフトウェアの依存関係を悪用した攻撃も急増しており、開発環境を持つ企業は特に注意が必要です。

サービス型（クラウドサービス・SaaS経由）

企業が利用するクラウドサービスやSaaSプロバイダーが侵害される形態です。多くの企業が共通して利用するSaaS管理ツールや認証サービスが侵害されると、そのサービスを利用する全企業に被害が連鎖します。SaaSのAPIを通じた不正アクセスも増加しています。

参考：IPA「情報セキュリティ10大脅威 2025」

参考：IPA「情報セキュリティ10大脅威 2026」

国内被害事例から学ぶ：主要インシデント

サプライチェーン攻撃は海外の大企業だけが受ける攻撃ではありません。国内事例を振り返ると、業種・規模を問わず被害が拡大していることがわかります。

株式会社イセトー事件（2024年）

2024年5月、印刷・発送業務を手がける株式会社イセトーがランサムウェア攻撃を受けました。イセトーは全国の自治体や企業から住民税の特別徴収通知書・年金通知書・医療費通知書などの発送業務を受託しており、漏えいした個人情報は約150万件に上りました。

この事件が残した教訓は、イセトー自身の被害にとどまらず、業務を委託していた自治体・企業がすべて二次被害者になったという点です。委託元は自社のシステムには一切問題がなかったにもかかわらず、顧客への謝罪・通知対応を余儀なくされました。

KADOKAWAグループへのランサムウェア攻撃（2024年）

2024年6月、KADOKAWAグループの複数サーバーへのアクセス障害が発生し、ニコニコ動画を中心としたサービス群が長期間にわたって停止しました。ランサムウェアを含む大規模なサイバー攻撃であることが確認され、グループ企業の業務データや個人情報の漏えいも発生しています。

KADOKAWAの事例は、グループが提供するサービスを利用していたクリエイターや企業が、自らのシステムは無事であるにもかかわらず、データアクセス不能という二次的な影響を受けたサードパーティリスクの典型例です。

トヨタ・小島プレス工業事件（2022年）

2022年2月、トヨタ自動車の部品サプライヤーである小島プレス工業がサイバー攻撃を受け、トヨタは翌日から国内全14工場28ラインの稼働を停止せざるを得ませんでした。生産停止による影響台数は約1万3千台。Tier1と呼ばれる一次サプライヤーへの攻撃が、製造業の中核に直接ダメージを与えた象徴的な事例です。

名古屋港コンテナターミナル（2023年）

2023年7月、名古屋港のコンテナターミナルで使用されているシステムがランサムウェアに感染し、コンテナの搬出入業務が約3日間停止しました。名古屋港は日本の総輸出入額の約10%を扱う国内最大の港湾であり、トヨタ自動車など多くのメーカーの物流に影響が生じました。

参考：サイバーセキュリティクラウド「企業のセキュリティインシデントに関する調査レポート2024」

なぜサプライチェーン攻撃は防ぎにくいのか

サプライチェーン攻撃が4年連続でIPAの10大脅威上位に位置するのは、従来のセキュリティ対策では防ぎにくい構造的な特徴があるためです。自社のファイアウォールやEDRを強化しても、攻撃経路が自社の外にある以上、これらの対策が機能しない場面が必ず生じます。

攻撃者の侵入経路が自社のコントロール外にある

自社のサーバーやエンドポイントへの不正アクセスは、自社のセキュリティツールで検知・遮断できます。しかし委託先企業のネットワークで何が起きているかは、自社のツールでは把握できません。委託先が侵害された後、正規の接続経路を通じてアクセスしてくる攻撃は、正規の通信として認識されてしまいます。

委託先のセキュリティ水準を把握できていない

委託先のセキュリティ対策水準を定期的に評価する仕組みを持っている企業は多くありません。契約時にセキュリティポリシーの遵守を義務付けていても、実際の対策状況を確認できていないケースが大半です。委託先が数十社・数百社に及ぶ場合、個別確認は現実的に困難です。

シャドーITや未把握SaaSが盲点になる

社員が情シスの承認なく利用しているSaaSや外部サービス、いわゆるシャドーITがサプライチェーン攻撃の入口になることがあります。未承認のSaaSが外部サービスと連携している場合、情シスが把握していないルートで攻撃者が侵入する可能性があります。

企業が取るべきサプライチェーン攻撃対策の全体像

サプライチェーン攻撃への対策は、自社内部・委託先管理・ソフトウェア管理の3層で考える必要があります。どれかひとつに集中するだけでは不十分であり、3層をバランスよく整備することが求められます。

NIST CSF 2.0では新たに「統治（Govern）」機能が追加され、サプライチェーンリスクを含む組織全体のリスク管理体制の整備が求められるようになりました。自社のセキュリティ対策をこのフレームワークに照らして点検することで、対策の網羅性を確認できます。3層それぞれの主な対策内容と担当部門を以下にまとめます。

対策の担当と完了条件を決める

対策を実行に移すには、管理対象の一覧に担当者、確認結果、未対応事項を記録します。設定しただけで完了にせず、不要権限の削除結果やログの取得状況を確かめてください。委託先の回答待ちと自社の作業待ちを分けると、次に誰が動くべきかが明確になります。

権限の確認から始める場合は、アクセス権限の棚卸しの手順に沿って、業務上必要な権限と残存している権限を照合します。委託先との接続に絞って確認し、結果を踏まえてほかの対象へ広げる進め方も取れます。

IT管理側で実践できる6つの具体的対策

情シス担当者がIT管理の観点から今日から取り組める対策を6つ挙げます。すべてを同時に実装する必要はなく、リスクが高い領域から順番に着手することが現実的です。

①最小権限の原則によるアクセス権管理

すべてのユーザー・システム・アプリケーションに対して、業務遂行に必要な最小限のアクセス権のみを付与します。委託先・外部ベンダーに付与しているアクセス権は特に注意が必要です。念のため広めに権限を与えておくという運用は、攻撃者が侵入した際の被害範囲を広げます。

アクセス権の棚卸しを定期的に実施し、不要になった権限はその時点で削除する運用を確立してください。プロジェクト終了後の外部委託先アカウントや退職者のアカウントが残存していないかを確認することが出発点となります。

②多要素認証の徹底

VPN・SaaS・クラウドサービスへのアクセスには、パスワードだけでなく多要素認証（MFA）を設定します。委託先がアクセスする際も例外なくMFAを要求してください。アカウント情報がフィッシングで漏えいしても、MFAがあれば不正ログインを防げます。

注意が必要なのは、複数のSaaSを利用している場合にMFAの設定状況がサービスごとに異なる点です。すべてのSaaSでMFAが有効になっているかを一括で確認できる体制を整えることが求められます。

③シャドーIT・未承認SaaSの検出と排除

情シスが把握していないSaaSや外部サービスの利用は、サプライチェーン攻撃の入口になります。社員が業務効率のために個人的に利用しているSaaSが社外の悪意あるサービスと連携している場合、情シスが知らないルートでデータが流出する可能性があります。

シャドーITの検出には、ネットワークの通信ログの分析や、SaaS管理ツールによる利用状況の可視化が有効です。発見した未承認SaaSは、業務上必要なものは正式な申請・承認フローに乗せ、不要なものはアクセスをブロックします。

シャドーIT 対策

④ソフトウェア・ライブラリの脆弱性管理

利用しているソフトウェアやライブラリの構成を把握し、既知の脆弱性が含まれていないかを継続的に確認します。SBOM（Software Bill of Materials）はソフトウェアに含まれるすべてのコンポーネントと依存関係を一覧化したもので、脆弱性が公表された際に影響を受けるシステムを迅速に特定するために活用できます。

オープンソースソフトウェアを利用している場合は、依存関係に脆弱なパッケージが含まれていないかを定期的に確認します。ソフトウェア構成分析ツールを活用することで、このスキャンを自動化できます。

⑤ネットワーク分離とゼロトラスト設計

委託先や外部ベンダーが接続するネットワークセグメントは、社内の重要システムとは分離して設計します。接続できることとすべてのリソースにアクセスできることは別であり、委託先に付与するアクセス権は業務に必要な特定のシステム・データに限定してください。

ゼロトラストセキュリティは「信頼しない、常に検証する」という原則に基づいています。社内ネットワーク内からのアクセスであっても、すべてのアクセスを検証・制御することで、侵入後の被害拡大を防ぎます。

⑥監査ログの収集と異常検知

委託先・取引先からのアクセスを含むすべての接続ログを収集し、異常なアクセスパターンを検知できる体制を整えます。通常とは異なる時間帯・場所・量のアクセスは、侵害の可能性を示すシグナルです。

各SaaSの管理コンソールが提供する監査ログを定期的に確認することも必要です。複数のSaaSにまたがるアクセスログを一元的に管理・分析できる環境を構築することで、異常の早期発見につながります。

参考：NIST CSF 2.0

参考：SBOM導入の手引き（経済産業省）

委託先・取引先のセキュリティ管理方法

自社内部の対策と並行して、委託先・取引先のセキュリティ水準を把握・管理することがサプライチェーン攻撃への実効的な対応です。第三者リスク管理（TPRM）と呼ばれるこの取り組みは、企業規模を問わず求められるようになっています。

委託先のセキュリティ評価チェックリスト

委託先のセキュリティ対策水準を評価するために、定期的な自己評価アンケートや現地確認を実施します。評価すべき主な項目は以下の通りです。

• 情報セキュリティポリシーの策定・運用状況
• アクセス制御・多要素認証の実施状況
• セキュリティインシデント発生時の報告義務と対応体制
• 個人情報・機密情報の取り扱いルール
• 再委託先（孫請け）のセキュリティ管理状況
• 定期的な脆弱性診断・セキュリティ教育の実施状況

委託先の規模や委託内容のリスク度に応じて評価の頻度・深度を変えることが現実的です。重要な個人情報や機密データを扱う委託先には、より詳細な評価と頻繁な確認が必要になります。

契約書への情報セキュリティ条項の組み込み

委託先との契約書には、情報セキュリティに関する要件を明示的に盛り込みます。主な条項として、セキュリティポリシーの遵守義務、インシデント発生時の報告義務（報告期限・報告内容を明記）、再委託先への同等のセキュリティ要件の適用、セキュリティ監査への協力義務などが挙げられます。

契約書に条項を盛り込むだけでは不十分です。委託先がこれらの義務を実際に履行しているかを確認する仕組みをセットで構築してください。

委託先への定期的な評価・確認の実施

セキュリティ評価を契約締結時に一度行うだけでは不十分です。委託先のセキュリティ状況は時間とともに変化します。半年から1年に一度の定期的な自己評価アンケート、重大なセキュリティ脆弱性が公表された際の緊急確認、インシデント発生時の即時報告と情報共有の体制を構築してください。

委託先の数が多い場合は、機密情報へのアクセス権がある・大量の個人情報を扱うといったリスクの高い委託先を優先的に評価対象とすることが現実的です。

参考：経済産業省「サイバーセキュリティ経営ガイドライン」

経済産業省SCS評価制度など法規制動向と企業対応

サプライチェーンセキュリティに関する法規制・ガイドラインの整備が急速に進んでいます。現在の対策状況を点検するとともに、今後の規制動向を注視することが求められます。

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）

SCS評価制度は、経済産業省と内閣官房国家サイバー統括室が制度構築方針を公表し、IPAが運営する、サプライチェーン強化に向けたセキュリティ対策評価制度です。2026年9月時点の整理では、★3は要求事項26・評価基準81、★4は要求事項43・評価基準153です。★3は専門家確認付き自己評価、★4は第三者評価に実地審査・技術検証を組み合わせます。

評価範囲はインターネットに接続する自社IT基盤で、OTシステムと提供製品そのものは対象外です。★3の有効期間は1年、★4は3年ですが期間中も毎年の自己評価を評価機関へ提出します。運用開始は2026年度末頃の想定です。任意の制度で、取引に規制措置を設けるものではなく、特定製品の導入も必須ではありません。

SCS評価基準を証跡の集め方で整理する（ジョーシス独自の整理）

この分け方は、制度が定めたものではありません。ジョーシスが独自に整理したものです。★3の81評価基準を証跡の集め方に割り当てると、システムで取るもの40件、文書で示すもの25件、人手で回すもの16件になります。ツール導入だけで対応が完結しない点に注意が必要です。

出典は、IPAが公開している要求事項・評価基準をもとにジョーシスが分類・集計したものです。2026年9月15日の記者勉強会で公表した整理であり、評価基準番号と特定製品の機能を一対一で対応させた表ではありません。

実務では、ログを集める担当、規程を更新する担当、委託先に確認する担当を分けて決めます。SaaSの監査ログ管理では記録の取得方法を、企業のセキュリティ監査の進め方では確認の段取りを整理できます。分類に当てはめること自体を目的にせず、説明に必要な記録が残っているかを確かめてください。

NIST CSF 2.0でのサプライチェーンリスク管理

2024年2月に公開されたNISTサイバーセキュリティフレームワーク2.0では、新機能「統治（Govern）」が追加されました。組織の意思決定者がサプライチェーンリスクを含むセキュリティリスクを管理する責任が明示され、委託先を含むサードパーティのリスクマネジメントが経営課題として位置付けられています。

金融庁ガイドラインにおける委託先管理要件

2024年10月に策定・公表された「金融分野におけるサイバーセキュリティに関するガイドライン」では、委託先を含むサードパーティリスクの管理が明示的に求められるようになりました。金融業界にとどまらず、他業種でも同様の要件が波及することが予想されます。

参考：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度 構築方針」

参考：経済産業省「SCS評価制度 中間取りまとめ」

SaaS可視化・アクセス管理でリスクを下げるJosys活用

サプライチェーン攻撃対策において、IT管理の観点から即効性が高い取り組みのひとつがSaaSの可視化と適切なアクセス管理です。Josysは、情シス2〜3名体制の組織が抱えるこの課題に直接対応する機能を提供しています。

SaaS管理の穴がサプライチェーンリスクになる理由

現代の企業は数十から数百種類のSaaSを並行して利用しています。しかし、情シスが把握していないSaaSの存在（シャドーIT）や、退職者・プロジェクト終了後も残存するアクセス権は、攻撃者が侵入するための穴になります。

委託先や外部ベンダーに付与したSaaSアクセス権が、業務終了後も削除されないまま残存しているケースは珍しくありません。このような幽霊アカウントが不正アクセスの踏み台になると、正規の認証情報を使ったアクセスとして検知を回避されてしまいます。以前は、未管理のSaaSアカウントや権限の状況を把握するには各SaaSの管理コンソールを個別に確認する必要があり、情シス2〜3名の体制では現実的に困難な作業でした。

JosysによるSaaSの一元可視化

Josysは、企業が利用するSaaSアプリケーションとそのアクセス権を一元的に管理・可視化します。どのユーザーがどのSaaSにどのような権限でアクセスしているかを、単一の画面から確認できる環境が整います。

個別のSaaS管理コンソールを横断的に確認していた作業から解放され、全SaaSのアクセス状況を一か所で把握できるようになります。これにより、不審なアクセスや不要な権限の早期発見が可能になります。

シャドーITの自動検出とアクセス権の一括管理

JosysのSaaS Discovery機能は、社員が利用しているSaaSを自動検出します。情シスが承認していないシャドーITを可視化し、セキュリティポリシーに基づいて対処できます。発見したシャドーITは、業務上必要と判断したものは正式な管理対象に移行し、不要なものはアクセスをブロックします。

SaaSへのアクセス権の付与・変更・削除を一元的に管理できるため、委託先・外部ベンダーへのアクセス権を適切なタイミングで停止する運用もスムーズになります。

退職・異動時の即時アクセス権停止で不正侵入を防ぐ

退職者のアカウントや異動後に不要になった権限が残存することは、サプライチェーン攻撃だけでなく内部不正のリスクにもなります。Josysは、入退社・異動に連動してSaaSのアクセス権を自動的に変更・停止する機能を提供しています。

委託先スタッフの担当業務終了時も同様に、付与していたアクセス権を漏れなく停止できます。アカウント削除漏れという人的ミスによるリスクを大幅に低減できます。

Josysは2021年のサービス開始以来、国内外1,000社以上に導入され、350以上のSaaSアプリとの連携に対応しています。AI駆動のアイデンティティセキュリティ基盤として、退職者IDの放置やシャドーIT、余剰ライセンスの是正を支援します。事例によってはIT工数を最大50%、ITコストを最大75%削減したケースがあります。効果は企業ごとの状況により異なります。

Josysのサービス資料をダウンロード（無料）

関連記事：SaaSセキュリティ 対策

よくある質問（FAQ）

サプライチェーン攻撃について、情シス担当者からよく寄せられる質問をまとめました。

Q1. サプライチェーン攻撃は大企業だけの問題ですか？

中小・中堅企業も対象になります。むしろ対策が手薄な中小企業が大企業への侵入経路として狙われるケースが増えています。取引先との接続があるすべての企業が対策を検討する必要があります。

Q2. 委託先が何十社もある場合、すべてを管理できますか？

リスクの高い委託先を優先的に管理することが現実的です。機密情報へのアクセス権がある・大量の個人情報を扱う・システム管理権限を持つ委託先を選定し、段階的に評価体制を整備してください。

Q3. 委託先が攻撃されたとき、自社にできることはありますか？

インシデント発生時の即時報告を契約に盛り込み、自社からの接続を素早く遮断できる体制を整えることが重要です。委託先からのアクセス権を適切に分離・最小化しておくことで、被害の連鎖を限定できます。

Q4. SCS評価制度に対応しないと取引できなくなりますか？

SCS評価制度は任意の制度で、対応していない企業の取引を規制するものではありません。特定のセキュリティ製品の導入も必須ではありません。自社の取引先から個別に求められる条件と、制度自体の要件を分けて確認してください。

Q5. ソフトウェアのアップデートを止めるべきですか？

停止はむしろリスクを高めます。既知脆弱性への対処を優先する観点から、アップデートの適用は基本的に継続してください。主要ベンダーの公式チャネル以外からのアップデート適用には注意が必要です。

まとめ

サプライチェーン攻撃は自社が直接狙われていないのに被害を受けるという、従来のセキュリティ対策の盲点を突く脅威です。2024年のイセトー事件やKADOKAWA事件が示すように、委託先・取引先の侵害が自社の顧客情報漏えいや業務停止につながります。

情シス担当者が今すぐ着手できる対策を改めて整理します。

1. アクセス権の棚卸し：委託先・退職者を含む不要なアクセス権を削除する
2. 多要素認証の徹底：VPN・SaaS・クラウドサービスへのすべてのアクセスにMFAを設定する
3. シャドーITの可視化：未承認SaaSを検出し、セキュリティリスクを評価する
4. 委託先評価の仕組みづくり：定期的なセキュリティ評価と契約条項の整備を進める
5. ログの一元管理：複数のSaaSにまたがるアクセスログを統合的に収集・監視する

これらの対策を個別のSaaS管理コンソールで手作業で実施することは、情シス2〜3名の体制では現実的ではありません。Josysは、SaaSの可視化・アクセス権管理・シャドーIT排除を一元的に実現し、サプライチェーン攻撃の入口を塞ぐIT管理基盤として機能します。

Josysのサービス資料をダウンロード（無料）

デモを予約する