サプライチェーン攻撃とは――なぜ2026年に最大級の脅威となっているか
サプライチェーン攻撃とは、攻撃者がターゲット企業を直接狙うのではなく、その企業が利用するソフトウェアベンダー・クラウドサービス・外部委託先・部品メーカーといったサプライチェーン上の第三者を経由して侵入する攻撃手法だ。
なぜこの手法が急増しているかは、攻撃者の合理的な判断によって説明できる。大企業はここ数年でファイアウォール・EDR・多要素認証などの直接防御を強化してきた。一方、その企業が契約している中小規模のシステム開発会社・清掃業者のIoT機器メーカー・物流管理SaaSベンダーのセキュリティ水準は、大企業と比べてはるかに低いことが多い。最も守りの堅い正面玄関を避け、裏口にあたる委託先から侵入する――これがサプライチェーン攻撃の基本的な発想だ。
IPA（情報処理推進機構）が発表した「情報セキュリティ10大脅威 2026」においても、「サプライチェーンの弱点を悪用した攻撃」は組織向け脅威の上位に位置し続けている。さらに2021年のSolarWinds社への攻撃（米国政府機関を含む18,000以上の組織が影響を受けた）や2022年のKaseya VSA事件を契機に、ソフトウェアサプライチェーンへの攻撃は国家レベルの問題として認識されるようになった。
日本においても、製造業・金融・医療・官公庁の各分野でサプライチェーン経由の侵害事案が相次いでいる。特に懸念されるのは、被害を受けた組織の多くが「直接攻撃された自覚がなかった」という点だ。委託先が侵害されているとは気づかないまま、数週間から数ヵ月にわたってデータが漏洩し続けるケースも確認されている。
主な攻撃手口3種
手口1：ソフトウェア改ざん（ソフトウェアサプライチェーン汚染）
ソフトウェアのビルドパイプラインやアップデート配布システムに侵入し、正規ソフトウェアの中にマルウェアを埋め込んで配布する手口だ。エンドユーザーは正規のベンダーから正規の手順でソフトウェアを受け取るため、疑う動機がほとんど生まれない。
SolarWinds事件がその典型例だ。攻撃者はITネットワーク監視ソフト「Orion」のビルド環境に事前侵入し、アップデートファイルにバックドア（SUNBURST）を埋め込んだ。配布されたアップデートをインストールした組織の環境に、静かに侵入経路が開かれた。
日本国内でも、業務用ソフトウェアのアップデートサーバへの不正アクセスにより、国内数十社の顧客環境へのバックドア設置が確認された事案が複数存在する。
なぜ検知が難しいか：
- デジタル署名が正規ベンダーのものであるため、インストール時の警告が発生しない
- ネットワーク通信はアップデートサーバとの正規通信に見える
- 侵害はビルドサーバ側で行われるため、エンドユーザー側のログには痕跡が残りにくい
手口2：委託先・取引先経由の侵入（第三者ベクター攻撃）
委託先（システム会社・保守業者・物流業者など）のネットワーク・認証情報・VPN接続を踏み台にしてターゲット企業へ侵入する手口だ。大企業ほど多くの外部委託先とVPN接続や専用回線を持つため、侵入経路の数も比例して増える。
攻撃者はまず、ターゲット企業と取引のある中小規模のベンダーを特定する。プレスリリース・登記情報・LinkedIn・求人票などの公開情報から、主要取引先のリストを作成することは難しくない。次に、セキュリティ対策が相対的に弱い委託先を標的にフィッシングやVPN製品の脆弱性を突いて侵入し、そこからターゲット企業のネットワークへと横展開する。
米国小売大手Targetの事件（2013年）はその古典的事例だが、手口は現在も本質的に変わっていない。空調設備の保守業者が踏み台にされ、約4,000万件のクレジットカード情報が流出した。2025〜2026年においても、製造業の部品サプライヤー経由・清掃・セキュリティ設備業者のリモート接続経由での侵入事例が国内で報告されている。
典型的な侵入フロー：
- 委託先のVPN認証情報をフィッシングで窃取
- 委託先のネットワーク内を横展開して内部情報を収集
- ターゲット企業との接続ポイント（専用VPN・EDI・ファイル共有）を特定
- ターゲット企業内部へ侵入し、長期間潜伏
手口3：オープンソースライブラリ汚染（OSS依存リスク）
現代のソフトウェア開発はオープンソースライブラリへの依存なしには成立しない。npmのJavaScriptライブラリ、PyPIのPythonパッケージ、MavenのJavaライブラリなど、アプリケーション1本が数百から数千のOSSコンポーネントを間接的に利用している。この依存関係が攻撃面として悪用される。
主な攻撃パターンは3つある。
タイポスクワッティング： 人気ライブラリに似た名前の悪意あるパッケージを公開する手口。lodashの代わりにl0dash、requestsの代わりにrequestzといった形で、開発者のタイプミスを狙う。悪意あるパッケージはダウンロード時に認証情報の窃取・バックドア設置のコードを実行する。
依存関係混乱（Dependency Confusion）： 企業の内部プライベートリポジトリに存在するパッケージと同名のパッケージを、より高いバージョン番号でパブリックリポジトリに公開する。パッケージマネージャーは「より新しいバージョン」を自動的に優先するため、意図せずパブリックの悪意あるパッケージがインストールされる。2021年にセキュリティ研究者Alex Birsan氏がこの手法の概念実証を公開して以来、実際の攻撃への悪用が増加している。
既存パッケージの乗っ取り： 広く利用されているOSSのメンテナーアカウントを乗っ取り、正規パッケージに悪意あるコードを混入して公開する。2022年のnode-ipc事件（ウクライナ侵攻への抗議として意図的に破壊的コードが混入）やevent-stream事件が代表例だ。信頼されたメンテナーからのコミットとして処理されるため、自動CI/CDパイプラインを通じて本番環境まで届く。
2025〜2026年の国内被害事例
事例①：大手製造業グループの委託先経由データ流出（2025年夏）
国内大手製造業A社グループにおいて、工場設備の保守を担当していた中小規模の協力会社が攻撃者に侵害された。協力会社はA社の製造実行システム（MES）にリモートアクセス権限を持っており、そのアクセス経路を通じて攻撃者がA社の工場ネットワーク内部に侵入。設計図面・生産ライン構成データ・一部の取引先情報が窃取されたとみられる。A社では「直接の侵入は確認されていない」とのコメントを出したが、協力会社経由の間接侵害であることが後に判明した。委託先が保有するアクセス権限の棚卸しと最小権限の原則適用が改めて問われた事案だ。
事例②：医療機関へのソフトウェアアップデート経由の侵害（2025年秋）
複数の地方医療機関が利用していた患者管理システムのベンダーが、アップデート配布サーバへの不正アクセスを受けた。改ざんされたアップデートファイルが医療機関側のサーバに配布され、適用後にバックドアが設置された。被害医療機関では診察予約システムが一時停止し、患者の個人情報・診療記録へのアクセスが一定期間にわたって攻撃者に可能な状態であったとみられる。医療分野は規制上の機微情報を大量に扱いながら、ITセキュリティ投資が他業種と比べて遅れがちであることが、格好の標的となる背景にある。
事例③：EC事業者へのOSSライブラリ汚染（2025年末〜2026年初頭）
国内中堅EC事業者B社の開発チームが利用していたnpmパッケージの一つが、メンテナーアカウント乗っ取りにより悪意あるコードを混入されていた。B社ではCI/CDパイプラインを通じて本番環境にデプロイされた後、顧客が入力するクレジットカード情報をリアルタイムで外部サーバに送信するスキミングコードが約2週間動作し続けた。発覚のきっかけはカード会社からの異常検知通報であり、B社のセキュリティ監視では検知できなかった。影響を受けた可能性のある顧客は数千名に上ると報告されている。
事例④：官公庁関連システムへの委託先経由アクセス（2026年）
官公庁向けシステムインテグレーターが複数の省庁・自治体向けシステムを保守していたケースで、そのSIer自身が攻撃者に侵害されていた事案が表面化した。SIerが保有していた各顧客向けのVPN認証情報・システム管理者アカウントが窃取されており、複数の省庁・自治体のシステムに対して不正アクセスが行われた可能性が浮上した。この事案は、委託先が複数の重要インフラを管理しているケースでは被害が連鎖的に拡大するリスクを改めて示している。
企業が受けるリスクの全体像
サプライチェーン攻撃による被害は、直接的な技術的被害にとどまらない。経営リスクとして広範に影響が及ぶことを理解しておく必要がある。
データ漏洩と法的責任
個人情報保護法の改正（2022年施行）により、個人情報の漏洩は原則として個人情報保護委員会への報告義務が生じる。委託先経由の漏洩であっても、委託元企業が負う責任は免除されない。個人情報保護委員会は委託元に対して「委託先の監督義務」を課しており、適切な監督を怠ったと判断された場合には是正勧告・命令の対象となる。
事業継続への影響
委託先が提供するシステム・サービスへの依存度が高い業種では、委託先の侵害がそのまま事業停止につながるリスクがある。製造ラインの停止・物流システムの麻痺・販売管理システムの停止は、一日あたり数百万〜数千万円規模の業務損失をもたらす。ランサムウェア感染が委託先から波及した場合には、暗号化による長期停止も想定される。
サプライチェーン汚染による連鎖被害
自社が「被害者」であると同時に、知らぬ間に「加害者」になるリスクもある。自社のシステムが侵害されて踏み台にされると、自社の顧客・取引先への攻撃に利用される。その場合、取引先からの損害賠償請求や契約解除のリスクが現実になる。
ブランド・信頼毀損
情報漏洩事案はメディアに取り上げられ、顧客・パートナー企業からの信頼を損なう。特にB2B取引において、セキュリティ管理体制の不備が判明した場合には取引継続の見直しや入札参加資格の喪失につながるケースがある。
企業が取るべき対策
対策1：委託先セキュリティ評価（サードパーティリスク管理）
委託先のセキュリティ水準を定期的に評価する仕組みが不可欠だ。評価項目には最低限、以下を含める。
- セキュリティ基準への準拠状況： ISO 27001認証・SOC 2レポート・ISMS認定の有無
- インシデント対応体制： 侵害発生時の報告義務・連絡体制・復旧手順の整備状況
- アクセス管理： 多要素認証の実装状況・特権アカウント管理・不要な接続の無効化
- パッチ管理： OSおよびソフトウェアの最新化サイクル
- 従業員教育： フィッシング対策訓練・セキュリティ研修の実施頻度
評価は自己申告書（アンケート形式）による一次評価と、重要委託先へのオンサイト・リモート監査による二次評価の二段構えが効果的だ。委託先の重要度に応じて評価頻度を変え、機密データ・重要インフラにアクセス権限を持つ委託先は年1回以上の評価が望ましい。
対策2：SBOM（ソフトウェア部品表）の整備と活用
SBOM（Software Bill of Materials：ソフトウェア部品表）とは、ソフトウェアを構成するすべてのコンポーネント・ライブラリ・依存関係の一覧だ。米国ではバイデン政権の大統領令（EO 14028、2021年）以降、連邦政府調達ソフトウェアへのSBOM提供が義務化されており、日本でも経済産業省が2023年にSBOM導入の手引きを公開した。
SBOMを整備することで、新たなCVE（脆弱性情報）が公開された際に「自社製品・自社システムが影響を受けるか」を即座に確認できる。OSSライブラリの無計画な追加を防ぎ、依存関係を可視化する手段としても機能する。
実務上の導入ステップ：
- SBOMツール（CycloneDX・SPDX形式に対応したツール例：Syft、Trivy）を導入し、既存プロジェクトのSBOMを生成する
- CI/CDパイプラインにSBOM生成・脆弱性スキャンを組み込み、新規コミット時に自動チェックを実施する
- SBOMをCVEデータベースと照合し、CVSS スコアに応じたパッチ適用優先度を管理する
- 委託開発成果物の受領時にSBOM提出を契約条件として義務付ける
対策3：ゼロトラストアーキテクチャの導入
「内部ネットワークは安全」という前提に立つ従来の境界防御モデルは、委託先経由の侵入に対して根本的に脆弱だ。委託先の正規アカウントで侵入された場合、VPNで内部ネットワークに入ってしまえば横展開が容易になる。
ゼロトラストアーキテクチャは「信頼しない、常に検証する」を原則とし、以下の要素を組み合わせて実現する。
- IDベースのアクセス制御（IAM）： すべてのアクセスをユーザーID・デバイス状態・コンテキスト（場所・時刻・リスクスコア）に基づいて動的に評価する
- マイクロセグメンテーション： ネットワークを細かなセグメントに分割し、セグメント間の通信を最小限に制限する。委託先が侵害されても、アクセス可能な範囲を限定できる
- 最小権限の原則： 委託先には業務遂行に必要な最小限のシステム・データへのアクセスのみを付与する。保守作業終了後は速やかに権限を剥奪する仕組みを整備する
- 継続的な認証・監視： セッション中のリスクが上昇した場合（異常なデータダウンロード・深夜の操作・未使用のシステムへのアクセス）に再認証を要求する
対策4：契約条項によるセキュリティ要件の担保
技術的対策と並行して、契約によって委託先に対してセキュリティ義務を課す仕組みが重要だ。サプライチェーン攻撃が発生した場合の責任の所在・対応義務を明確にしておかないと、被害が拡大した後の収拾が困難になる。
契約に盛り込むべき主な条項：
- セキュリティ基準への準拠義務： 委託先がISO 27001相当のセキュリティ管理を維持することを義務付ける
- インシデント通報義務： 侵害が疑われる事象が発生した場合、委託元への通報を（例：24時間以内）義務付ける。通報の遅延は重大な契約違反として扱う
- 再委託先管理： 委託先が業務の一部を再委託する場合、委託元の事前承認を必要とし、再委託先にも同等のセキュリティ基準を要求することを定める
- 監査権： 委託元が委託先のセキュリティ状況を定期的に監査する権利を明記する
- 損害賠償条項： セキュリティ基準の違反・通報義務の不履行に起因して委託元が損害を被った場合の賠償責任範囲を定める
既存の委託契約にこれらの条項が含まれていない場合、契約更新時に段階的に導入していくことが現実的なアプローチだ。
対策5：継続的な監視とログ管理
委託先が正規の認証情報でアクセスしている場合でも、行動の異常を検知することが可能だ。そのためには、委託先のアクセスログを含む包括的な監視体制が必要になる。
- 特権アクセス管理（PAM）ツールの導入： 委託先の特権アカウント操作をすべて記録・監視する。セッション録画機能を持つPAMツールは、侵害後のフォレンジック調査にも有効だ
- SIEM（セキュリティ情報・イベント管理）： 委託先のアクセスログをSIEMに集約し、異常なアクセスパターン（通常業務外の時間帯・未使用システムへのアクセス・大量データのダウンロード）を自動検知する
- サプライチェーン向けThreat Intelligenceの活用： 委託先が利用するソフトウェアベンダーに関する脅威情報（CVE・侵害指標）を継続的に収集し、リスクの早期把握に役立てる
中小企業でもできる現実的なサプライチェーン対策
「委託先管理・SBOM・ゼロトラスト」といった対策を聞いて、「大企業向けの話で、中小企業には無関係」と感じた担当者もいるかもしれない。しかし、中小企業もサプライチェーン攻撃の被害者と加害者の両方になり得る。大企業の取引先として攻撃の起点にされるリスクは、むしろ中小企業に高い。
以下は、専任のセキュリティ担当者がいない中小企業でも着手できる優先度の高い対策だ。
Step 1：委託先アクセスの棚卸しと最小化（コスト：低）
自社のネットワーク・システムへのリモートアクセス権限を持つ委託先の一覧を作成する。各委託先がアクセスできるシステムの範囲・権限レベルを確認し、業務上不要なアクセスを即座に削除する。VPN接続ごとにアカウントが設定されていない場合（共有IDを使い回している場合）は、委託先ごとの個別アカウント発行に切り替える。
Step 2：多要素認証（MFA）の全面適用（コスト：低〜中）
委託先が使用するリモートアクセス（VPN・リモートデスクトップ・社内ポータル）に多要素認証を適用する。認証情報が窃取されても、MFAがあれば不正ログインの大部分を防止できる。Microsoft Authenticator・Google Authenticatorなどのソフトウェアトークンであれば、ハードウェアトークンと比べてコストを抑えて導入できる。
Step 3：OSS依存関係の可視化（コスト：低）
自社でソフトウェア開発を行っている場合は、OSSの脆弱性スキャンツール（Trivy・Snyk無償プランなど）をCI/CDパイプラインに組み込む。開発を外部委託している場合は、委託先に対して定期的な依存ライブラリのアップデート対応を契約上の義務として明記する。
Step 4：委託先へのセキュリティ要件通知（コスト：低）
正式なセキュリティ監査が難しくても、委託先に対して「最低限守ってほしいセキュリティ要件」を書面で通知し、同意を取得することから始められる。要件には「OSとソフトウェアの定期的なアップデート適用」「フィッシング対策訓練の年1回実施」「インシデント発生時の24時間以内通報」などを含める。
Step 5：インシデント対応計画の整備（コスト：低）
委託先が侵害された可能性が浮上した場合に、どのような手順で対応するかを事前に決めておく。対応計画には「委託先へのアクセスの即時遮断手順」「影響を受けた可能性のあるシステムの特定方法」「法的な報告義務の確認手順（個人情報保護委員会への報告）」を含める。発生後に計画を作ろうとしても、混乱の中では判断が遅れる。
AEVUSのサプライチェーンセキュリティ支援
サプライチェーン攻撃への対策は、自社の技術的な対策だけでは完結しない。委託先の評価・契約条項の整備・ソフトウェア依存関係の可視化・ゼロトラストアーキテクチャの設計と、複数の専門領域にまたがる取り組みが必要だ。
AEVUSは、日本企業のサプライチェーンセキュリティ強化を以下の形で支援している。
委託先セキュリティアセスメント
委託先企業のセキュリティ管理状況を評価するアセスメントサービスを提供している。ISO 27001・SOC 2・CIS Controlsを参照基準として、書面評価・ヒアリング・技術的な検査を組み合わせ、委託先のリスクを可視化する。評価結果に基づいた委託先向け改善提言も行い、委託元・委託先の双方のセキュリティ水準引き上げを支援する。
ペネトレーションテスト（委託先経由の侵入シミュレーション）
攻撃者が委託先ネットワークを踏み台にしてターゲット企業へ侵入するシナリオを想定したペネトレーションテストを実施する。委託先との接続ポイント・認証設定・アクセス制御の実効性を実際の攻撃手法で検証し、潜在的な侵入経路を特定する。
SBOM導入支援
自社開発・委託開発ソフトウェアを対象としたSBOM整備の設計・ツール選定・CI/CDパイプラインへの組み込みを支援する。既存システムのOSS依存関係の棚卸しから、継続的な脆弱性管理プロセスの構築まで対応する。
ゼロトラストアーキテクチャの設計支援
現行のネットワーク構成を評価した上で、委託先アクセスを含むゼロトラスト移行のロードマップを策定する。マイクロセグメンテーション・IAM・PAMの導入計画を、既存インフラへの影響を最小化しながら段階的に設計する。
サプライチェーン攻撃は「自社だけ守れば安全」という時代が終わったことを意味している。自社を含むサプライチェーン全体のセキュリティ水準を底上げしていく取り組みが、企業の持続的な事業継続に不可欠だ。具体的な取り組みの進め方についての相談は、AEVUSのサービスページからお問い合わせいただきたい。
→ AEVUSのペネトレーションテスト・セキュリティ診断サービスを見る
