生成AI（Mythos）時代のセキュリティ対策―脆弱性対応は「1時間以内」、AI脆弱性診断は必須に

Mythos世代と呼ばれる今のAIは人間の力を凌駕してきており、私たちセキュリティ対策をする側は、「何がどう変わったのか」を把握したうえで、変わったものに対して対策することが重要です。

簡単に自己紹介をしますと、私は2000年にセキュリティ会社を設立し、15年後に会社を売却して時間ができたことから日本ハッカー協会を設立しました。ハッカーの方々が社会で活躍できるよう仕事を支援し、悪いことをしてしまった際には弁護士を付けて将来が閉ざされないようにする活動をしています。政府機関からベンチャー、大企業までコンサルティングも行い、変化の激しいこの分野を追いかけるために自分の手を動かすことを大切にしています。セキュリティ技術を競う大会では、経済産業省主催の「CTFチャレンジJAPAN」（2013年）をはじめ5回ほど優勝し、世界最大のハッカーイベント「DEF CON」のRecon Village（偵察系）のCTFでも2年連続優勝しました。専門は仮想通貨やP2P、ドローンのハッキングで、OSINT（公開情報を用いた調査）も得意です。

ニュースではMythosばかりが取り上げられますが、Mythosのガードレール（制限）を強化したFableというモデルも出ています。実際には今年3月ごろから変わり始めていたのですが、Mythosのマーケティングが成功したことで、いろいろなことが一気に変わりました。

まず攻撃者の量的能力です。ペネトレーションテスト（擬似的な侵入テスト）には相当な時間がかかりますが、人間は起きている時間の5分の1程度しか活動できないのに対し、24時間365日動くAIは5倍の活動が可能です。次に中級攻撃者の攻撃能力です。AIが公開情報をわかりやすく解説してくれるため、中級の攻撃者も上級者レベルの高度な攻撃を大量に行えるようになりました。さらに攻撃者の速度も上がり、休日でもAIが勝手に情報を見つけて攻撃してきます。

脆弱性の発見件数も急増しています。昨年7月のMicrosoftのWindowsアップデートは130件ほどでしたが、今年は622件前後と5倍近く。しかもクリティカルなものが200件超あり、実態は1,000件ぐらいでしょう。重要な脆弱性が15〜20倍に増えて対応できていないのが現状です。一方、防御側の人的リソースは変わりません。最終判断は人間に残りますし、低レベルな脆弱性報告が増える中で「有効かどうか」を判断できる人も足りていないのが実態です。

昨年までは、公開された脆弱性情報とパッチの差分をもとに人が攻撃コードを開発し、検証環境でテストしていました。今は脆弱性情報やパッチが出るとAIが1時間ほどで攻撃コードを作ってしまいます。

実例をご紹介します。日本時間の7月18日（米国時間では金曜日の夜）、WordPressのコア部分、つまりほとんどのWordPressが影響を受ける脆弱性が公開されました。新しいバージョンのみが対象とはいえ非常に重要な脆弱性で、多くのサイトで緊急対応が行われたと思います。

日本時間で追うと、土曜日の午前3時45分に公式が情報を開示し、4時に脆弱性情報として公開。自動アップデートが効いていたシステムでも更新完了は5時21分で、発表から1時間20分ほどかかっています。昨年までなら「緊急でも3日以内に」という感覚でしたが、攻撃コードがリポジトリで公開されたのは午前7時7分。公開から3時間ちょっとで攻撃コードが出回り、攻撃はもう来ているのです。この世代では、このくらい早く対応しなければなりません。

ゼロデイ（修正パッチが出る前の脆弱性）で攻撃されるものもありますが、公開されたらすぐ対応すべき脆弱性は、自動で対応できないなら早く対応できる体制が必要です。

AI時代は「CVE待ち」ではなく、外に出ている資産をあらかじめ数えておき、公開された脆弱性とマッチングして防ぐ、攻撃者視点の継続管理が必要です。スキャンすれば該当するものが全部やられような脆弱性も増えており、少しでも放置すると被害を受けます。先ほどのWordPressのような「数年に1回」の脆弱性が、今年はたくさん出るでしょう。

昨年までは重大な脆弱性でも、人間がトリアージ（優先順位付け）し、平日にパッチ適用を判断し、テストして本番適用する1〜3日の流れでした。今年からはこれでは間に合いません。脆弱性情報の発表から1時間以内に、自動アップデート・自動トリアージ・パッチ適用まで自動で進まないと安全とは言えないと考えています。人間の判断で1時間以内に対応できるのは相当お金をかけられる組織だけですから、今後はAIが判断を担うようになっていくでしょう。

ただし高速なパッチ適用は結構大変です。脆弱性情報をすぐ収集できるシステムが必要で、自動アップデートの頻度を上げるのもよい方法です。一方、すべてに高速でパッチを当てるのはリスクが高いので、攻撃面の管理、ASM（Attack Surface Management／アタックサーフェスマネジメント）が完全にできている必要があります。ここで言うASMは脆弱性を見つけることではなく、外部に公開されていて攻撃可能なサービスをすべてリストアップすることです。

そのうえで、脆弱性情報の収集・該当判断・トリアージまで進めても、検証環境の展開・パッチ適用テスト・本番パッチ適用の3つが自動化できていないと、1時間では絶対に間に合いません。検証環境はIaC（Infrastructure as Code）化、テストは自動化、本番適用はスクリプト化し、人が作業していた部分を残さないことが重要です。

外部公開システムは、今年から来年にかけてさらにリスクが高まります。WordPressの件も1日で侵入された企業が多く、盗まれると困るデータを扱っている組織は特に注意が必要です。

侵害を放置すると被害は拡大しますから、AIが「侵害された」と判断したら、サーキットブレーカーのようにデータの流れを止める仕組みが必須になります。ただしAIはあくまで判断支援です。脆弱性情報・資産情報・外部露出・業務影響・SBOMをもとにAIが一次評価を出し、侵害が確定しておらず業務影響がある場合は、人間の確認と責任者の承認を残す設計にしておくべきです。

狙われるのは脆弱性だけではなく、管理の甘いソフトウェアサプライチェーンも実際に狙われています。構成部品の情報をSBOM（Software Bill of Materials／ソフトウェア部品表）で管理し、新しい部品は一旦弾いて、脆弱性がないことを確認してから少し遅れて導入する、といった運用が重要です。

意外と狙われているのがGitHubやGitLabです。私たちが攻撃側の立場で外部資産を探索するとき一番ターゲットにするのは、開発者のメールアドレスがGitHubに誤って公開されているケースです。Gitはメーリングリスト文化をバージョン管理に利用しているため、メールアドレスが公開状態になりがちです。セキュリティ設定をすれば到達しないアドレスを作れますので、ぜひそちらを使ってください。そこを起点にしたフィッシングや、漏洩したアカウント情報での侵入が増えており、開発基盤が連携するSaaS側も狙われます。いま、開発者は確実に狙われています。

侵入経路が多い以上、侵害前提で「止める・防ぐ・復旧する」、さらに演習で確認しないと対応できません。多層防御（重要資産の分離、特権ID管理、EDR／NDR／SIEMの連携、横展開の検知・分離）、復旧可能性（イミュータブルバックアップ、リストア訓練、RTO／RPOの明確化）、AIを考慮した演習（外部資産探索、GitHub情報抽出、CI/CD侵害やSaaS権限悪用の想定）が柱です。

最初からすべて成熟させることはできませんので、少しずつ進めてください。大体2年かけて完璧にしてほしい、1年では難しいというのが私の実感です。成熟度はLevel 0（CVE後追い・手作業依存）からLevel 5（AI検出・修正・演習の定期運用）まで段階的に上げますが、ツール導入数ではなく、外部露出の削減、判断速度、緩和・復旧・演習の実効性で測ってください。

管理指標としては、ASM、外部露出部の初動時間、内部の脆弱性管理、SBOMやGitHub／SaaSの監査、復旧のレジリエンスなどが考えられます。被害事例も出てきていますから、他人の失敗を裏付けに対応策を考え、経営層には「リスクを管理してください」と伝えることも重要です。最大のリスクは、攻撃速度に組織の判断速度が負けることなのです。

セキュリティが大きく変わった点として、AIによる脆弱性検査（AI脆弱性診断）が今年から急増しています。AIに勝てるレベルで脆弱性を検査できる人は、日本にほんの少ししかいません。脆弱性診断を外注しても、AIを使っていない時点で攻撃者より弱くなってしまうのです。攻撃者より優位に立つには、AIによる脆弱性検査が必須です。

脆弱性診断は通常テスト工程で行いますが、AIが適用できる工程は「全部」です。要件定義、設計、実装、脆弱性診断・セキュリティテスト、リリース後の運用まで、AIの補助を使った方が圧倒的にクオリティが高くなります。

では、どの段階で行うか。1つ目は開発中（テスト工程の前）です。今有利なのはCodexのセキュリティプラグインで探す方法で、致命的なものを含め大抵の脆弱性を見つけてくれます。初歩的なミスを減らせますし、1年前にはできなかったビジネスロジックの脆弱性も見つかるようになりました。テストコストが重い後工程に比べ、プロジェクト全体で最もコストが下がる方法です。

2つ目は完成後のAIセキュリティ検査です。ソースコードと実行環境を用意し、プロによるAI補助付きの診断を行います。開発者より深いレベルで検査でき、今考えられる中で一番強い検出ができます。3つ目は外部攻撃者と同条件（ブラックボックス）で、設計書もソースコードもない状態で実施します。スライドの有効性は、バグバウンティで稼いでいるXBOW社がMythos previewで評価した数値で、ソースコードなしでも結構見つけられます。4つ目のソースコードのみの検査は、実行環境がないため半分ぐらい見逃しがあり、攻撃者よりかなり劣ります。ここだけでやっていると非常に不利なので気をつけてください。

ベストは、開発中にAIで脆弱性やバグを修正し、完成後にAIセキュリティ検査を実施すること。新しい有用なモデルが出るたびにやり直すのが理想です。ベターは攻撃者と同条件の検査を行って修正すること。バッドは、ソースコードのみの検査や従来型スキャナのみで済ませることです。

AIは同じモデルでも毎回同じ回答をするとは限りません。何回か実行したり、パラメーターを変えて30並列、100並列で動かしたりして徹底的に見つけるのが、プロのやり方です。一番厄介なのがハルシネーションで、存在しない脆弱性を見つけて修正コードまで書いてくることがあります。最終的に人が検証して、本当に脆弱性かを確認しなければなりません。

検出ゼロが脆弱性ゼロではありませんが、AIを使った方が網羅性は確実に高いです。新しいモデルが出たらやり直すこと、そして使う人のハーネス（AIを動かすフレームワーク）で結果がまったく変わることも覚えておいてください。

AIを使おうとすると「学習利用NG」「保存NG」「国外持ち出しNG」「第三者送信NG」といった組織内の制約があり、フロンティアモデル（最先端のAIモデル）が使えないことがあります。対処はNGの中身で変わります。学習利用NGなら、既定で学習に使わない商用API・エンタープライズ契約を提示して交渉する。国外移転NGなら、リージョン指定可能なクラウド経由を提示する。第三者送信NGなら、Kimiなど中国製モデルをローカルで動かしますが、ハードウェアが高く、見つかるクオリティにも制限がかかります。ソースコード開示NGなら、公開情報だけを使うブラックボックステストです。全面NGなら従来型の手動診断のみになりますが、AIより弱いので攻撃者に負ける可能性があることを理解していただく必要があります。公開Webサーバーなら、ブラックボックスでもよいのでAI検査をやってほしいと思います。

モデルや環境で結果に差が出るのは、攻撃と防御の両方に使えるデュアルユースの条件で使うには認証が必要だからです。私たちセキュリティの専門家は大体AnthropicとOpenAIの認証を取っており、これがあると攻撃用コードも出せます。一般向けのものだと、攻撃コードを生成してくれない、脆弱性の発見が薄いといった問題が起きます。法人でも認証が取れますので、まだであれば検討してください。

ただし、AWSのBedrockやGoogleのVertex AI経由では現時点で対応しておらず、診断能力がとても弱くなります。また、バイナリもほぼソースコードと同じ状態で読めますので、バイナリが公開されていればソースコードが公開されていると考えてください。攻撃者はCodex、Opus、中国系モデル、ローカルLLMを使っており、防御側はTACやCVPで能力差を埋める必要があるのです。

対象は、デジタル庁が公開したオープンソースの政府AI基盤「源内」です。公開直後にCodex（GPT-5.5）へ「脆弱性を検出し、発見したら検証コードを作成して脆弱性診断士の仕事をアシストしてください」という単純なプロンプトを与えたところ、数分で脆弱性を2つ見つけ、レポートと検証コードまで書いてくれました。後に修正された5つのうちの2つです。

Claude Codeでも、自分で作ったプログラムを診断させると、脆弱性を重大度付きで一覧にし、パッチを作り、残存リスクまでまとめてくれます。過去に作ったものでも、AIの脆弱性診断は非常に強力です。

ただし、出力にはちゃんとした脆弱性ではない偽物、いわゆるAI Slopが混ざりますので、検証したうえで使ってください。

もう1つ、先進的なモデルではファイアウォールを組んでいても攻撃が抜ける事例がニュースになっています。トンネリングという手法で制限を突破する方法はたくさんあり、サンドボックスでも防ぐのは難しいのが現状です。

以上、Mythos世代の脆弱性対応とセキュリティ対策をご紹介しました。ありがとうございました。