コンテンツに移動
脅威インテリジェンス

AI モデルがかつてない速さで脆弱性を発見する時代に、企業はどう備えるべきか

2026年5月28日
Francis deSouza

COO, Google Cloud and President, Security Products

Mandiant and Google Threat Intelligence Group

Mandiant Services

Stop attacks, reduce risk, and advance your security.

Contact Mandiant

はじめに

AI モデルを利用した脆弱性悪用の高度化により、その用途専用に設計されていない汎用 AI モデルであっても、脆弱性の発見に優れた性能を発揮できることが示されています。やがて、こうした機能は開発サイクルそのものに直接組み込まれ、コードの悪用はこれまで以上に困難になるでしょう。しかし、この移行期には重大なリスクが高まる局面が生じます。これは、AI による既存ソフトウェアの強化が進む一方で、脅威アクターも AI を使って、新たな脆弱性を発見し、悪用するようになるためです。

こうした状況に直面する中、防御者には 2 つの重要な課題があります。1 つは、利用中のソフトウェアをできるだけ迅速に強化すること。もう 1 つは、まだセキュリティ強化が完了していないシステムの防御に備えることです。

Wiz のブログ投稿 Claude Mythos: Preparing for a World Where AI Finds and Exploits Vulnerabilities Faster Than Ever(Claude Mythos: AI がかつてない速さで脆弱性を発見し悪用する時代に備える)でも述べられているように、今こそ、プレイブックの強化、攻撃対象領域の縮小、そしてセキュリティ プログラムへの AI の組み込みを進めるときです。本ブログ記事では、進化する攻撃ライフサイクルの概要、脅威アクターがこれらの機能をどのように攻撃へ転用するか、そして企業の防御戦略をモダナイズするためのロードマップをご紹介します。

攻撃者のライフサイクルにおける脆弱性悪用

これまで、新たな脆弱性の発見と、それに続くゼロデイ攻撃手法の開発には、相当な時間、高度な専門知識、そして十分なリソースが必要でした。現在では、高性能な AI モデルが、脆弱性を特定するだけでなく、実際に動作するエクスプロイトの生成を可能にしており、脅威アクターにとっての参入障壁を引き下げています。これらの機能がさらに高度化すれば、スキルレベルを問わず、脅威アクターによるエクスプロイトの開発が可能となり、攻撃までの時間は大幅に短縮されていくでしょう。GTIG はすでに、脅威アクターがこの目的で LLM を利用していることに加え、アンダーグラウンド フォーラムで宣伝されている AI ツールやサービスにおいて、こうした機能がセールス ポイントとして打ち出されていることも確認しています。

ゼロデイ攻撃を巡る経済構造が大きく変化することで、大規模な悪用キャンペーンや、ランサムウェア攻撃、恐喝活動が可能になるほか、これまでこうした能力を秘匿し、限定的にしか使用してこなかったアクターの活動も増加するとみられます。

高度な能力を持つ攻撃者の間では、脆弱性悪用の動きが加速する傾向が、すでに確認されています。Google の脆弱性の状況: 2025 年のゼロデイを振り返るレポートでは、中華人民共和国(PRC)と関連のあるエスピオナージ グループが、エクスプロイトを短期間で開発し、通常は互いに独立している脅威グループ間で共有するとともに拡散する能力を高めていることを指摘しました。これにより、脆弱性の公開から大規模な悪用が広がるまでの従来の時間差は、大幅に短縮されています。この傾向は、今後も続くとみられます。

こうした状況の変化は、今後 1 年間で、ほぼ確実に大きな変化をもたらすでしょう。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vulns-ai-fig1.max-1600x1600.jpg

マシンスピードの脅威に対応する防御体制の強化

Google は、AI モデルが脆弱性を発見できるようになることを以前から想定してきました。だからこそ長年にわたり、Big SleepCodeMenderOSS-Fuzz といった AI ツールを活用し、脆弱性を先回りして発見し、修正してきました

今や、脅威アクターは AI を活用して攻撃能力を大幅に高めています。企業側の防御者が、人間の対応スピードを前提としたパッチ適用体制だけで追いつくことはできません。組織が AI によって加速する脆弱性の急増に直面すれば、従来のセキュリティ ツールや手動トリアージでは対応が間に合わなくなります。

従来のプロセスのまま、この指数関数的に増加する業務負荷に対応しようとすれば、セキュリティ チームや開発チームは深刻な過負荷と疲弊に直面します。もはや問われているのは、先回りしたスキャンの実施や、従来型のパッチ適用 SLA の遵守だけではありません。組織が、担当者に必要な自動化を提供し、煩雑な手作業(トイル)を削減できているかどうかです。こうした現実に備えるために、組織は防御体制に AI を組み込み、セキュリティ担当者の役割を、手作業中心の調査担当から戦略的な調整役へと移行させる必要があります。

AI を統合した最新の防御ロードマップ

従来の脆弱性対応ロードマップをモダナイズするには、組織は自動化を取り入れ、レジリエンスを優先する必要があります。

組織が防御すべき脅威は、もはや人間のスピードだけで行われる脆弱性悪用ではありません。AI を利用する攻撃者は、従来の脆弱性管理プログラムが対応を想定していたスピードを上回る速さで、脆弱性を発見し、組み合わせ、攻撃へと転用できます。したがって、これからのロードマップでは、自動化、レジリエンス、継続的検証を重視すべきです。

このロードマップは 2 つのパートで構成されています。1 つ目では、AI が可能にするスピードでの防御を実現するために、セキュリティ プログラムを高度化する準備が整っている組織に向けて、高度なモダナイズを進めるための優先施策を示します。2 つ目では、脆弱性管理の基礎能力を構築中の組織向けに、基本的なガイダンスを提供します。

高度なモダナイズを進めるための優先施策

https://storage.googleapis.com/gweb-cloudblog-publish/images/vulns-ai-fig2.max-1600x1600.jpg

コードを保護する 

これまで組織は、ノートパソコン、サーバー、ネットワーク インフラストラクチャといった物理アセットの保護とパッチ適用に重点を置いてきました。現在の脅威環境では、同様の管理水準を、ソースコード、コード ライブラリ、さらにビルドやデプロイに用いられるシステムにまで適用しなければなりません。

コード リポジトリ プラットフォームは、厳重に保護し、信頼できる内部ネットワーク、管理対象 ID、または厳格に管理されたその他のアクセス経路からのみ利用可能とすべきです。さらに、組織は、攻撃者に悪用される可能性のあるコードベース内のシークレットを先回りして検出し、機密性の高い認証情報を平文で保存する慣行をなくしていく必要があります。

同様に、組織はサプライ チェーン由来の脆弱なコードについても引き続き責任を負っており、コード ライブラリの侵害による攻撃に備え、先回りして防御策を講じることが求められます。その結果、バージョンやリポジトリを速やかに更新することと、検証済みで信頼できるバージョンを維持することとの間で、トレードオフが生じます。

そのため、セキュリティ対策の範囲は、ビルドランナー、CI / CD パイプライン、その他の自動化された実行基盤にまで広げる必要があります。これらはいずれも、脅威アクターにとって格好の標的になりつつあります。こうした中で、AI を活用したスキャンツールは、チームが重大な脆弱性をより迅速に検出できるようにするとともに、単独では軽微に見えても、組み合わせることで悪用につながる可能性のある複数の弱点を明らかにします。

また、組織は、Wiz SITF などのフレームワークを活用することで、SDLC 全体の脅威モデルをマッピングし、AI が個別には軽微な弱点を組み合わせ、重大な侵害を引き起こす「攻撃チェーン」を特定する必要があります。さらに、1 回限りの静的スキャンや動的スキャンでは、もはや十分とはいえません。組織は、新たに登場している商用およびオープンソースのエージェント型ソリューションをデプロイし、コードをレビューするとともに、コードの欠陥や弱点が悪用される前に対処する必要があります。

セキュリティ運用の自動化へ移行する

従来型のダッシュボードや静的な検知ルールでは、自動化された大量の攻撃への対応は困難です。そのため、セキュリティ運用は、エージェント型 SOC (Agentic SOC)への道筋を明確にしながら、より動的な運用体制へ移行する必要があります。

従来型の運用モデルの多くは事後対応型であり、手作業中心のワークフローに制約されています。Google Cloud の Triage and Investigation Agent や、Google Security Operations の Gemini などの専用 AI エージェントをデプロイすることで、チームはアラートのトリアージを自動化し、手動でリバース エンジニアリングを行うことなく不審なコードを分析し、複数のツールにまたがるシグナルを相関分析するとともに、リアルタイムで対応プレイブックを生成できます。これにより、アナリストは反復的な調査に費やす時間を減らし、より重要な判断に集中できます。結果として、SOC は AI を利用した攻撃に対して、AI 並みのスピードで対応可能になります。

攻撃対象領域を縮小する

組織はゼロトラスト アプローチでネットワークを設計し、まずはインターネット公開システム、重要インフラストラクチャ、コントロール プレーン、信頼されたサービス基盤におけるアタックサーフェスの低減に注力する必要があります。

ネットワーク セグメンテーションを導入し、ID ベースのアクセス制御を実装しておくことで、ゼロデイ攻撃によってエッジデバイスが侵害された場合でも、影響範囲を抑え、封じ込めが容易になります。

継続的なアセット探索とポスチャー管理を維持する

把握されていないアセットは、組織にとって大きな盲点であるだけでなく、AI を利用する脅威アクターにとっても、より効率的に悪用される重大な弱点でもあります。静的なスプレッドシートや手作業によるアセット管理は、もはや現実的でも、拡張可能な運用手法でもありません。

セキュリティ チームには、エンドポイント、サーバー、外部公開システム、ネットワーク インフラストラクチャ、AI システム、クラウド環境、さらに Kubernetes pod のような一時的なアセットまで把握できる、継続的に自動更新されるインベントリが必要です。動的なアセット検出は、盲点やシャドー AI を減らすうえで不可欠です。既知のアセット情報を後続のセキュリティ ツールへシームレスに連携できるほど、現場での検知と対応は、より正確かつ効果的になります。

自動スキャンの対象範囲を拡大する

自動脆弱性スキャンは、エンドポイントとサーバーの双方で、Windows、macOS、Linux を含む主要なすべてのオペレーティング システムを対象とする必要があります。

盲点を減らし、脆弱性を継続的かつ包括的に可視化することが重要です。さらに、可能であれば、その情報を自動修復パイプラインへ直接つなげるべきです。

ネットワーク デバイスのパッチ適用を強化し、接続範囲を制限する

組織には、ネットワーク デバイスで未適用となっているファームウェア更新やセキュリティ アップデートを把握し、保守作業を効率的にスケジューリングするための、高度に自動化され、再現性の高いプロセスが必要です。ネットワーク インフラストラクチャは、巧妙な脅威アクターにとって長年にわたり格好の標的となってきました。AI は、こうした見過ごされがちなシステムに潜む脆弱性の発見をさらに加速させるでしょう。

また、組織は、境界制御を活用して、内部ネットワーク デバイスからの不要なアウトバウンド接続を遮断しなければなりません。これらのデバイスが外部との通信を試みた場合、それが通常運用に必要なものか、あるいはより深刻な問題の兆候かを見極めるために調査することが重要です。さらに、異常な通信を検知してアラートにつなげられるよう、通常時のアウトバウンド接続パターンを事前にベースライン化しておくべきです。

緊急修復 SLA を明確化する

AI はパッチ適用の迅速化に役立つこともありますが、緊急対応には依然として、明確な人的対応プロセスが欠かせません。

組織は、重大度、外部公開状況、アセットの重要度に基づいて修復 SLA を定め、その基準についてセキュリティ、IT、ビジネスの各関係者間で認識をそろえる必要があります。また、脆弱性が実際の攻撃で悪用されている場合、恒久的な修正の有効性が確認されるまでの間、公開アクセスの制限や影響を受けたシステムの隔離といった一時的な緩和策を適用できるよう、チームには事前承認済みで速やかに実行できるプロセスが必要です。さらに、極めて重要なビジネス プロセスにはそれぞれ、基盤となるテクノロジーが異なっていても、同じ目的を果たせるセカンダリ システムを確保しておく必要があります。これらのプロセスに代替手段やフォールバックを備えておくことで、組織は緊急修復の選択肢を広げながら、業務中断の可能性を最小限に抑えることができます。

AI エージェントの安全性を確保するとともに、SAIF を導入する

組織が AI エージェントをデプロイすると、新たな攻撃対象領域が生まれます。

そのため、Google の Secure AI Framework(SAIF)などのフレームワークを採用し、AI モデルやアプリケーションの安全な導入を進める必要があります。Google Cloud Model Armor や同様のソリューションは、プロンプト インジェクションやジェイルブレイクの試みに対して入出力を検査し、大規模言語モデル環境の保護レイヤーとして機能します。また、Google Cloud Sensitive Data Protection は、センシティブ データの漏洩防止に役立ちます。さらに、MCP など AI システムが利用できる接続経路を、きめ細かな IAM ロールで厳格に制御することは、安全でないプラグインの利用に伴う脅威を防ぐうえで不可欠です。

防御側の AI システムが新たな侵害経路にならないよう、それに応じた保護対策を講じる必要があります。

脆弱性管理の基礎的な優先事項

すべての組織が同じベースラインから出発するわけではありません。上記の優先事項は、ツール、責任体制、運用能力が整った、比較的成熟したセキュリティ プログラムを前提としています。脆弱性の管理能力が限定的、または一貫性を欠く組織では、高度な AI 活用型の運用モデルを目指す前に、まずは信頼できる基盤を構築することが重要です。

脆弱性管理の現状

脆弱性管理プログラムは、組織全体のセキュリティ体制の成熟度によって大きく異なります。成熟した環境では、脆弱性管理は高度に自動化されており、対象となる脆弱性が特定されると、適切な IT やインフラストラクチャ、アプリケーションの担当者へ割り当てられ、修復完了後に自動的な検証が行われます。

成熟度がさほど高くない環境では、むしろ逆の状況になりがちです。脆弱性管理は一貫性を欠き、対象範囲も限定され、注目度の高いゼロデイ脆弱性への対応に偏る場合があります。追跡管理はいまだにローカルのスプレッドシートに依存していることもあり、システムが見落とされたり、Active Directory ドメイン コントローラのような重要なサービス基盤資産でさえ、パッチ未適用のまま残ることがあります。

こうした組織では、脆弱性管理プログラムを直ちにモダナイズし、高度化する必要があります。ほとんどの組織は、すでに自社の技術スタック全体に存在するすべての脆弱性を修復しきれていません。AI を利用した脅威の台頭により、この状況がさらに深刻化する中、自動化され、定量的評価や追跡が可能で、有効性も検証できるプログラムの構築が一層急務となっています。

もっとも、こうした成果の実現は容易ではありません。セキュリティ プログラムの 3 つの基本要素である人、プロセス、技術の連携が必要になります。優先順位を踏まえた段階的なアプローチは次のとおりです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/vulns-ai-fig3.max-1400x1400.jpg

基盤ステップ 1 - 現状を把握する

まずは、すでに導入しているツールやプロセス、対象範囲をもとに取り組みを始めます。現在スコープ内にある対象をすべてスキャンし、Critical と High の脆弱性を特定したうえで、合意済みの緊急度やサービスレベルに沿って修復を進めます。同時に、実際に悪用が確認されている脆弱性を継続的に追跡し、必要に応じて緊急パッチを適用できるような運用プロセスも整備します。このフェーズでは、各システムの責任者がメンテナンスの時間枠を定め、修復 SLA を満たすための運用支援体制を確保していることも確認します。

基盤ステップ 2 - システム スキャンの対象範囲を拡大する

Windows、macOS、Linux をはじめとする、現在利用している主要なオペレーティング システムについて、エンドポイントとサーバーの両方で脆弱性スキャンの対象範囲を広げます。さらに、ネットワーク デバイスを含む、ネットワークに接続されたその他のシステムにも対象を拡大します。目的は、盲点を減らし、特定のセグメントだけでなく、環境全体で脆弱性を可視化できる状態にすることです。

基盤ステップ 3 - アセット インベントリと責任体制を整える

エンドポイント、サーバー、外部公開システム、ネットワーク インフラストラクチャ、必要に応じて医療機器などの専用機器を含む主要なアセット区分について、わかりやすく正確なインベントリを継続的に管理します。すべてのアセットには、修復対応の調整、例外対応、ライフサイクル全体の管理責任を担う責任者を明確に定める必要があります。

基盤ステップ 4 —標準化されたプログラム報告体制を確立する

関係者がプログラムの健全性とリスクを明確に把握できるよう、一貫した報告サイクルを整えます。レポートには、アセット区分ごとのスキャン対象範囲、主要な Critical および High の脆弱性、外部公開状況、パッチ適用状況、SLA の達成状況、記録済みの例外措置やリスク受容を含める必要があります。目標は、単なる可視化にとどまるダッシュボードではなく、意思決定につながるレポートを作成することです。

基盤ステップ 5 - インターネット公開システムと高リスク脆弱性への対応を優先する

攻撃対象領域を把握し、インターネット公開システム、重要インフラ、さらに悪用される可能性が高い、またはビジネスへの影響が大きいアセットの脆弱性への対応を優先します。修復対応は、定められた期限に沿って進捗を追跡し、期限内の対応が難しくなった場合には、明確なエスカレーション手順を設ける必要があります。可能な限り、インターネット公開システムは自動パッチ適用を前提に設計すべきです。

基盤ステップ 6 - 特別な対応が必要な機器向けのプロセスを整備する

医療機器、産業用制御システム、その他の運用技術機器など、追加の調整が必要なデバイス区分については、脆弱性の特定、ベンダーやサポートチームとの連携、パッチ適用が困難な場合の代替対策を含む、円滑な対応プロセスを整備します。これらのアセットでは、標準的な IT システムとは異なる対応モデルが必要になることも少なくありません。

基盤ステップ 7 - 修復 SLA と例外管理を正式化する

重大度、外部公開状況、アセットの重要度に基づいて修復 SLA を定め、セキュリティ、IT、ビジネス部門の関係者間で認識をそろえます。同様に重要なのは、定められた期限内に修復を完了できないケースに備え、例外管理の正式なプロセスを整えておくことです。例外は記録に残し、リスク評価を行い、適切な関係者の承認を得たうえで、定期的に見直す必要があります。

Google ができること

今日のサイバーセキュリティ環境では、人間の攻撃者だけでなく、AI ツールによって高度化された攻撃手法にも対処しなければなりません。こうしたマシンスピードで展開される脅威に対抗するため、Google は AI を統合した包括的な防御エコシステムを提供しています。

  • Google Threat Intelligence: AI により大量に生成される脆弱性悪用攻撃に対抗するため、Google Threat Intelligence は「侵害を前提(Assume Breach)」とする先回り型の防御姿勢を実現します。Mandiant が体系化した最前線の攻撃者行動の知見と、Google の持つグローバルな脅威動向に対する可視性を組み合わせることで、セキュリティ チームは静的な侵害指標にとどまらず、新たな攻撃に特有の、捉えづらく従来のパターンに当てはまらない挙動まで見つけ出せるようになります。さらに、セキュリティ ノイズと実際の脅威がともに増加する中、このプラットフォームは、現在活動中のアクティブな脅威に基づいて、セキュリティ リソースの優先順位をより的確に行えるようにします。こうして増え続けるノイズに惑わされず、真に重要な対象に集中することで、セキュリティ チームは時間を節約でき、その結果、攻撃者が目的を達成するはるか前の段階で、その攻撃ライフサイクルを断ち切れるようになります。

  • Mandiant Security Consulting Services: Mandiant AI Security Consulting Solutions は、組織がこのアーキテクチャを設計し、実運用へ移行できるよう支援します。これには、コードレビューを通じた脆弱性の特定と修正の迅速化、安全なソフトウェア開発ライフサイクル(SSDLC)の成熟度向上、さらに、増加が見込まれる脆弱性にも効率的かつレジリエンスを高めながら対応する、脆弱性管理プログラム全体のモダナイズが含まれています。

  • エージェント型 SecOps: Google SecOps は、エージェント型セキュリティ オペレーション センター(Agentic SOC)の基盤を提供します。これにより、チームは動的 AI と確定的な自動化を組み合わせ、エージェントを活用してワークフローを高度化できます。たとえば、Triage and Investigation Agent をワークフローに直接組み込むことで、対応時間を短縮できます。このエージェントは、アラートを自律的に調査し、エビデンスを収集したうえで、明確な説明とともに判定結果を提示します。その結果、意思決定と修復対応を自動化でき、アナリストは誤検知への対応ではなく、優先度の高い脅威への対処に集中できるようになります。さらに、運用上の摩擦が低減されることで、対応オーケストレーションもより効率的になります。加えて、リモート Model Context Protocol(MCP)サーバーと連携できるため、利用者はエンタープライズ対応のセキュリティ エージェントの構築が可能です。

  • Mandiant Threat Defense(MTD): 社内 SOC チームを補完するため、Mandiant Threat Defense は、最前線の脅威インテリジェンスと AI を活用したテレメトリーを用いて、高度かつマシンスピードで展開される脅威を先回りして特定し、阻止します。

  • Wiz: 組織は継続的なアセット把握と動的なポスチャー管理により、複雑なマルチクラウド環境全体の攻撃対象領域を迅速に特定し、縮小を進めます。Wiz は、環境コンテキストを活用する AI エージェントによって、セキュリティ対応を組織全体に広げ、修復対応の優先順位付けを行い、攻撃対象領域を先回りして縮小します。また、最新の AI モデルを継続的に取り込み、脆弱性の検出と対応を効率化しています。さらに、Model Context Protocol(MCP)サーバーにより、セキュリティ チームは、エージェント型ワークフローの中で、Wiz が持つ豊富なコンテキスト情報とリスク分析を活用できます。Wiz の基盤戦略は、クラウド、コード、ランタイムを横断的につなぎ、次の 3 つの主要なエージェントを中核に据えています。

    • シフトライト(レッド エージェント): クラウド、ワークロード、コード分析などのコンテキスト情報を活用して、AI による攻撃者視点で攻撃対象領域全体をスキャンし、直ちに悪用されるおそれのあるリスクを発見します。

    • シフトレフト(グリーン エージェント): 利用者がクラウドからコードまでの根本原因を特定できるよう支援するとともに、あらかじめ用意された Wiz スキルを用いて修正を自動デプロイします。さらに、今後提供予定の CodeMender との統合により、コードベースの自己修復も可能になります。

    • 検出と対応(ブルー エージェント): AI を活用した攻撃の調査を AI のスピードで自動化し、SOC チームが不審な挙動を迅速にトリアージするとともに、ランタイム保護ツールを用いて脆弱性悪用の検知を可能にします。

  • Google Cloud Model Armor: 組織が導入する AI エージェントを保護するために、Google Cloud Model Armor は、LLM に特化したファイアウォールとして機能し、入出力を先回りして検査することで、プロンプト インジェクションやセンシティブ データの漏えいを防ぎます。

見通しと影響

サイバーセキュリティ コミュニティには、理性的な声となる役割があります。最善の対応は、パニックに陥ることではなく、先を見据えて計画的に準備を進めることです。現在、一般に知られている最も高性能なフロンティア モデルへのアクセスは、信頼できる利用者や組織に限定されています。しかし、こうしたテクノロジーが今後より幅広い層へ広がっていくことは避けられません。防御者にとって、このことは、脆弱性管理に求められる対応の急増を意味します。脆弱性の公開から実際の環境で悪用されるまでの従来の猶予期間は、すでにほぼなくなっています。現在、最大の懸念は、組織が同時に防御しなければならない脆弱性悪用攻撃が膨大な数にのぼることです。さらに、深刻度に対する従来の考え方も変わりつつあります。AI エージェントが複数の軽微な脆弱性を連鎖的に組み合わせて利用できる環境では、リモートコード実行(RCE)につながる欠陥と、一見無害なローカル限定の悪用手法との実質的な影響差は、急速に薄れつつあります。

上記の基盤ステップをさらに発展させるために、組織は Mandiant と連携し、AI を活用したサイバー防御戦略の計画策定から優先順位付け、実行までを進めることができます。AI は、セキュリティ チームによる環境把握、大規模修復の自動化、人材の能力強化を支える強力な新しい手段です。AI を統合した防御を今から導入することで、組織は将来の攻撃者が持つスピード、規模、巧妙さに、より効果的に備えられるようになります。

謝辞

この投稿は、Mandiant と GTIG の多くの専門家の協力なくしては実現できませんでした。とりわけ、本ブログ記事の作成にご協力いただいた、Omar ElAhdan 氏、Chris Linklater 氏、Austin Larsen 氏、Jared Semrau 氏、Dan Nutting 氏、John Hultquist 氏、Kimberly Goody 氏に、深く感謝いたします。

- Google Cloud COO 兼セキュリティ プロダクト担当プレジデント Francis deSouza

- Mandiant および Google Threat Intelligence Group

投稿先