はじめに
近年、ランサムウェアを中心としてセキュリティインシデントのニュースが目立っています。
しかし、その定義や具体的な手口、そして「なぜ今急増しているのか」について、自信を持って説明できるでしょうか？
今回は、IPAの「情報セキュリティ10大脅威 2025[組織]」でも第2位に入っている「サプライチェーン攻撃」について、エンジニア視点で解説します。
1. そもそも「サプライチェーン攻撃」とは？
サプライチェーン攻撃とは、「防御が堅固なターゲット（本丸）」を直接攻撃するのではなく、セキュリティが比較的脆弱な「供給元・供給先（サプライチェーン）」の弱点を突いて侵入する攻撃手法の総称です。
🔍 混同しやすい？「マルウェア」との違い
ニュースでは「サプライチェーン攻撃」と「ランサムウェア」が並列に語られることがありますが、これらは比較するものではなく、組み合わせられるものです。
-
サプライチェーン攻撃 = 侵入ルート (How)
- どうやってターゲットに到達するか（経路）。
-
マルウェア / ランサムウェア = 凶器 (What)
- 到達した後に何を使って攻撃するか（実行コード）。
▼ 概念図
宅配便でたとえると…
- 通常の攻撃: 泥棒が凶器（マルウェア）を持って、窓を割って無理やり入る。
- サプライチェーン攻撃: 信頼する**「宅配業者（正規ソフトや取引先）」が、「爆弾（マルウェア）」が入った荷物**を家の中まで届けに来る。
私たちは「正規のルート」からのアクセスを信頼してしまうため、検知が非常に難しいのが特徴です。
2. どこから来るのか？ 3つの侵入経路
サプライチェーン攻撃は、侵入経路によって大きく3つのタイプに分類できます。
エンジニアとして特に意識すべきなのは「ソフトウェアサプライチェーン」ですが、組織全体を守る視点では他の2つも重要です。
① ソフトウェアサプライチェーン（開発プロセスへの攻撃）
私たちエンジニアにとって最も身近な脅威です。開発ライフサイクルの各段階が標的になります。
-
ライブラリ/OSSの汚染:
-
タイポスクワッティング: 有名なパッケージ名に似せた偽パッケージを登録する（例:
react→raect）。 -
依存関係の悪用: 正規のOSSメンテナのアカウントを乗っ取り、悪意あるコードを混入させる（後述するXZ Utilsの事例など）。
-
開発環境・ビルドパイプラインの侵害:
-
CI/CDツール（Jenkins, GitHub Actionsなど）の設定ミスや脆弱性を突き、ビルドプロセス中でマルウェアを埋め込む。
② サービス・ハードウェアサプライチェーン
IT機器や運用委託先を物理的・システム的に利用するルートです。
-
委託先・MSP（マネージドサービスプロバイダ）経由:
-
保守運用のために接続されている回線や、リモート管理ツールを踏み台にする。
-
ハードウェア/ファームウェア:
-
PCやサーバーの出荷段階で、既にマルウェアが仕込まれているケース。
③ ビジネスサプライチェーン
組織的な「信頼関係」を悪用するルートです。
- 関連会社・取引先からの侵入:
- セキュリティ対策が手薄な海外拠点や子会社、あるいは取引先のメールアカウントを乗っ取り、そこから正規の業務連絡を装ってマルウェアを送付する（Emotetなどの拡散手口）。
3. なぜ今、急増しているのか？
主な理由は2つあります。
- 正面突破が難しくなった
- 大企業や主要サービスのセキュリティ境界（Firewall, EDR等）が強化され、攻撃者にとって正面からの攻撃は「コスパが悪く」なりました。
- 依存関係の複雑化（DevOps/OSS）
- 現代のソフトウェア開発は、大量の外部ライブラリ（OSS）やSaaS、外部ベンダーに依存しています。
- 「攻撃可能な接点」が幾何級数的に増えています。
4. 代表的な事例から学ぶ
ここでは、性質の異なる2つの重要な事例を紹介します。
🏥 事例A：大阪急性期・総合医療センター（2022年）
〜組織の繋がり（ビジネス・サービス）を狙う攻撃〜
2022年、大阪の基幹病院がランサムウェア被害に遭い、電子カルテが使用不能に。診療停止など地域医療に甚大な被害が出ました。
- 侵入経路:
- 攻撃者は直接病院を狙ったのではなく、**「給食委託事業者」**のシステムに侵入しました。
- 給食事業者が使用していたVPN機器（FortiGate）の脆弱性が放置されており、そこを踏み台に、閉域網を経由して病院サーバーへ侵入されました。
📦 事例B：XZ Utils（2024年）
〜利用するモノ（ソフトウェア）を狙う攻撃〜
Linuxの多くのディストリビューションに含まれる圧縮ツール xz (liblzma) に、バックドアが仕込まれそうになった事件です。発覚が遅れれば、世界中のSSHサーバーが乗っ取られる可能性がありました。
-
手口：ソーシャルエンジニアリング
-
攻撃者（Jia Tanと名乗る人物）は、数年かけてOSSコミュニティに貢献し、**「信頼できるメンテナ」**の地位を獲得しました。
-
その権限を利用して、高度に難読化された悪意あるコードをテストデータに紛れ込ませました。
-
発見のきっかけ:
-
Microsoftのエンジニアが「PostgreSQLのベンチマーク時に、SSHのログインが0.5秒遅い」という違和感に気づき、執念の調査で発覚。偶然による発見に世界が震えました。
5. 私たちができる対策
「サプライチェーン攻撃」は完全に防ぐことが難しいため、**「侵入リスクを下げる（防御）」と「被害を最小限にする（検知・回復）」**の両輪が必要です。
🛡️ 防御（Prevent）
- 多要素認証（MFA）の徹底
- GitHub、AWS、SaaSなど、開発・運用に関わる全アカウントで必須化する。
- 依存関係の管理
- DependabotやRenovateを導入し、ライブラリを常に最新に保つ。
- 使用するOSSの評価（メンテナは活動しているか？ スター数は？）。
- 委託先管理
- 外部ベンダーとの接続において「境界」を設ける（Zero Trustの考え方）。無条件に信頼しない。
🔍 検知・対応（Detect & Respond）
- SBOM（Software Bill of Materials）の整備
- 「自分たちが何を使っているか」を把握していなければ、脆弱性が発表されても影響有無がわかりません。
- ログの監視と「違和感」への感度
- XZ Utilsの事例のように、わずかなパフォーマンス低下や不審な通信ログが発見の鍵になります。
6. まとめ
- サプライチェーン攻撃は、「信頼」を逆手に取った攻撃であり、誰にとっても他人事ではありません。
- 「OSSを使うな」「外部委託するな」というのは非現実的です。
- 「利用するリスク」を正しく理解し、自社のコードだけでなく、依存先や委託先を含めた広い視野でセキュリティを考える必要があります。
株式会社Inner Resource のエンジニアブログです。 忙しい研究者・研究施設の業務効率化のためのクラウド購買管理ソフト「リプルア」を開発しています。
Discussion