サプライチェーン攻撃の構造と防御の考え方。ソフト・ハード・サービス経由の侵入をどう減らすか

自分たちのシステムをどれだけ堅牢に作っても、そのシステムは数えきれない「他者の成果物」の上に成り立っています。OSやライブラリ、開発ツール、クラウドサービス、運用を委託しているベンダー、ネットワーク機器のファームウェア。これらは普段「信頼できるもの」として疑わずに使っています。サプライチェーン攻撃とは、まさにこの「信頼している入口」を突いてくる攻撃です。標的の本丸が固ければ固いほど、攻撃者は正面からではなく、より守りの薄い供給元を経由して入り込もうとします。

この攻撃が厄介なのは、被害者側の「自社のセキュリティ対策」だけでは防ぎきれない点にあります。正規の配布経路で届いた、正規の署名がついたアップデートが、すでに汚染されていたとしたら、受け取る側に止める手立てはほとんどありません。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの脅威として「サプライチェーンや委託先を狙った攻撃」が第2位に挙げられており、これは8年連続の選出です。一過性の流行ではなく、構造的・継続的に重視され続けている脅威だと捉える必要があります。

この記事では、サプライチェーン攻撃を「ソフトウェア経由」「ハードウェア経由」「サービス・委託先経由」の3つの経路に分けて構造を分解し、実際に起きた事例をもとに何が起きるのかを確認します。そのうえで、完全には防げないこの攻撃に対して、被害の確率と影響をどう下げていくか、実務での判断基準まで掘り下げます。

サプライチェーン攻撃とは何か。なぜ「信頼」が狙われるのか#

通常の攻撃は、標的のシステムに存在する脆弱性や、利用者のミスを直接突きます。これに対してサプライチェーン攻撃は、標的が日常的に信頼して受け入れているもの、つまり「検証せずに通してしまう経路」を汚染します。攻撃者から見れば、堅牢な標的を直接攻めるより、その標的に部品やサービスを供給している、より守りの弱い組織を一つ落とすほうが効率的です。一つの供給元を汚染できれば、そこを使う多数の組織に一度に到達できる、いわば「一対多」の攻撃になります。

ここで鍵になるのが「信頼の連鎖（チェーン）」という言葉です。あなたのシステムはライブラリAを信頼し、ライブラリAはビルドツールBを信頼し、配布サーバーCを信頼している。この鎖のどこか一箇所でも乗っ取られると、最終的な利用者まで汚染が伝播します。そして利用者は、その鎖の途中で何が起きたかを直接は見られません。届いた成果物が「正規のもの」に見えてしまうからです。

誤解しやすいのは、これを「他人の問題」と捉えてしまうことです。供給元が侵害された場合でも、最終的に情報漏えいや業務停止という被害を負うのは利用者側です。法的・契約的な責任の所在は別として、事業へのダメージは自社に降りかかります。だからこそ「供給元任せ」にせず、受け取る側でも被害を局所化し、異常を検知できる構えを持つことが重要になります。

3つの侵入経路で構造を分解する#

サプライチェーン攻撃は手口が多様で全体像をつかみにくいため、侵入経路で分類すると整理しやすくなります。ここでは代表的な3経路を、何が信頼の対象になっているかとあわせて示します。

ソフトウェア経由#

開発・運用の現場で特に接点が多く、報告される事例も多いのがこの経路です。現代のアプリケーションは、自分が書いたコードよりはるかに大量の外部ライブラリ（直接依存とその先の間接依存）の上に成り立っています。攻撃者はこの依存の鎖のどこかに悪意あるコードを忍び込ませます。手口は、人気パッケージに似た名前を付けて誤インストールを狙う「タイポスクワッティング」、メンテナの信頼を時間をかけて獲得してから本体に仕込む手口、ビルドや配布の基盤そのものを乗っ取る手口など、多岐にわたります。

ハードウェア経由#

サーバー、ネットワーク機器、IoT機器などの製造・流通の過程で、不正な部品や改ざんされたファームウェアが仕込まれる経路です。ソフトウェアに比べると一般企業が遭遇する頻度は低めですが、いったん成立すると、OSより低いレイヤーで動作するため検知が極めて難しくなります。重要インフラや防衛、政府調達の文脈で特に重視されており、調達段階での供給元評価が中心的な対策になります。

サービス・委託先経由#

運用やシステム管理を外部に委託している場合、その委託先（MSPやSaaS事業者を含む）が侵害されると、委託先が持つ正規のアクセス権限を経由して、標的のシステムに正面突破されてしまいます。委託先は業務上、標的の内部に強い権限で入れることが多いため、攻撃者にとって価値の高い踏み台になります。テクノロジー企業だけでなく、保守・運用・コンサルティングなど、自社に出入りするすべての取引先がこの経路の起点になり得ます。

実例で見る攻撃の構造#

抽象論だけでは実感がわきにくいため、事実が確認できる代表的な事例で構造を確認します。

SolarWinds（SUNBURST）: 更新配信の汚染#

ネットワーク監視製品SolarWinds Orionのビルド過程に悪意あるコードが注入され、正規のソフトウェア更新として配布された事例です。MITRE ATT&CKはこれをキャンペーンC0024として記録しており、APT29による高度なサプライチェーン作戦と位置づけています。最初の活動は2019年8月にさかのぼり、発覚したのは2020年12月中旬。トロイの木馬化された更新を受け取った顧客は約18,000にのぼるとされ、そのうちの一部に対して追加の侵害活動が行われました。

この事例の恐ろしさは、利用者が「正規ベンダーの正規署名つき更新」を、正しい手順で適用しただけで侵害された点にあります。受け取る側のパッチ運用は何も間違っていません。汚染はビルド工程という、利用者からは見えない上流で起きていました。

SolarWinds Compromise（C0024）の時期や規模は MITRE ATT&CK の記載に基づきます。初出2019年8月、発覚2020年12月中旬、影響を受けた顧客は約18,000とされます。

XZ Utils（CVE-2024-3094）: OSSメンテナ権限の悪用#

2024年に発覚した、Linuxで広く使われる圧縮ライブラリxz/liblzmaへのバックドア混入事例です。NVDの記載によれば、xzのバージョン5.6.0以降の配布用tarballに悪意あるコードが含まれ（実際に汚染版として配布されたのは5.6.0と5.6.1）、一連の複雑な難読化を経て、liblzmaのビルド過程で特定の関数が改ざんされる仕組みでした。CVSS基本値は最大の10.0（Critical）です。

技術的な手口もさることながら、より示唆的なのは「人間の信頼」が標的になった点です。攻撃者は長期間にわたってプロジェクトに貢献し、メンテナとしての信頼を獲得したうえで仕込みを行ったとされます。この事例は、広く使われている安定版の更新ですら無条件には信頼できないこと、そして発見が幸運な偶然に依存しうることを示しました。

Log4Shell（CVE-2021-44228）との関係#

広く使われるライブラリの欠陥が一斉に影響を及ぼすという意味で、2021年のLog4j2の脆弱性Log4Shell（CVE-2021-44228、CVSS 10.0）もサプライチェーンの問題として語られます。これは悪意ある混入ではなく機能設計上の脆弱性ですが、「自分が直接書いていない、深い依存の奥にあるコンポーネントが攻撃面になる」という構造は共通しています。多くの組織が「自社のどこでLog4jを使っているか」を即答できず、把握そのものに苦労しました。この教訓は

防御の核心は「無条件の信頼」を減らすこと#

サプライチェーン攻撃は供給元の侵害に起因するため、利用者側で100%防ぐことはできません。だからこそ防御の発想を「侵入を完全に止める」から「無条件に信頼している部分を減らし、汚染が起きても被害を局所化し、早く気づける状態にする」へと切り替えます。これはゼロトラストの考え方を、社外の供給元にまで広げる発想だと言えます。

NISTはこの領域を「サイバーセキュリティ・サプライチェーンリスク管理（C-SCRM）」として体系化しており、その実務ガイドが SP 800-161 Rev.1（Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations）です。重要なのは、これを技術部門だけの課題にせず、調達・契約・全社のリスク管理に統合する点です。供給元の選定や契約条件そのものが、セキュリティ対策の一部になります。

具体的な打ち手は、次の4層で考えると整理しやすくなります。

ここで現実的な優先順位として最初に効くのは、「把握」の徹底です。何を使っているか分からなければ、脆弱性が公表されたときに自社が影響を受けるかどうかすら判断できません。SBOMの整備とSCAの導入は、地味ですが費用対効果の高い第一歩です。依存ライブラリ管理の具体的な進め方は

委託先・取引先リスクの実務的な扱い#

技術的な対策と並んで重要なのが、契約と運用の面です。委託先経由の侵入は、技術だけでは閉じられません。委託先に求めるセキュリティ要件を契約に明記する、インシデント発生時の報告義務とタイムラインを取り決める、再委託（委託先がさらに別へ委託すること）の範囲を把握する、といった調達・契約レベルの取り組みが効いてきます。

運用面では、委託先に渡すアクセス権限の最小化が最大の防御線です。「常時・広範囲」のアクセスを与えていると、その委託先が侵害された瞬間に自社が丸ごと露出します。必要なときに、必要な範囲だけ、期限付きで権限を付与し、使われ方を監視する。これは委託先を疑うという話ではなく、どこか一箇所の事故が連鎖しない構造を作るという話です。

ここでの判断基準は「その取引先が侵害されたら、自社にどんな被害が及ぶか」です。機微な情報を預けている、自社システムに強い権限で入れている、業務が止まると事業に直結する。こうした条件に当てはまる相手ほど、評価と権限管理を手厚くします。逆に影響が限定的な相手にまで重い手続きを課すと、形骸化を招きます。

よくある誤解と判断の指針#

実務でつまずきやすいのは、「対策の効果には限界がある」という前提を受け入れられないケースです。サプライチェーン攻撃は供給元の侵害に起因する以上、利用者側の努力だけでゼロにはできません。これは諦めではなく、だからこそ「侵入されても被害を小さくする」「早く気づく」側に投資する、という合理的な判断につながります。完璧な予防に固執して検知・対応を後回しにするのは、優先順位を誤っています。

もう一つの誤解は、署名やハッシュの検証があれば安全だという思い込みです。SolarWindsやXZ Utilsが示したのは、署名が正規であっても、署名される前の段階（ビルドや本体への混入）で汚染されていれば意味をなさないということです。署名検証は配布経路での改ざん検知には有効ですが、上流が侵害されたケースは別の手段（行動の監視、依存の精査、最小権限）で補う必要があります。

よくある質問#

まとめ#

サプライチェーン攻撃は、自社のシステムが堅牢かどうかとは別の軸で迫ってくる脅威です。完全な予防は望めない以上、防御の重心を「無条件の信頼を減らし、被害を局所化し、早く気づく」側に置くことが現実的な答えになります。まずは「自分たちが何を信頼して使っているのか」を可視化するところから始めてください。広く使われるコンポーネントが一斉に攻撃面になる構造については