脅威アクターがサイバー攻撃に人工知能を利用しているという懸念が高まる中、あるソフトウェアベンダーが脆弱性修復に大規模言語モデル(LLM)を活用し、成果を上げています。
先月、Ivantiはモバイルゲートウェイ製品「Sentry」に存在する最大深刻度の重大な欠陥であるCVE-2026-10520を公表しました。しかし、CVSSスコア10点満点を記録したこの脆弱性を発見したのは、セキュリティ研究者でも、サードパーティベンダーでも、あるいはIvanti自社のエンジニアでもありませんでした。発見したのはLLMだったのです。
Ivantiは先月、エンジニアリングチームおよび製品セキュリティのレッドチームの能力を高め、特に「従来型のツールでは検知できない」欠陥を特定・修正するために、高度なモデルの活用を開始したと発表しました。今週、IvantiのチーフセキュリティオフィサーであるDaniel Spicer氏がDark Readingの取材に応じ、このプロジェクトの内側、これまでの成果、コスト管理の方法、そしてフロンティアモデルの改善がどれほどのスピードで進んでいるかについて語りました。
Dark Reading: LLMの利用を始めた当初の経緯から伺えますか。このプロジェクトが生まれたきっかけは何だったのでしょうか。
Daniel Spicer氏: 2月の中旬から下旬にかけてのことでした。NSG(ネットワークセキュリティグループ)製品の多くを担当しているMike Reamerとチームで話し合っていたのですが、興味深いことに、私たち二人ともほぼ同時期に、Claudeの4.6世代のモデルが実際にかなり優れていることに気づき始めていたんです。アプリ開発だけでなく、セキュリティの分野でも何かできるのではないかと考え始めたのがこの頃でした。そこで3月の第1週に社内プロジェクトを立ち上げました。エンジニアリングとセキュリティの合同チームで、大きく二つの方向性を設定しました。一つは脆弱性を自動的に解消する方法を探ること、もう一つはもちろん、見逃している脆弱性を見つける手助けをどう実現するかというものです。
当然ながら、多くの人が同時期に同じような発想に至っていたようで、それからわずか数週間後にAnthropicがProject Glasswingを発表しました。Anthropicも社内で同じような結論に至り、業界の他の企業とも同様の結論に至った関係者との対話を始めていたようです。実際、私たちがAnthropicと直接ライセンス契約を結び、こうしたユースケースの検討を始めたのもちょうどその頃でした。
Dark Reading: モデルを脆弱性の発見と修正の両方に使っていたのですか。
Daniel Spicer氏: はい、ただ、はっきりさせておきたいのですが、これは二つの異なる方向性だと捉えています。既存のツールが見逃している脆弱性を見つけることは、間違いなく重要な取り組みです。一方、脆弱性の解消という側面では、SAST(静的アプリケーションセキュリティテスト)やDAST(動的アプリケーションセキュリティテスト)のスキャナーから検出結果が上がってくると、そこには弱点が示されるわけですが、その弱点すべてが脆弱性というわけではありません。そのコード内のどこに弱点があるかによって話は変わります。実際にユーザーの制御下にさらされているのか、あるいは複数の弱点が組み合わさって製品内に悪用可能な脆弱性を生み出しているのか、といった点です。Ivantiではここについて非常に厳格な立場を取っており、こうした弱点はすべて洗い出して解消する方針です。自動修復の発想は、SASTによってエンジニアが生成しているこうした弱点を見つけた際に、エンジニアに修正を指示するのではなく、事前にその弱点を検知して解消し、修正済みの状態でエンジニアに再提出できないか、というものです。それが最終的な目標です。
Dark Reading: このLLMプロジェクトを始めてから、どのような成果が出ていますか。これまでに発見・修正した脆弱性の数はわかりますか。
Daniel Spicer氏: 発見した件数についてはまだ正確な数字をお伝えできません。今後数カ月のうちに、この研究成果の一部を公開する予定です。ただ、修正の面については、正直なところ良い意味で驚いています。しかもAnthropicのモデルだけでなく、OpenAIの多くのモデルでも良好な結果が得られています。
Dark Reading: 複数のLLMを併用しているということですね。
Daniel Spicer氏: はい。フロンティアモデルに加えて、社内で特殊な運用方法によって動かしているオープンソースモデルも数種類組み合わせて、最良の結果を得ようとしています。それらのモデルは想像されるような形でスコアリングしているわけではありません。私たちが本当に取り組もうとしているのは、まずCWEを基準に脆弱性のクラスを分類し、高品質な修正を実現できる適切なプロンプトを作成することです。私たちはこれをより恒常的な運用の仕組みへと発展させようとしています。つまり、そのプロセスを取り出してスキルとして定義し、それをエージェントに組み込むことで、該当のCWEが検出された際に自動的にそのチケットを取得してエージェントに渡し、エージェントに修正させ、そのままパイプラインを進めて再びSASTやDASTのスキャナーに戻し、「まだこの問題は検出されるか」を確認させるという流れです。そして答えが「いいえ」であれば、自動化されたパフォーマンステストや潜在的なバグの検証を実行し、その結果をエンジニアに戻すのです。
正直に言うと、最終的にはこの工程にエンジニアが関与する必要すらなくなるのではないかという感触があります。ただ、私たちはまず複雑度の低いCWEから着手し、徐々に複雑度の高いCWEへと対象を広げてきました。その多くにおいて、かなり質の高い修正が得られています。これは二つ目の取り組みの一環でSASTツールが見逃していた問題として見つかったものであったり、プロンプトが実際に機能しているかをテスト・確認するためにラボ内で作成したものであったりします。
Dark Reading: AIエージェントに権限を与えるというのは、ある種の思い切った決断だったのではないでしょうか。エージェントが本来意図していなかった行動を取ってしまった悪名高い事例も報告されていますが、Ivantiのセキュリティチームとしても取り組みを始めるにあたって何かためらいはありましたか。
Daniel Spicer氏: ためらいというより、当初は正直、成功への期待値自体が低かったと思います。ここまでうまくいくとは、私たちの誰も予想していませんでした。ただ、エージェントが予想外の行動を取ってしまったという数々の失敗事例については、そこにはガードレールの設計やエージェントの使い方に関する教訓が常に存在していると思います。私たちがこの仕組みを運用に組み込む際にエージェントに与えているのは、基本的に一つのPR(プルリクエスト)であり、そこには特定済みの問題が含まれています。そして「このコンテキストの中でこれを修正せよ」と指示し、それで完了です。GitHubへのフルアクセスや、OSを消去できるような権限は一切与えていません。特定の目的のために、自己完結型で短期間だけ動作するハーネスという位置づけです。とはいえ、繰り返しになりますが、得られている修正の質には驚かされています。
Dark Reading: 逆に、こうした目的でAIエージェントの有効性を目の当たりにしたことで、これらのモデルが攻撃的なサイバー攻撃に利用され得るという見方に何か影響はありましたか。この点についてのお考えは変わりましたか。
Daniel Spicer氏: [間を置いて] そうですね、影響はあったと思います。もともとある程度の考えは持っていましたが、SonnetやOpus 4.6を触り始めてから劇的に変わったというわけではありません。GPT 5.5や5.6も非常に印象的なモデルで、確実に大きなギャップを埋めてきています。ただ、私のこうした懸念を最も裏付ける出来事があったとすれば、それはある特定のバグバウンティ報告でした。それは私たちがすでに特定していた問題に関するものだったので、その点では良かったのですが、その報告を見て「これはOpusモデルから出てきたものだな」と感じました。フォーマットの仕方、論旨の展開の仕方、構成の仕方などがそう思わせたのです。そしてこれこそが、こうしたモデルが悪用された場合の威力を最も強く実感させた出来事の一つだったと思います。月額100ドルのClaudeのサブスクリプションが、例えば5,000ドルから10,000ドルのバグバウンティを獲得しうるという事実を目の当たりにしたわけです。これは現在存在するバウンティプログラムのあり方に大きな影響を及ぼすと考えています。
Dark Reading: その話題に関連して、不正確なAI生成のバグ報告を数多く目にしていますか。あと一歩というところまで来ている7割5分程度の完成度のものから、完全なAIスロップ(質の低いAI生成物)まで、幅はありますか。
Daniel Spicer氏: 昨年は本当にひどい状況でした。昨年は、大量のスロップのせいで、公表しているSLAを守ることすら苦労するほどでした。しかし今年は質が違います。先ほども触れた1月から2月にかけての時期に、状況が変わり始めました。今寄せられる報告は、おっしゃる通り7割から8割方完成しているか、あるいは端から非常によく書かれた報告のどちらかで、見た瞬間に「これを本当に人間が書いたのだろうか」「何かしっくりこない」と感じるようなものです。そしてスロップの量そのものも減少しています。バグバウンティの報告件数自体が大幅に減っていて、指標で見ると崖から落ちるように急減しています。これは、昨年見られたような大量のスロップが来なくなったことが要因だと考えています。
Dark Reading: それはなぜだと思われますか。
Daniel Spicer氏: 提出する側が、AIが正しく生成したと思っていても、こちらが見て「これはひどい、意味が通らない」と判断するような報告を、以前ほど提出しなくなったのだと思います。昨年は本当に大量の報告が来ていました。数百件という単位でした。
Dark Reading: 二つの取り組みと複数のフロンティアモデルを併用する中で、AI利用コストの上昇について懸念はありますか。あるとすれば、どのように管理していますか。
Daniel Spicer氏: はい、懸念しています。社内の攻撃側チーム(レッドチーム)のマネージャーに、コスト管理に関するより良いガイドラインを整備するよう依頼しました。私のコスト管理に関する考え方は、従来のセキュリティの議論とは少し外れていて、むしろ「これはAIの効果的な使い方と言えるのか」を問うことに重きを置いています。そして、多くの人がこの問いをそもそも立てていないと感じています。
一つエピソードをお話しします。あるチームメンバーが、自社のオンプレミス製品の新バージョンをゼロからインストールし、テストができるよう正しくデプロイ・セットアップしようとしていたのですが、私はその件で彼に指導しなければなりませんでした。彼はそれを自分にとって手間のかからない、あるいは大した工夫を要しないタスクだと判断し、AIにやらせるのが良いアイデアだと考えたのです。しかし、本来想定されていない仮想インフラ上にソフトウェアをインストールし、正しく構成する方法をAIに延々と試行錯誤させることが、レッドチーム担当者の時間の使い方として本当に妥当なのか。おそらく妥当ではありません。しかも、AIにとっても非常にコストのかかるタスクです。これが社内向けの(AI利用に関する)ガイドラインを整備する動機の一つになりました。何が良い実験と言えるのか、何がAIの良い使い方とは言えないのかを、どう判断すればよいのか。運が良かったのか、あるいはプロジェクト設計が良かったのか、複雑度の低いCWEから着手し、徐々に複雑度を上げていくという当初の方針が、結果的にAIがどこでつまずくのかを見極める手助けとなり、コストがどこで増加し始めるかを把握できるようになりました。これは良い結果だったと思います。
Dark Reading: このプロジェクトはまだ初期段階だとは思いますが、モデルがどのような種類の脆弱性を見つけるのが得意か、何らかの傾向やパターンは見えてきましたか。
Daniel Spicer氏: まだ十分な傾向データが揃っているとは言えませんが、SASTスキャナーが弱いとわかっている部分をLLMが効果的に補ってくれるケースが幾つもあり、嬉しい驚きを感じています。その一例が、不正確な認可、あるいは特定のエンドポイントにおける認可・認証の欠落です。SASTスキャナーはあるエンドポイントを見つけると、そのデータフローを最後まで追跡して「この関数は問題ない」と判断してしまい、そのエンドポイントに本来必要な認可や認証が備わっているべきだということまでは気づきません。これは従来、人間が確認する必要がある領域だったからです。
しかし、こうした要素のマッピングをLLMに与えて「すべてのエンドポイントを確認し、認可や認証が欠けている、あるいは不十分と思われる箇所について提案してほしい」と指示すると、かなり良い仕事をします。これは特に興味深いと感じている点です。というのも、従来型のセキュリティツールが機能しないとわかっている部分を補強してくれるからです。ただ、まだ十分な傾向データが揃っているとは言えませんし、当社のポートフォリオの規模を考えても、特定の種類の問題を見つけるのが得意だと言い切れるほどのデータを得るのは難しいかもしれません。また、これは時間とともに変化していくものだとも考えています。モデルは日々進化を続けています。GPT 5.6は素晴らしい出来ですし、MythosやFableで何ができるかについても多くの人が話題にしています。組織にとって最善なのは、プロセスを確立し、そのプロセスを支えるハーネスを構築し、モデルを入れ替えられるようにしておくこと、そして次のモデルに切り替える際にプロンプトやスキルを効果的にテストできるようにしておくことだと思います。モデルは今後もどんどん進化していくのですから。
Dark Reading: その点に関連してですが、これらのモデルをIvantiの既存のシステムやプロセスに組み込むまでに、どれくらいの期間を要しましたか。
Daniel Spicer氏: もう完了したと言えば嘘になります。先ほど申し上げた通り、社内プロジェクトを本格的に始動したのは3月でした。今も隔週の打ち合わせを続けていて、取り組みが確実に前進するよう努めていますが、取り組めば取り組むほど、改善したい点が次々と見つかってきます。AIをめぐる今の盛り上がりや、私たちが見出している成果自体が、継続的な改善を後押ししやすくしているとも感じています。ただ、これは他のあらゆる取り組みと同様に、ワークフローへの最適化を絶えず継続的に改善し続けるプロセスになるだろうと思います。現在は、SASTやDAST由来の問題を自動処理するためのより優れたハーネスの開発に取り組んでいて、それが完成すれば、すぐに次に何が必要かという議論を始めることになるでしょう。
これは絶えず進化し続けるプロセスです。というのも、あるプロンプトについて「もうこれで完成した」「再利用可能なスキルにできた」と感じた途端に、モデルが変わってしまい、すべてを再テストし、再び調整をやり直さなければならなくなるからです。これはまだ触れていなかった点ですが、モデルが変わるたびに、たとえOpus 4.6から4.7への移行や、GPT 5.5から5.6への移行のような小さな変化であっても、プロンプトやスキルの有効性を再テストする必要があります。すべてを再テストしなければなりませんし、随所で調整も必要になってきます。
Dark Reading: 最後の質問です。この技術によって、攻撃のスピードに対応できるペースで脆弱性を発見・対処できるようになり、Ivantiと攻撃者との間の力関係がより対等に近づいているとお感じになりますか。
Daniel Spicer氏: まだそこまでは至っていないと思います。それには二つの理由があります。まず一つ目は、私たちがこのプロセスを実運用の段階まで持っていくには長い時間がかかるという点です。脅威アクターはそうした手間を気にする必要がありません。彼らはどれだけ雑で乱暴なやり方をしても構わないのです。自分たちのコードに誤ってバグを混入させてしまう心配をする必要もありませんし、盗んだクレジットカードを使っている場合はトークンのコストを気にする必要すらないこともあります。そして二つ目、少し視点を変えると、これは従来型のエンタープライズにおけるパッチ管理の課題そのものには、実はあまり変化をもたらしていません。私はここにこそ多くの重圧がかかっていると感じています。オンプレミスソフトウェアを月に一度どころか週に複数回も再デプロイしなければならない状況、つまり異なる製品で新たな問題が次々に発生し、迅速に対処しなければならない状況というのは、IT部門にとって大きな重圧となっているのです。
