結論：Glassworm 単体の対策ではなく「サプライヤー経由侵入」の備えとして読む
Glassworm は 2026 年に脅威インテリジェンスコミュニティ・各セキュリティベンダーで言及されている、サプライチェーン経路を悪用した APT 型攻撃キャンペーンとして報告されている。Google Search Console のデータからも検索ニーズが立ち上がっており、調達部門・情シスから「うちは大丈夫か」という問い合わせが増えるタイミングだ。
ただし、Glassworm は「単一の脆弱性」ではなく 手口の総称・キャンペーン名 として扱われる傾向が強く、特定の CVE 1本にパッチを当てれば終わる種類のものではない。本稿では、中堅企業が サプライチェーン経由の侵入リスク にどう備えるかという観点で整理する。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
Glassworm を読み解く前提：APT 型サプライチェーン攻撃の構造
APT（Advanced Persistent Threat）型のサプライチェーン攻撃は、概ね次の構造を持つ。
横にスクロールして確認できます
| フェーズ | 内容 |
|---|---|
| 標的選定 | 最終標的（大企業・政府機関）と直接取引のある中堅サプライヤーを偵察 |
| 初期侵入 | サプライヤーの脆弱な OSS / 開発ツール / VPN / メール経由で侵入 |
| 持続的アクセス | 多段ペイロード・正規ツール悪用（LotL）で長期潜伏 |
| 横展開 | サプライヤー経由で最終標的のネットワークに到達 |
| 目的達成 | 知財窃取・身代金要求・作戦行動の妨害など |
中堅企業の経営層が押さえるべきは「自社が最終標的でなくとも、取引先大手の踏み台として狙われる」という事実だ。Glassworm に限らず、近年の APT キャンペーンの大半はこの中堅サプライヤー経由侵入を中心戦術としている。
公開情報からみえる Glassworm の特徴
本稿執筆時点で公開されている範囲では、以下のような特徴が複数のリサーチャー・ベンダーから言及されている。詳細な IoC（Indicator of Compromise）は各ベンダーの脅威インテリジェンスレポートを直接参照してほしい。
- 開発エコシステム（パッケージリポジトリ、ブラウザ拡張、IDE 拡張など）を経路として狙う傾向
- 正規ツール・正規プロトコルを悪用する Living off the Land 戦術の比率が高い
- 標的国・業種に偏りがあり、特定地域・特定業界を集中して狙うキャンペーン特性
- 検知回避のため多段スクリプト・暗号化された C2 通信を多用
これらの特徴は Glassworm に固有ではなく、現代の APT 全般に共通する。「Glassworm 対策」ではなく「APT 一般への耐性向上」として施策を組む のが実務的な姿勢だ。
「自社のシステムが影響を受けるか分からない」
脆弱性スキャンとパッチ適用支援、サプライチェーン監査を提供します。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
中堅企業が実施すべき4段の備え
段1：サプライヤー / 取引先の棚卸し
- 自社が「誰に、何を、どの経路で」納めているかを部署横断で一覧化
- 直接取引先（Tier 1）に加え、その先（Tier 2）まで業務影響を確認
- データ連携・API 連携・VPN 接続の権限保有者リストを整備
段2：契約上のセキュリティ条項の整備
- 主要取引先と自社の間に インシデント発生時の通知義務・通知期限（例：72時間以内）の条項
- サプライヤー側のセキュリティ対策水準（ISO 27001 / SOC 2 等）の確認頻度
- 委託・再委託に関する事前承認のルール
段3：技術的な検知体制
# 例：サプライヤー由来の通信を切り出すための分類
# 自社ネットワークの egress ログから、業務上想定される接続先と
# それ以外を区別できるドメインリストを作っておくと検知が早い
- EDR の導入と「正規ツール悪用」を捕まえるためのチューニング
- DNS / Proxy ログを SIEM に集約し、未知の C2 候補ドメインへのアクセスを検知
- メールゲートウェイで開発ツール系ドメインへのフィッシングを検知（GitHub / npm / VS Code Marketplace 等を装うもの）
段4：開発・運用環境のサプライチェーン強化
- 開発端末でインストールする IDE 拡張・パッケージのホワイトリスト運用
- ビルドパイプライン側でパッケージの署名検証 / SBOM 生成
- 本番系と開発系のクレデンシャル分離
影響範囲をどう自己評価するか
「うちは Glassworm の被害を受けているか」を自己評価する場合、以下の観点が役立つ。
横にスクロールして確認できます
| 観点 | 確認方法 |
|---|---|
| 自社が APT 標的業界か | 防衛・先端製造・インフラ・官公庁との取引比率 |
| 開発エコシステムの清潔度 | npm / PyPI / VS Code Marketplace 利用ポリシーの有無 |
| ログの保管期間 | 90日以上ない場合、潜伏期に気付けない可能性大 |
| EDR / SIEM の有無 | 中堅企業の半数強は未導入、未導入なら検知不能 |
| 取引先の通知体制 | 過去に取引先からの通知を受けた経験があるか |
評価の結果「ログが30日しかない」「EDR がない」「サプライヤーの一覧がない」のいずれかに該当するなら、Glassworm 対策以前にサプライチェーン全般への耐性が低い 状態だ。優先順位は IoC 探索より体制整備の方が高い。
確認コマンド・ログクエリの例
# 例：proxy ログから直近30日の未分類ドメインを抽出
# （業務上の正規ドメインリストとの差分を取る用）
awk '{print $7}' access.log \
| sort -u \
| grep -vFf known_legit_domains.txt
# 例：エンドポイント側で起動された PowerShell の引数を検査
# Living off the Land 攻撃の典型的痕跡を拾うため
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" `
| Where-Object { $_.Message -match "EncodedCommand|DownloadString|IEX" }
具体的な IoC（ハッシュ値・ドメイン・IP）はベンダー脅威インテリジェンスから取得して使うのが原則だ。個別 IoC のリストを記事側で固定せず、購読中の脅威情報フィードを優先してほしい。
まとめ
横にスクロールして確認できます
| 項目 | ポイント |
|---|---|
| 脅威 | Glassworm（APT 型サプライチェーン攻撃キャンペーンとして言及） |
| 性質 | 単一 CVE ではなく手口の総称、対策は APT 一般耐性で考える |
| 中堅企業の論点 | 大手の踏み台として狙われる、検知体制の不足 |
| 4段の備え | サプライヤー棚卸し / 契約条項 / 検知体制 / 開発環境強化 |
| 一次情報 | 各セキュリティベンダーの脅威インテリジェンスレポート、JPCERT/CC |
「自社が最終標的でなくとも、取引先の踏み台として狙われる」——この認識をもとに、サプライヤー監査と検知体制をワンセットで整備していくことが、Glassworm を含む APT への現実的な備えとなる。
GXOの見解
セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。
GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。
GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。
実務判断のポイント
この記事は、経営者、CIO、情シス、セキュリティ担当、開発責任者向けです。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。Glassworm 脅威インテリジェンス速報｜APT型サプライチェーン攻撃と中堅企業のサプライヤー監査に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。
GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。
GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、診断、監査、保守契約、月次レポート、緊急対応支援へ接続。さらに、チェックリスト型診断を入口に、継続監視・改善支援へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問（FAQ）
Q1. Glassworm の IoC リストはどこで入手できますか？
各セキュリティベンダー（Mandiant / CrowdStrike / Trend Micro / Recorded Future 等）の脅威インテリジェンスレポート、および JPCERT/CC の公開情報を参照してください。記事側で固定 IoC を掲載すると陳腐化が早いため、購読契約のあるベンダーフィードを正とする運用を推奨します。
Q2. 自社で APT 対策を内製化するのは現実的ですか？
中堅企業の規模では、SOC 24/365 の内製化はコスト面で合いません。MDR（Managed Detection and Response）サービスの利用、または取引先大手のセキュリティ要件に合わせた段階的整備が現実解です。
Q3. 取引先からセキュリティアンケートを求められました。何を最低限整備すべきですか？
ISO 27001 取得まで行かずとも、情報セキュリティポリシー文書、インシデント対応手順、アクセス権限の棚卸し記録、教育実施記録、の4点を最低ラインとして揃えてください。これだけでも Tier 1 サプライヤーとしての信用は大きく変わります。
Q4. 開発端末の IDE 拡張をホワイトリスト化すると開発生産性が落ちませんか？
短期的には申請プロセスのオーバーヘッドが発生します。ただし VS Code Marketplace 経由のサプライチェーン攻撃事例は実際に複数報告されており、侵害発生時の被害額と比較すれば極めて低コストです。最初は「重要 repo を扱う端末のみ」から段階導入するのが現実的です。
参考情報
- 各セキュリティベンダーの脅威インテリジェンスレポート
- JPCERT/CC「サプライチェーン攻撃に関する注意喚起」関連ページ
- IPA「中小企業の情報セキュリティ対策ガイドライン」
- MITRE ATT&CK Framework（Supply Chain Compromise: T1195）
関連記事
取引先から「貴社のセキュリティは大丈夫か」と問われていませんか？
サプライヤー棚卸し・契約条項見直し・EDR 導入・ログ集約まで、中堅企業の実情に合わせた段階的なサプライチェーンセキュリティ整備を支援します。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
