「導入しているソフトウェアは正規品だし、アップデートも公式サイトから適用している」――その安心感が、サプライチェーン攻撃の狙い目になっています。正規のソフトウェアや信頼している取引先を経由して攻撃が仕掛けられるため、従来のセキュリティ対策だけでは検知が極めて難しい脅威です。
IPAの「情報セキュリティ10大脅威 2025」でも「サプライチェーンの弱点を悪用した攻撃」は組織向け脅威の上位に位置付けられています。大企業だけでなく、むしろサプライチェーンの末端にいる中小企業こそが踏み台として狙われやすいのが現実です。
この記事では、サプライチェーン攻撃の仕組み・代表的な攻撃パターン・組織として取るべき対策について、中小企業の情シス担当でも実践できるレベルで解説します。

サプライチェーン攻撃とは?なぜ今、最も警戒すべき脅威なのか
サプライチェーン攻撃とは、標的とする組織を直接攻撃するのではなく、その組織が利用するソフトウェア・サービス・取引先などの「供給網(サプライチェーン)」を経由して侵入する攻撃手法の総称です。
従来のサイバー攻撃は、標的のシステムに直接侵入を試みるものが主流でした。しかし、大企業がセキュリティ投資を強化した結果、直接侵入のハードルが上がっています。そこで攻撃者が目を付けたのが、セキュリティ対策が比較的手薄な取引先やソフトウェアの開発元です。
サプライチェーン攻撃が深刻な脅威である理由は主に3つあります。
・正規のルートで侵入される: 公式のソフトウェア更新や信頼された取引先経由のため、ファイアウォールやウイルス対策ソフトが反応しにくい
・被害が連鎖的に拡大する: 1社の侵害が、その製品やサービスを利用する数千・数万の組織に波及する可能性がある
・発見までに時間がかかる: 正規のプロセスに紛れ込むため、侵害を検知するまでに数か月かかるケースも珍しくない
サプライチェーン攻撃の類型 ― 攻撃者はどこを狙うのか
サプライチェーン攻撃には複数のパターンがあります。防御策を考えるうえで、攻撃者がどの経路を狙っているかを理解しておくことが重要です。
1. ソフトウェアサプライチェーン攻撃
最も報道されることが多いパターンです。ソフトウェアの開発・配布プロセスに悪意あるコードを混入し、正規のアップデートとしてユーザーに配布します。
2020年に発覚したSolarWinds社のネットワーク管理ツール「Orion」への攻撃は、この類型の代表例です。攻撃者はOrionのビルドプロセスにバックドアを仕込み、正規のアップデートとして約18,000の組織に配布しました。米国政府機関を含む多くの組織が影響を受け、サプライチェーン攻撃の危険性を世界に知らしめた事件でした。
また、オープンソースのライブラリに悪意あるコードが混入されるケースも増えています。多くのソフトウェアがオープンソースの部品を組み合わせて開発されているため、1つのライブラリが汚染されると、それを利用するすべてのソフトウェアに影響が及びます。
2. マネージドサービス経由の攻撃
IT運用を外部の管理サービスプロバイダー(MSP)に委託している場合、MSPのシステムが侵害されると、MSPが管理するすべての顧客企業に被害が波及します。
2021年のKaseya社への攻撃では、同社のIT管理ツール「VSA」の脆弱性が悪用され、VSAを利用していたMSP経由で約1,500の組織がランサムウェアに感染しました。中小企業がITインフラ管理をMSPに任せるケースは多いため、この攻撃パターンは特に注意が必要です。
3. ハードウェア・ファームウェア経由の攻撃
ネットワーク機器・IoTデバイス・USBメモリなどのハードウェアや、そのファームウェアに細工を施すパターンです。製造段階や流通段階で不正なチップやファームウェアを組み込むことで、ソフトウェアレベルでの検知が困難な侵害を実現します。
ソフトウェア型と比べて発生頻度は低いものの、検知と修復が極めて困難であるため、重要インフラや軍事・政府関連では大きなリスクとして認識されています。
4. ビジネスサプライチェーン攻撃(取引先経由)
取引先のメールアカウントやファイル共有システムを侵害し、正規の業務連絡を装って標的企業に攻撃を仕掛けるパターンです。取引先からのメールは疑いなく開封されやすいため、フィッシングやマルウェア配布の成功率が高くなります。
国内でも、大手自動車メーカーの部品サプライヤーがランサムウェアに感染し、完成車工場の操業が停止した事例が報道されています。この場合、直接攻撃されたのはサプライヤーですが、被害は取引先である大手メーカーにまで及びました。
以下は、各攻撃パターンの特徴をまとめた表です。
| 攻撃パターン | 攻撃の入口 | 影響範囲 | 検知難易度 |
|---|---|---|---|
| ソフトウェア | 開発・配布プロセスへのコード混入 | ユーザー全体(数千〜数万社) | 非常に高い |
| マネージドサービス | MSPの管理ツールの脆弱性 | MSPの全顧客 | 高い |
| ハードウェア | 製造・流通段階での改ざん | 該当機器の利用者 | 極めて高い |
| ビジネス(取引先) | 取引先のアカウント侵害 | 取引先ネットワーク全体 | 中程度 |

具体的な防御手順 ― サプライチェーンリスクを下げるために
サプライチェーン攻撃を完全に防ぐことは、正規のルートを悪用される以上、容易ではありません。しかし、攻撃の成功確率を下げ、被害を早期に検知し、影響を最小限に抑えることは可能です。
1. SBOM(ソフトウェア部品表)で依存関係を把握する
SBOM(Software Bill of Materials)とは、自社のシステムで使用しているソフトウェアとその構成部品(ライブラリ・フレームワーク等)の一覧表です。何を使っているかが分かっていなければ、脆弱性が公表されても「自社に影響があるのか」すら判断できません。
# SBOMの管理項目の例 # - ソフトウェア名とバージョン # - 利用しているオープンソースライブラリとバージョン # - ライセンス情報 # - 開発元・提供元の情報 # - 最終更新日
大規模なSBOM管理ツールの導入が難しい場合でも、「どのサーバーにどのソフトウェアのどのバージョンが入っているか」をスプレッドシートで管理するだけでも、脆弱性情報が公表された際の初動対応が格段に速くなります。
2. ベンダー・取引先のセキュリティ評価を実施する
自社のセキュリティがいくら強固でも、取引先やベンダーのセキュリティが脆弱であれば、そこが攻撃の入口になります。新規取引の開始時や契約更新時に、以下のポイントを確認しましょう。
・セキュリティポリシーの有無: 情報セキュリティ基本方針が公開されているか
・認証の取得状況: ISMS(ISO 27001)やプライバシーマーク等の第三者認証を取得しているか
・インシデント対応体制: セキュリティインシデント発生時の連絡体制・対応フローが整備されているか
・データの取り扱い: 自社のデータがどのように保管・処理されるか
3. ソフトウェア更新の検証プロセスを設ける
「アップデートは即座に適用する」というのが一般的なセキュリティの鉄則ですが、サプライチェーン攻撃の文脈では、正規のアップデートそのものにリスクがある場合があります。すべての更新を疑えというわけではありませんが、重要なシステムについては検証ステップを挟むことが望ましいです。
・テスト環境での事前検証: 本番環境に適用する前に、テスト環境で動作確認を行う
・配布元の正当性の確認: ダウンロードURLが公式サイトであること、ハッシュ値(チェックサム)が公式の値と一致することを確認する
・段階的な展開: 全端末に一斉適用するのではなく、少数の端末に先行適用して様子を見る
# ダウンロードしたファイルのハッシュ値を検証する例(Linux) sha256sum downloaded-software.tar.gz # 出力されたハッシュ値を公式サイトの値と比較する
4. ネットワークの監視と分離を強化する
サプライチェーン攻撃で侵入されても、被害を局所化するために、ネットワークセグメンテーションと通信監視が有効です。
・ネットワークセグメンテーション: 社内ネットワークを業務単位で分離し、セグメント間の通信を最小限に制限する。1台が侵害されても横展開を防げる
・外向き通信の監視: 正規のソフトウェアが不審な外部サーバーと通信していないか監視する。C2サーバー(指令サーバー)との通信を早期に検知できる
・ログの集約と分析: ファイアウォール・プロキシ・認証システムのログを集約し、異常なパターンを検知する
5. インシデント対応計画を策定する
サプライチェーン攻撃を受けた場合、自社だけでなく取引先や顧客にも影響が及ぶ可能性があります。事前に対応計画を準備しておくことで、被害拡大を最小限に抑えられます。
・連絡先の整備: 主要ベンダー・取引先のセキュリティ担当の連絡先を一覧化しておく
・遮断手順の明確化: 侵害が確認された場合に、どのシステム・ネットワークを遮断するか事前に決めておく
・バックアップの確認: ランサムウェアを伴うサプライチェーン攻撃に備え、オフラインバックアップが正常に取得できていることを定期的に確認する
中小企業でも今日からできること
「SBOMの管理」「ベンダー評価」と聞くと大企業向けの話に感じるかもしれません。しかし、サプライチェーン攻撃のリスクを下げるために、規模や予算に関係なくすぐに着手できることがあります。
| 対策 | 内容 | コスト |
|---|---|---|
| 使用ソフトウェアの棚卸し | 業務で使っているソフトウェアとバージョンをスプレッドシートに一覧化する | 無料 |
| 管理者権限の棚卸し | 外部サービスやツールの管理者アカウントが誰に付与されているか確認し、不要な権限を削除する | 無料 |
| MFAの導入 | クラウドサービス・メール・VPNなど外部から接続できるサービスに多要素認証を設定する | 無料〜低額 |
| アップデートのハッシュ確認 | 重要なソフトウェアのアップデート適用前に、公式サイトのチェックサムと照合する習慣をつける | 無料 |
| 取引先との連絡体制の整備 | 主要取引先のセキュリティ担当(または窓口)の連絡先を把握し、インシデント時の連絡フローを決めておく | 無料 |
| オフラインバックアップ | 重要データのバックアップをネットワークから切り離された媒体(外付けHDD等)にも定期的に取得する | 低額 |
特に効果が高いのは「MFAの導入」と「使用ソフトウェアの棚卸し」です。取引先のアカウントが侵害されてもMFAがあれば自社への不正アクセスを防げますし、ソフトウェアの一覧があれば脆弱性情報が出た際にすぐ「自社に影響があるか」を判断できます。
よくある誤解と注意点
【注意】「大手ベンダーの製品だから安全」ではない
SolarWinds事件が示したように、世界的に信頼されていたベンダーの製品であっても、開発プロセスが侵害されれば攻撃の媒介になります。「有名だから安心」という思考は、サプライチェーン攻撃の前では通用しません。ベンダーの知名度ではなく、セキュリティ体制の実態を確認することが重要です。
【注意】「自社は直接狙われるような企業ではない」という認識は危険
サプライチェーン攻撃では、最終的な標的は大企業や政府機関であっても、その攻撃ルートとして中小企業が踏み台にされます。自社が「攻撃の本命」でなくても、取引先を通じて攻撃の入口にされるリスクは常にあります。実際に、セキュリティ対策が手薄な下請け企業が侵入口となり、最終的に親会社のシステムに到達されたケースは国内でも複数報告されています。
【注意】「アップデートを止めればいい」は逆効果
「正規のアップデートが攻撃に使われるなら、アップデートを止めればいいのでは」と考えるのは危険です。アップデートを適用しないことで既知の脆弱性がそのまま残り、別の攻撃に対して無防備になります。サプライチェーン攻撃のリスクよりも、既知脆弱性を放置するリスクの方がはるかに高いのが実態です。アップデートの適用を止めるのではなく、検証プロセスを挟むことが正しい対応です。

本記事のまとめ
サプライチェーン攻撃は、信頼しているソフトウェアや取引先を経由して侵入するため、従来の境界防御だけでは防げない深刻な脅威です。しかし、ソフトウェアの棚卸し・ベンダー評価・更新の検証プロセス・ネットワーク分離・インシデント対応計画の整備を組み合わせることで、攻撃の成功確率を下げ、被害を最小限に食い止めることができます。
まず取り組むべきは、自社で利用しているソフトウェアの一覧化(簡易SBOM)と、主要取引先との連絡体制の確認です。「自社は大丈夫」ではなく「自社が踏み台にされるかもしれない」という前提で備えることが、サプライチェーン全体のセキュリティ向上につながります。
| 防御策 | 効果 | 優先度 |
|---|---|---|
| SBOM(ソフトウェア部品表)の管理 | 脆弱性公表時の影響範囲を即座に特定できる | 最優先 |
| ベンダー・取引先のセキュリティ評価 | 攻撃の入口となる弱いリンクを事前に把握する | 最優先 |
| ソフトウェア更新の検証プロセス | 正規アップデートに紛れた攻撃を検知する | 高 |
| ネットワーク監視と分離 | 侵入後の横展開とC2通信を早期に検知・遮断する | 高 |
| インシデント対応計画 | 被害発覚後の初動対応を迅速化し、影響を最小化する | 高 |
ゼロデイ攻撃やランサムウェアの仕組みについては、本サイトの「ゼロデイ攻撃とは?」や「ランサムウェアとは?」の記事で詳しく解説しています。ネットワーク分離の考え方については「ゼロトラストとは?」の記事もあわせてご覧ください。
Linuxサーバーのアクセス制御やログ監視の詳細については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
あなたの会社がサプライチェーン攻撃の「踏み台」にならないために
自社だけでなく取引先全体を守るには、セキュリティの基礎知識を体系的に理解することが欠かせません。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。

コメント