何が起きたのか
2026年5月初旬、サイバーセキュリティ企業Trellixが「ソースコードリポジトリへの不正アクセスを確認した」と発表した。ランサムウェアグループRansomHouseが5月7日に犯行声明を出し、内部サービスや管理ダッシュボードへのアクセスを示すスクリーンショットをリークサイトに公開した。Trellixは「ソースコードのリリース・配布プロセスへの影響や、ソースコードが悪用された証拠は現時点で見つかっていない」と説明しているが、セキュリティベンダー自身のソースコードが侵害された事実の重みは否定できない。
Trellixとはどのような企業か
Trellixは2022年1月にMcAfee EnterpriseとFireEyeの合併により設立された国際的なサイバーセキュリティ企業だ。エンドポイントセキュリティ・XDR（拡張検知応答）・ネットワーク防御・クラウドセキュリティを主力製品として提供し、世界185カ国・53,000以上の顧客を持ち、2億超のエンドポイントを保護している。顧客にはFortune 100企業や政府機関が含まれる。
FireEye由来の脅威インテリジェンスとMcAfee由来のエンドポイント保護が組み合わさった同社のソースコードは、世界のサイバーセキュリティインフラの一端を担う重要資産だ。
RansomHouseとはどのようなグループか
RansomHouseはデータ窃取と恐喝に特化したグループで、2022年から活動が確認されている。通常のランサムウェアグループとは異なり、ファイルの暗号化よりも機密データの窃取・公開脅迫を主な手口とする。過去にはAMD・Loews Hotels・Keralty（コロンビアの医療システム）などを標的にした実績がある。
Trellixへの侵入は4月17日に発生したと主張しており、「データを暗号化した」と述べているが、具体的な窃取データ量は公表されていない。
技術的な解説
「セキュリティベンダーのソースコード流出」が特別に危険な理由
一般企業のソースコード流出と、セキュリティベンダーのソースコード流出には質的な違いがある。
| リスク | 内容 |
|---|---|
| 検知回避ロジックの把握 | Trellixの製品がどのようなシグネチャ・ヒューリスティック・振る舞い検知ルールを使っているかが攻撃者に判明する。Trellix製品を導入している組織を狙う際に、検知されにくいマルウェアを作成できる |
| 未知の脆弱性の発見 | ソースコードを精査することで、公開されていない脆弱性（ゼロデイ）を発見できる可能性がある。セキュリティ製品の脆弱性は、製品が高い権限で動作するため影響が大きい |
| サプライチェーン攻撃の足がかり | 将来的な製品アップデートへのコード改ざんや、ビルドパイプラインへの侵入に向けた情報収集として活用される可能性がある |
| 顧客情報の間接的なリスク | 製品の認証・ライセンス管理・クラウド接続に関連するコードが含まれている場合、顧客環境への侵害の糸口になりうる |
「ソースコードが悪用された証拠はない」の意味
Trellixは「ソースコードが悪用された証拠はない」と述べているが、この表現の意味を正確に理解する必要がある。これは「ソースコードを使った攻撃が発生していない」ことを意味するが、以下については保証していない。
- 攻撃者がソースコードを読んで分析しているかどうか
- ソースコードから発見した脆弱性が将来悪用されないかどうか
- 攻撃者がソースコードを第三者に売却しているかどうか
ソースコードの「閲覧・分析」は痕跡が残りにくく、被害者側から検知することが困難だ。「証拠がない」は「被害がない」と同義ではない点を理解しておく必要がある。
セキュリティベンダー侵害の歴史的文脈
セキュリティ企業が攻撃者に侵害された事例は過去にも複数存在する。
- RSA Security（2011年）: SecurIDトークンの製造情報が流出。その後、防衛請負業者Lockheed Martinへの攻撃に悪用されたとされる
- FireEye（2020年）: RedTeamツールが流出。これはSolarWindsサプライチェーン攻撃（SUNBURST）との関連が後に判明し、ロシアSVRの関与が指摘された
- Okta（2022年・2023年）: IDaaSプロバイダーのソースコードおよびサポートシステムへの不正アクセスが複数回発生
- Microsoft（2024年）: Midnight Blizzard（ロシアSVR）がMicrosoft幹部のメールを侵害し、ソースコードも一部アクセスされた
これらの事例が示すように、セキュリティベンダーは「最も攻撃の価値が高い標的」の一つだ。
RansomHouseの恐喝モデルと予防的対応
RansomHouseはデータを公開する前に身代金交渉を行う。Trellixが交渉に応じなかった場合、窃取したソースコードやその他データが公開・売却される可能性がある。一方、身代金を支払っても「データが完全に消去される保証はない」というのがセキュリティ業界の共通見解だ。
日本企業への影響
Trellix製品のユーザー組織
日本にもTrellix（旧McAfee Enterprise）製品を使っている企業・官公庁・金融機関は多い。特にエンドポイントセキュリティ製品を長期運用している組織では旧McAfee製品からの継続利用も多い。以下の点で自組織への影響を評価することが必要だ。
- Trellix製品のアップデートを通常どおり適用して問題ないか（現時点でTrellixは「配布プロセスに影響なし」と説明しているが、状況の変化に注意する）
- Trellix製品を中心としたセキュリティ体制に多層防御が機能しているか（単一ベンダー依存の排除）
- ベンダーのセキュリティインシデント通知を受け取れる連絡体制が整っているか
セキュリティベンダーのインシデントをどう評価するか
「セキュリティ会社がハッキングされた」というニュースを聞いたとき、「だからセキュリティ製品は信用できない」という反応は適切ではない。同時に「うちのベンダーは大丈夫」と楽観視するのも危険だ。適切な評価姿勢は以下だ。
- ベンダーの公式発表と継続的な情報開示を継続的に追う
- ベンダーが「配布プロセスへの影響なし」と説明しているうちは通常運用を継続し、アップデート署名の検証に問題がないか確認する
- 製品アップデートのハッシュ検証と署名確認の手順を整備しておく
- 単一ベンダーへの依存を減らし、Defense in Depthを維持する
今すぐ確認すべきポイント
1. Trellix製品を使っているかどうかを確認する
Trellix・旧McAfee Enterprise・旧FireEye製品を使用している場合、Trellix公式サイトおよびセキュリティアドバイザリの更新を監視する。現時点では「製品の配布プロセスへの影響なし」とされているが、新情報が出た場合は即時対応する。
2. セキュリティ製品のアップデートの完全性検証を実施する
セキュリティ製品のアップデートパッケージが正規の署名で配布されているかを確認する仕組みを整備する。予期しない配布元・変則的な更新スケジュールには警戒する。
3. 多層防御の状態を評価する
エンドポイントセキュリティを単一ベンダーに依存している場合、そのベンダーが侵害された際のリスクを評価する。EDR・ネットワーク監視・SIEMの組み合わせで異なるベンダーを使い、単一障害点を排除することが重要だ。
4. セキュリティベンダーへの問い合わせを検討する
自社がTrellix製品を利用している場合、担当営業・カスタマーサクセスを通じてインシデントの詳細・自社環境への影響・追加的な緩和措置について照会する。
5. ベンダーリスク管理プロセスを見直す
セキュリティベンダーを含む重要サプライヤーのインシデント対応能力・情報開示方針・セキュリティ認証（SOC 2・ISO 27001等）を定期的にレビューする仕組みを設ける。「セキュリティ会社だから安全」という前提に依存したベンダー評価は見直す必要がある。
参考情報
- BleepingComputer: Trellix source code breach claimed by RansomHouse hackers
- BleepingComputer: Trellix discloses data breach after source code repository hack
- The Hacker News: Trellix Confirms Source Code Breach With Unauthorized Repository Access
- SecurityWeek: Trellix Source Code Repository Breached
- Dark Reading: Trellix Source Code Breach Highlights Supply Chain Threats