世界を震撼させたサプライチェーン攻撃
海外では、国家支援型の攻撃グループによる大規模なサプライチェーン攻撃が相次いで発生しています。これらの攻撃は、その巧妙さと被害規模において、サイバーセキュリティの歴史に残る事件となっています。
- 国家支援型攻撃の存在
- SolarWinds事件ではロシアのAPT29、3CX事件では北朝鮮のLazarusグループなど、国家の支援を受けた攻撃グループの関与が指摘されています。これらのグループは豊富なリソースと高度な技術を持ち、長期間にわたる持続的な攻撃を行います。標的型攻撃（APT）の詳細をご覧ください。
- ソフトウェアサプライチェーンが主戦場
- 海外の事例では、ソフトウェアのビルドプロセスや配布経路を侵害する「ソフトウェアサプライチェーン攻撃」が多く見られます。正規のアップデートにマルウェアを仕込むことで、大規模な感染を引き起こします。ソフトウェアサプライチェーン攻撃で詳しく解説しています。
- グローバル企業への影響
- SolarWinds、Kaseya、NotPetyaなどの事例では、世界中の企業や政府機関が影響を受けました。グローバルにビジネスを展開する日本企業にとっても、これらの事例は他人事ではありません。
以下では、代表的な海外事例を詳しく分析し、その手口と教訓を解説します。
SolarWinds事件（2020年12月）
SolarWinds事件は、サプライチェーン攻撃の脅威を世界に知らしめた象徴的な事件です。ネットワーク監視ソフトのアップデート経由で1万8千以上の組織にバックドアが仕込まれ、サイバーセキュリティ史上最大規模の攻撃の一つとなりました。
事例の概要
2020年12月、セキュリティ企業FireEyeが自社への攻撃を調査する中で、SolarWinds社のネットワーク監視ソフト「Orion」が侵害されていることを発見しました。
| 項目 | 内容 |
|---|---|
| 発見日 | 2020年12月（攻撃開始は2020年3月頃） |
| 被害企業 | SolarWinds社、およびOrion利用組織 |
| 攻撃者 | APT29/Cozy Bear（ロシア国家支援グループ）と推定 |
| 影響範囲 | 1万8千以上の組織にバックドア配布 |
| 主な被害組織 | 米国財務省、商務省、国土安全保障省、FireEye、Microsoft等 |
| 発覚までの期間 | 約9ヶ月 |
SolarWinds社のOrionは、フォーチュン500企業の多くや米国政府機関で使用されている、業界標準のネットワーク監視ソフトウェアでした。攻撃者はこの広く使われているソフトウェアを標的にすることで、大規模な侵害を実現しました。
攻撃の手口（SUNBURST）
SolarWinds事件の攻撃手口は非常に巧妙であり、複数の段階を経て実行されました。
- 第1段階：SolarWindsのビルド環境への侵入
- 攻撃者は、SolarWinds社のソフトウェア開発・ビルド環境に侵入しました。どのように侵入したかは完全には解明されていませんが、パスワードスプレー攻撃や内部関係者の認証情報窃取などの可能性が指摘されています。
- 第2段階：ビルドプロセスへの悪意あるコードの注入
- 攻撃者は、Orionのビルドプロセスに「SUNBURST」と呼ばれるバックドアコードを注入しました。このコードは、正規のOrionコードに溶け込むように巧妙に作成されていました。
- 第3段階：正規署名付きアップデートとして配布
- SUNBURSTを含むOrionアップデートは、SolarWindsの正規のデジタル署名が施され、通常のアップデート経路で配布されました。利用組織にとっては、信頼できるベンダーからの正規アップデートにしか見えませんでした。
- 第4段階：顧客環境でのバックドア確立
- アップデートをインストールした組織では、SUNBURSTがアクティベートされ、攻撃者のC2（コマンド&コントロール）サーバーと通信を開始しました。ただし、SUNBURSTは約2週間の休眠期間を設けており、インストール直後の検知を回避しました。
- 第5段階：標的の選定と更なる侵入
- 攻撃者はすべての感染組織に深く侵入したわけではなく、戦略的価値の高い組織を選別して更なる攻撃を行いました。選ばれた組織に対しては、追加のマルウェアを展開し、長期的なアクセスを確立しました。
攻撃の巧妙さは、検知回避の工夫にも現れています。正規のソフトウェアプロセスを装う、休眠期間を設ける、通信を正規のトラフィックに偽装するなど、様々な手法が使われていました。
被害の規模と影響
SolarWinds事件の影響は、サイバーセキュリティ史上最大級のものでした。
- 影響を受けた組織の範囲
- Orionの侵害されたバージョンをインストールした組織は1万8千以上に上ります。ただし、攻撃者が積極的に侵入したのはそのうちの一部（数百組織程度）と推定されています。
- 米国政府機関への影響
- 米国財務省、商務省、国土安全保障省、国務省、エネルギー省など、複数の連邦政府機関が被害を受けました。機密情報へのアクセスがあった可能性も指摘されています。
- セキュリティ企業への影響
- 皮肉にも、最初に攻撃を発見したFireEye自身も被害者でした。同社の内部ツール（レッドチーム用ツール）が窃取されました。Microsoftも影響を受け、一部のソースコードへの不正アクセスがあったことを公表しました。
- 発覚までの長期間
- 攻撃開始から発覚まで約9ヶ月を要しました。この間、攻撃者は検知されることなく活動を続けていました。これは、サプライチェーン攻撃の検知の難しさを示しています。
教訓
SolarWinds事件から得られる教訓を整理します。
- ソフトウェアサプライチェーンの脆弱性
- 信頼できるベンダーからのソフトウェアであっても、その開発・配布プロセスが侵害される可能性があります。「信頼」だけに頼らず、検証の仕組みが必要です。
- ビルド環境のセキュリティ
- ソフトウェアのビルド環境は、最終製品の信頼性に直結する重要な資産です。ビルド環境への厳格なアクセス制御、監視、完全性検証が求められます。CI/CDセキュリティで詳しく解説しています。
- 署名だけでは安全ではない
- デジタル署名は、ソフトウェアの改ざんを検知する重要な仕組みですが、ビルド環境自体が侵害されれば、正規の署名がついた悪意あるソフトウェアが作成されます。署名に加えて、他の検証手段も必要です。
- 国家レベルの攻撃者への備え
- 国家支援型の攻撃グループは、通常の攻撃者よりもはるかに高度な技術とリソースを持っています。重要なインフラや機密情報を扱う組織は、このレベルの脅威を想定した対策が必要です。
- SBOMの重要性
- 自社が使用しているソフトウェアに何が含まれているかを把握することが重要です。SBOM（Software Bill of Materials：ソフトウェア部品表）の導入により、脆弱なコンポーネントの特定や影響範囲の把握が容易になります。SBOMの詳細をご覧ください。
3CX事件（2023年3月）
3CX事件は、ビジネスコミュニケーションソフトウェアを狙ったサプライチェーン攻撃であり、「サプライチェーン攻撃のサプライチェーン攻撃」という二重構造が特徴的でした。
事例の概要
2023年3月、VoIPソフトウェア企業3CXのデスクトップアプリが改ざんされ、マルウェアが混入した状態で配布されていることが発覚しました。
| 項目 | 内容 |
|---|---|
| 発見日 | 2023年3月29日 |
| 被害企業 | 3CX社、およびデスクトップアプリ利用組織 |
| 攻撃者 | Lazarusグループ（北朝鮮国家支援グループ）と推定 |
| 影響範囲 | 60万以上の顧客企業が影響を受けた可能性 |
| 攻撃の特徴 | 二重のサプライチェーン攻撃 |
3CXは世界中で60万以上の企業に利用されているビジネス電話システムのプロバイダーであり、そのデスクトップアプリが改ざんされたことで、広範な影響が生じる可能性がありました。
連鎖的なサプライチェーン攻撃
3CX事件の最も注目すべき特徴は、その攻撃経路の複雑さにあります。
- 最初の攻撃：Trading Technologies社への侵害
- 攻撃は、3CXへの直接攻撃ではなく、3CXの開発者が使用していた別のソフトウェアから始まりました。Trading Technologies社の金融取引ソフトウェア「X_TRADER」が最初に侵害されていました。
- X_TRADER経由での3CX開発環境への侵入
- 3CXの従業員がX_TRADERの侵害されたバージョンを使用したことで、その開発者の端末が感染しました。攻撃者はこの端末を足がかりに、3CXの開発環境にアクセスしました。
- 3CXデスクトップアプリの改ざん
- 攻撃者は3CXの開発環境に侵入し、デスクトップアプリのビルドプロセスに悪意あるコードを注入しました。改ざんされたアプリは、正規の配布経路で顧客に配布されました。
- 「二重のサプライチェーン攻撃」
- この事例は、サプライチェーン攻撃を実行するためにサプライチェーン攻撃を使うという、入れ子構造の攻撃でした。最終的な標的（3CX顧客）に到達するまでに、2つのソフトウェアサプライチェーンが侵害されました。
教訓
3CX事件から得られる教訓を整理します。
- 連鎖的な攻撃の危険性
- 攻撃者は、直接の標的ではなく、その標的にアクセスできる別の組織を狙うことがあります。自社のセキュリティだけでなく、自社が使用するツールやサービスのサプライチェーンにも注意が必要です。
- 開発者環境のセキュリティ
- 開発者の端末は、組織のコードベースへのアクセス権を持つ重要な資産です。開発者端末のセキュリティ強化、使用ソフトウェアの管理、異常検知が重要です。
- 使用するツールの信頼性確認
- 業務で使用するソフトウェア（特にサードパーティ製ツール）についても、そのセキュリティ状況を確認する必要があります。廃止されたソフトウェアや、サポートが終了したツールの使用は特にリスクが高いです。
ソフトウェアサプライチェーン攻撃への対策については、ソフトウェアサプライチェーン攻撃の対策で詳しく解説しています。
Kaseya VSA事件（2021年7月）
Kaseya事件は、MSP（マネージドサービスプロバイダ）を経由して1,500社以上にランサムウェアが配布された、サービスサプライチェーン攻撃の代表的な事例です。
事例の概要
2021年7月2日、Kaseya社のリモート管理ソフト「VSA」の脆弱性が悪用され、VSAを利用するMSP経由でその顧客企業にランサムウェア「REvil」が配布されました。
| 項目 | 内容 |
|---|---|
| 発生日 | 2021年7月2日（米国独立記念日の週末） |
| 被害企業 | 約60のMSP、1,500社以上の最終顧客 |
| 攻撃者 | REvilランサムウェアグループ |
| 攻撃手法 | VSAのゼロデイ脆弱性悪用 |
| 要求された身代金 | 総額7,000万ドル（約77億円） |
Kaseya VSAは、MSPが顧客企業のITインフラをリモートで管理するためのソフトウェアです。1つのMSPが数十〜数百の顧客を管理している場合もあり、MSPを狙うことで効率的に多数の組織に攻撃を波及させることができます。
攻撃の手口
Kaseya事件の攻撃は、以下のような手順で実行されました。
- ゼロデイ脆弱性の悪用
- 攻撃者は、Kaseya VSAに存在するゼロデイ脆弱性（当時未公開の脆弱性）を悪用しました。認証バイパスやSQLインジェクションなど、複数の脆弱性が組み合わせて使われました。
- VSAサーバーからの攻撃
- VSAサーバーに侵入した攻撃者は、VSAの機能を悪用して、そのサーバーが管理するすべてのエンドポイント（顧客企業のPC）にランサムウェアを配布しました。
- 「1対多」の管理関係の悪用
- MSPは通常、1つのVSAサーバーで多数の顧客を管理しています。攻撃者は、この「1対多」の関係を悪用し、1つのサーバーへの攻撃で多数の組織に被害を拡大させました。
- 週末のタイミング
- 攻撃は米国独立記念日の週末に実行されました。多くの組織でIT担当者が休暇を取っているタイミングを狙い、検知と対応を遅らせる意図があったと考えられます。
教訓
Kaseya事件から得られる教訓を整理します。
- サービスサプライチェーン（MSP）のリスク
- MSPやクラウドサービスは便利ですが、そのサービスが侵害された場合の影響は非常に大きくなります。MSPの選定時にはセキュリティ体制の確認が重要です。サービスサプライチェーン攻撃で詳しく解説しています。
- ゼロデイ脆弱性への備え
- ゼロデイ脆弱性は防ぎようがないと考えられがちですが、多層防御、ネットワークセグメンテーション、異常検知など、侵入を前提とした対策が有効です。
- リモート管理ツールのセキュリティ
- リモート管理ツール（VSA、RMM等）は、その性質上、管理対象システムへの強力なアクセス権を持っています。これらのツールのセキュリティ強化は特に重要です。
- 休日・週末の攻撃への備え
- 攻撃者は、防御側の体制が手薄になるタイミングを狙います。24時間365日の監視体制や、休日でも対応できるインシデント対応計画が必要です。
NotPetya（2017年6月）
NotPetyaは、史上最大の被害をもたらしたサプライチェーン攻撃の一つであり、被害総額は100億ドル以上と推定されています。
事例の概要
2017年6月27日、ウクライナの会計ソフト「M.E.Doc」のアップデートを通じて、破壊的なマルウェア「NotPetya」が配布されました。
| 項目 | 内容 |
|---|---|
| 発生日 | 2017年6月27日 |
| 初期感染経路 | ウクライナの会計ソフト「M.E.Doc」のアップデート |
| 攻撃者 | Sandworm（ロシア国家支援グループ）と推定 |
| 被害総額 | 100億ドル以上（推定） |
| 主な被害企業 | Maersk、FedEx（TNT）、Merck、Mondelez等 |
NotPetyaは、ランサムウェアを装っていましたが、実際にはデータを復旧させる意図のない「ワイパー」（破壊型マルウェア）でした。身代金を支払ってもデータは復旧せず、純粋な破壊を目的としていたと考えられています。
被害の規模
NotPetyaの被害は、サイバー攻撃史上最大級のものでした。
- Maersk（海運大手）
- 世界最大のコンテナ船運航会社であるMaerskは、ITインフラ全体の再構築を余儀なくされました。約4万5千台のPCと4千台のサーバーを置き換え、損失は約3億ドルに上りました。10日間で通常の20%しか貨物を扱えなかったとされています。
- FedEx（TNT Express）
- FedExの子会社TNT Expressは、システムが壊滅的な被害を受け、数週間にわたって通常業務ができませんでした。損失は約4億ドルと報告されています。
- Merck（製薬大手）
- 製薬大手Merckは、製造ラインを含むシステムが停止しました。損失は約8億ドル以上と推定されています。
- ウクライナ全土への影響
- M.E.Docはウクライナ企業の約80%が使用していたとされ、ウクライナ国内では銀行、政府機関、インフラ企業など広範な組織が被害を受けました。
教訓
NotPetya事件から得られる教訓を整理します。
- 地政学的リスクとサプライチェーン
- NotPetyaは、ロシア・ウクライナ間の緊張を背景とした攻撃と考えられています。地政学的リスクが高い地域に関連するソフトウェアやサービスの使用には、追加の注意が必要です。
- グローバルな被害の連鎖
- ウクライナを標的とした攻撃が、世界中のグローバル企業に波及しました。ウクライナに子会社や取引先がある企業が、そのネットワーク経由で感染しました。グローバルにビジネスを展開する企業は、世界中のリスクを考慮する必要があります。
- 復旧計画の重要性
- Maerskは、たまたま電源障害で停止していたガーナのドメインコントローラーから、Active Directoryを復旧することができました。この「偶然」がなければ、復旧はさらに困難だったとされています。バックアップと復旧計画の重要性を示す事例です。
- ランサムウェアとワイパーの区別困難
- NotPetyaはランサムウェアを装っていましたが、実際には復旧不能な破壊型マルウェアでした。身代金を支払っても回復しないケースがあることを示しています。
その他の海外事例
上記の代表的な事例以外にも、重要なサプライチェーン攻撃が発生しています。
Codecov事件（2021年）
Codecovは、コードカバレッジ（テストのカバー率）を測定するツールを提供する企業です。2021年、同社のBashアップローダースクリプトが改ざんされていたことが発覚しました。
攻撃者は、Dockerイメージ作成プロセスの欠陥を悪用し、Bashスクリプトを改ざんしました。このスクリプトは、CI/CD環境で実行される際に、環境変数（認証トークンやAPIキーを含む）を攻撃者のサーバーに送信するよう変更されていました。
Twitch、HashiCorp、Confluent、Twilioなど、複数の企業が影響を受けたことを公表しています。この事例は、ソーシャルエンジニアリングや直接的な侵入ではなく、自動化されたプロセスの脆弱性を突いた攻撃でした。
ua-parser-js事件（2021年）
ua-parser-jsは、ブラウザのUser Agent文字列を解析するJavaScriptライブラリで、npmで週間約700万ダウンロードを記録する人気パッケージでした。
2021年10月、このパッケージのメンテナのnpmアカウントが乗っ取られ、マルウェアを含むバージョンが公開されました。改ざんされたバージョンには、Linuxでは暗号通貨マイナー、Windowsではパスワードスティーラーとトロイの木馬が含まれていました。
この事例は、OSSエコシステムの脆弱性と、メンテナのアカウント保護の重要性を示しています。npmセキュリティで対策を解説しています。
event-stream事件（2018年）
event-streamは、Node.jsのストリーム処理ライブラリで、広く使用されていたOSSパッケージでした。
オリジナルのメンテナが開発を継続する時間がなくなり、協力を申し出た第三者にメンテナ権限を譲渡しました。しかし、この新しいメンテナは悪意を持っており、ビットコインウォレット「Copay」を標的としたマルウェアをパッケージに仕込みました。
この事例は、OSSのメンテナ継承におけるリスクと、依存関係の管理の重要性を示しています。
海外事例から学ぶ教訓
海外のサプライチェーン攻撃事例に共通する教訓を整理します。
- 教訓1：ソフトウェアサプライチェーンの脆弱性を認識する
- SolarWinds、3CX、NotPetyaなどの事例は、正規のソフトウェア配布経路が攻撃に悪用されうることを示しています。「信頼できるベンダーからのソフトウェアだから安全」という前提は成り立ちません。
- 教訓2：国家レベルの攻撃者の存在を意識する
- SolarWinds（ロシア）、3CX（北朝鮮）、NotPetya（ロシア）など、多くの事例で国家支援型攻撃グループの関与が指摘されています。重要なシステムを運用する組織は、このレベルの脅威を想定する必要があります。標的型攻撃（APT）の詳細をご覧ください。
- 教訓3：ビルド環境・CI/CDのセキュリティを強化する
- SolarWinds、Codecovなどの事例は、ソフトウェアのビルド・配布プロセスが攻撃者の標的になることを示しています。ビルド環境への厳格なアクセス制御、完全性検証、監視が重要です。CI/CDセキュリティで対策を解説しています。
- 教訓4：MSP/クラウドサービスのリスクを評価する
- Kaseya事件は、MSPやクラウドサービスが侵害された場合の影響の大きさを示しています。サービス選定時のセキュリティ評価、責任分界の明確化が重要です。サービスサプライチェーン攻撃をご覧ください。
- 教訓5：SBOMの導入を検討する
- 自社が使用するソフトウェアにどのようなコンポーネントが含まれているかを把握することが、脆弱性への迅速な対応を可能にします。米国ではSBOMの義務化が進んでいます。SBOMの詳細をご覧ください。
- 教訓6：グローバルな情報共有に参加する
- サプライチェーン攻撃の脅威は国境を越えます。CISA（米国）、ENISA（EU）、JPCERT/CCなどの機関が発信する情報を活用し、グローバルな脅威動向を把握することが重要です。
国家支援型攻撃について
海外のサプライチェーン攻撃事例の多くには、国家支援型攻撃グループの関与が指摘されています。
| 攻撃グループ | 関連国家 | 関連事例 | 主な特徴 |
|---|---|---|---|
| APT29/Cozy Bear | ロシア | SolarWinds | 高度な技術、長期的な諜報活動 |
| Sandworm | ロシア | NotPetya | 破壊的な攻撃、インフラ標的 |
| Lazarus | 北朝鮮 | 3CX | 金銭目的、暗号通貨標的 |
| APT41 | 中国 | 複数事例 | 諜報と金銭目的の両方 |
- 国家支援型攻撃の特徴
- 国家支援型攻撃グループは、豊富なリソース、高度な技術、長期的な視点を持っています。通常の攻撃者とは異なり、検知回避に多大な労力をかけ、数ヶ月から数年にわたる持続的な活動を行います。
- 企業としての備え
- 国家レベルの攻撃者に対して完璧な防御は困難ですが、多層防御、検知能力の強化、インシデント対応計画の整備により、被害を最小化することは可能です。重要なシステムについては、特に厳格なセキュリティ対策が求められます。
- 政府機関との連携
- 国家支援型攻撃の被害に遭った場合、CISA（米国）、NCSC（英国）、NISC（日本）などの政府機関との連携が重要です。脅威情報の共有や、復旧支援を受けられる場合があります。
関連する攻撃手法
海外のサプライチェーン攻撃事例には、以下のような攻撃手法が使われています。
| 攻撃手法 | 海外事例での使われ方 | 関連ページ |
|---|---|---|
| 標的型攻撃（APT） | SolarWinds、NotPetyaなど国家支援グループによる攻撃 | 標的型攻撃 |
| ランサムウェア | Kaseyaでの大規模配布 | ランサムウェア |
| ゼロデイ脆弱性 | Kaseyaでの未公開脆弱性悪用 | ゼロデイ攻撃 |
| マルウェア | SUNBURST、NotPetyaなどの展開 | マルウェア感染 |
| 不正アクセス | ビルド環境、開発者端末への侵入 | 不正アクセス |
| バックドア | SolarWindsでの長期的なアクセス確保 | トロイの木馬 |
| 横展開 | 初期侵入後のネットワーク内移動 | 権限昇格・横展開 |
よくある質問
- Q: SolarWinds事件の犯人は捕まったのですか？
- A: SolarWinds事件は、ロシアの国家支援グループAPT29（Cozy Bear）の犯行と広く認定されていますが、個人が逮捕・起訴された事例はありません。国家支援型攻撃の場合、攻撃者が国家の保護下にあるため、法的な処罰が難しいのが現実です。米国政府はロシアに対して経済制裁などの措置を講じました。
- Q: 日本企業も海外のサプライチェーン攻撃の影響を受けますか？
- A: はい、可能性があります。NotPetyaでは、ウクライナに子会社や取引先がある世界中の企業が影響を受けました。SolarWindsやKaseyaの製品を使用している日本企業も存在します。グローバルにビジネスを展開する企業や、海外製ソフトウェアを使用する企業は、海外の事例にも注意が必要です。グローバル企業の対策をご覧ください。
- Q: 国家支援型攻撃から企業を守れるのですか？
- A: 国家レベルの攻撃者に対して完璧な防御は困難ですが、被害を最小化することは可能です。多層防御、ネットワークセグメンテーション、検知能力の強化、インシデント対応計画の整備などが有効です。また、政府機関（NISC、JPCERT/CC等）が発信する脅威情報を活用し、最新の攻撃手口に対する備えを更新し続けることが重要です。
- Q: OSSを使うのは危険なのですか？
- A: OSSの使用自体が危険というわけではありません。ua-parser-jsやevent-streamの事例は、OSSエコシステム特有のリスクを示していますが、同時にOSSのメリット（コスト、透明性、コミュニティによる検証）も大きいです。重要なのは、使用するOSSの依存関係を把握し、脆弱性情報を監視し、迅速にアップデートできる体制を整えることです。SBOMの導入が有効です。
- Q: これらの事例から最も重要な教訓は何ですか？
- A: 最も重要な教訓は、「信頼だけに頼らない」ということです。信頼できるベンダー、正規のアップデート、デジタル署名——これらはすべて有効なセキュリティ対策ですが、それだけでは不十分です。検証、監視、多層防御を組み合わせた包括的なアプローチが必要です。また、侵入を100%防ぐことは困難という前提で、検知と対応の能力を高めることも重要です。
まとめ
海外のサプライチェーン攻撃事例から得られる主要なポイントを整理します。
- SolarWinds事件は、ソフトウェアサプライチェーンの脆弱性と国家支援型攻撃の脅威を世界に示した
- 3CX事件は、「サプライチェーン攻撃のサプライチェーン攻撃」という二重構造の危険性を示した
- Kaseya事件は、MSP経由の攻撃が多数の組織に被害を波及させることを示した
- NotPetyaは、史上最大級の被害（100億ドル以上）をもたらし、破壊型攻撃の脅威を示した
- 多くの事例で国家支援型攻撃グループの関与が指摘されており、高度な脅威への備えが必要
- SBOMの導入、ビルド環境のセキュリティ、MSP選定時の評価など、具体的な対策が求められる
- 日本企業もグローバルなサプライチェーンを通じて海外の事例の影響を受ける可能性がある
次のステップとして、以下のページをご覧ください。
事例・動向カテゴリのトップページはこちらです。
サプライチェーン攻撃の全体像については、サプライチェーン攻撃とは｜総合ガイドで詳しく解説しています。
サプライチェーン攻撃 完全ガイド ナビゲーション
総合ガイド
目的別に探す
- 基礎知識を学ぶ
- 事例・動向を知る ← 現在のカテゴリ
- 自社の対策を始める
- 取引先管理を強化する
役職・立場別に探す
業種別に探す
攻撃タイプ別に探す
人気のページ
更新履歴
- 初稿公開
