AikidoのCVE Exploitability Analysisは、LLMエージェントが自社コードベースでのCVEの悪用可能性を分析し、許可された範囲でトリアージを自動実行する。Allowed Actions・Spend Limit・Historyによる統制設計と、姉妹機能Secrets AutoTriageに共通する「存在ではなく悪用可能性を見る」思想を読み解く。目指すは no false positives、ただし危険を隠さずに。
ソフトウェア開発の現場で、CVEアラートは珍しいものではなくなった。
GitHub、SCAツール、コンテナスキャン、クラウドの脆弱性管理。どこかでライブラリやOSパッケージに既知脆弱性が見つかれば、すぐに通知が飛んでくる。
それ自体は進歩だ。昔は、脆弱性があっても気づけなかった。今は気づける。
しかし、現場で問題になるのはその先だ。
通知されたCVEは、本当に自分たちのアプリケーションで悪用可能なのか。
脆弱なライブラリは入っている。だが、その関数は呼ばれているのか。本番コードで使っているのか。テストツールの依存関係にすぎないのか。外部入力からその危険な処理まで到達できるのか。
ここを見ないまま「Critical」「High」と表示されても、開発チームは動けない。
いや、正確には、動けなくなる。アラートが多すぎるからだ。
脆弱なパッケージが依存関係に存在することと、その脆弱性が自社環境で悪用可能であることは、同じではない。
その脆弱性が特定の関数にしか影響しないなら、自社コードがその関数を呼んでいなければ実際のリスクは大きく下がる。開発・テスト用ツールの依存として入っているだけなら、ユーザーから攻撃される経路はないかもしれない。
CVE対応で本当に見たいのは「含まれているか」ではない。
「使われているか」 「本番に出ているか」 「外部入力から到達できるか」 「攻撃者が実際に悪用できるか」
ここである。
従来のスキャナは、まず「含まれているか」を見る。これは必要だ。しかし、それだけでは足りない。
現場が欲しいのは、発見ではなく判断だ。
Aikidoには以前からReachability Analysisがある。脆弱なコードへの実行経路があるかを見て、到達不能なCVEアラートを減らす仕組みだ。
CVSSスコアは「その脆弱性そのもの」の危険度であって、「あなたのアプリケーションで今すぐ悪用できるか」ではない。Reachability Analysisは、その差を埋める第一歩だった。
今回のCVE Exploitability Analysisは、その上にLLMエージェントによるコードベース固有の推論を重ねる。
単純な到達性だけでは判断できないケースがあるからだ。
関数は呼ばれている。でも入力は固定値かもしれない。外部入力は来る。でも途中で検証されているかもしれない。危険なAPIはある。でも本番設定では無効かもしれない。
こうした文脈を読むには、依存関係の有無だけでは足りない。CVE Exploitability Analysisは、そこに踏み込む。
AikidoのCVE Exploitability Analysisは、オープンソース依存関係のCVEを、自社の実際のコードベースに照らして分析する機能だ。
AikidoのLLMエージェントが、脆弱なパッケージがリポジトリ内でどのように使われているかを読み、その環境で本当に悪用可能なのかを評価する。そして、設定で許可された範囲に応じて、triage actionを実行する。
ここが重要だ。
これは単なる説明文生成ではない。workspace-wide automationとして動く。Advanced Settingsで一度設定すると、条件に一致する未解決のCVE findingsに対して毎晩自動で分析が走る。オンデマンドの即時実行もでき、各実行結果はhistoryで確認できる。
現在はfeature flag配下の機能で、利用するにはAikidoチームに有効化を依頼する必要がある。
CVEの説明なら、NVDにもGitHub Advisoryにもベンダー告知にも書いてある。
問題は、そのCVEが自社のコードでどう意味を持つかだ。
脆弱なパッケージは入っている。 しかし、その危険な関数は呼ばれているのか。 呼ばれているとして、攻撃者が制御できる入力が届くのか。 設定上、その危険なモードは有効なのか。 テストコードだけなのか、本番コードなのか。 実際の実行経路に乗るのか。
AikidoのCVE Exploitability Analysisは、既存のopen dependency findingsを対象にする。つまり、新しくCVEを探すのではなく、すでに検出されているCVE findingsを、実際のコード上の利用状況に基づいてトリアージする。
CVEを見つけるAIではない。
CVEが、自社環境で本当に危ないかを読むAIだ。
この機能で面白いのは、AIエージェントの判断をどこまで自動反映させるかを、利用者側が設定できる点だ。
| アクション | 発動条件 | 結果 |
|---|---|---|
| Downgrade | CVE自体は本物だが、自社コードでは基本スコアほど危険ではない | severityを下げる |
| Upgrade | 自社コードでは基本スコア以上に悪用しやすい | severityを上げる |
| Snooze | 今すぐではないが、後で対応すべき | 一時的に非表示 |
| Ignore | 自社環境では悪用可能ではない | findingをfeedから外す |
注目すべきはUpgradeの存在だ。
これは単なるノイズ削減ツールではない。ベーススコア以上に危険なCVEを引き上げる方向にも働く。「静かにするAI」ではなく「優先順位を正すAI」である。
そして、許可していないアクションは自動適用されない。
DowngradeとSnoozeだけを許可し、Ignoreは人間承認にする、という運用もできる。エージェントがIgnoreを提案しても、それはpendingとして残り、historyから人間が確認して承認できる。
これは日本企業にとってかなり重要な設計だと思う。
AIに全部任せるのは怖い。しかし、AIの判断を全部捨てるのももったいない。
「提案はさせるが、自動実行は限定する」 「Ignoreは人間承認にする」 「まずはHigh以上だけで試す」
AIを入れるか入れないか、という二択ではない。
AIに何を許すかを設計する機能になっている。
分析対象のscopeも設定できる。
Minimum Severityは Critical only / High and above / Medium and above / All severities から選ぶ。Repositoriesでは対象リポジトリを選べる。
最初から全リポジトリ、全severityで回す必要はない。
インターネットに露出しているサービス。 顧客データを扱うリポジトリ。 認証・決済・管理画面に関わるコード。 CriticalまたはHighのCVE。
ここから始めるのが自然だ。
CVE Exploitability Analysisは、全CVEを一律にAI分析するための機能ではない。
限られたクレジットと、限られた人間のレビュー時間を、どこに使うかを決めるための機能だ。
忘れてはならないのは、これが有料機能だという点だ。
1 CVEのトリアージごとに1 Aikido Creditを消費する。LLMエージェントがリポジトリを読み、推論する以上、コンピュートコストは避けられない。
このコストが見合うかどうか — ROIの判断は利用者側に委ねられている。
CVEアラートの多くが、実環境ではそのまま悪用可能とは限らない現実を踏まえれば、「エンジニアが1件ずつ調査する工数」と「1クレジット」を天秤にかける計算は、各組織でそう難しくないはずだ。
Spend Limit per Dayで24時間あたりの消費クレジットに上限をかけられる。デフォルトは100。Cost to Inbox Zeroの見積もりで、現在のscopeに一致するCVE数とフル実行に必要なクレジット数も事前に確認できる。
AI機能で怖いのは、便利さよりも先に、費用が読めないことだ。
この機能は、日次上限・scope・severity・repository・allowed actionsで、使い方をかなり制御できる。
「AIだから高そう」ではなく、「どのCVEにAI分析を使うか」を設計する機能だと見るべきだ。
CVE Exploitability Analysisは、設定されたworkspaceで毎晩自動実行される。対象は、設定したseverityとrepository scopeに一致するopen findingsだ。
夜間実行を待たずに、Advanced SettingsからStart Analysisでオンデマンド実行もできる。各runはdaily spend limitと利用可能クレジットの範囲内で動き、クレジット切れ・日次上限到達・対象issueなしの場合は、その理由が表示される。
CVE対応には、定常運用と緊急対応がある。
毎晩のInbox整理と、緊急時のオンデマンド分析。
この二つを分けて使えるのは、運用上かなり現実的だ。
すべてのrunがhistoryに記録される。
実行日、package、repository、分析されたCVE数、実行されたtriage actions。詳細画面では、agent-written summary、各CVEに対するactionとreasoning、runのtimelineまで確認できる。
これは単なるログではない。
監査のための説明材料だ。
なぜこのCVEをignoreしたのか。 なぜseverityを下げたのか。 AIが何を提案し、何を実行したのか。 人間が承認したのか、自動適用されたのか。
CVE対応は、後から説明を求められる。
「AIが判断したから」では説明にならない。
AIが何を根拠に判断し、それを人間または設定がどう扱ったのか。ここまで残ることで、初めて運用に乗る。
同じ思想は、シークレット検出にも展開されている。Secrets AutoTriageだ。
これはsecret scanningそのものではなく、検出されたsecret findingsの下流に位置する。
test files、mock data、placeholderを認識してfalse positiveを減らし、さらにLive Secret Detectionと連動して、そのsecretがまだ有効か、どんな権限を持つかを見る。
失効済みならdowngrade。有効でwrite/delete権限を持つなら即時対応としてupgrade。
ここでも思想はCVEと同じだ。
存在ではなく、悪用可能性を見る。
そして、パターンだけでは本物と区別できないものは隠さない。疑わしい場合は、reviewできるようにfindingを残す。
ノイズ削減とは、危険を隠すことではない。
明らかに安全なものを減らし、不明なものは残すことだ。
なお、Secrets AutoTriageはデフォルトでは有効ではなく、workspace adminがSettings → Triageから有効化するopt-in機能だ。
CVE Exploitability Analysisとは有効化の形は違うが、どちらも勝手に全自動化される機能ではない。管理者が明示的に有効化し、段階的に使う設計になっている。
セキュリティツールの歴史は、検知の歴史だった。
脆弱性を見つける。 依存関係を見つける。 secretを見つける。 設定ミスを見つける。 攻撃面を見つける。
見つける力は上がった。
しかし、見つける力が上がるほど、次の問題が出てくる。
どれが本当に危ないのか。 どれを先に直すのか。 どれは後回しでよいのか。 どれは人間が判断すべきなのか。
Aikidoがやろうとしているのは、AIに判断を丸投げすることではない。
AIに何を許すかを人間が設計するトリアージである。
目指すは "no false positives"。
ただし、危険を隠さずに。
AIで脆弱性を発見する話は派手だ。AI Pentestも分かりやすい。
しかし、企業の現場で本当に効くAIは、もっと地味なところにある。
毎日積み上がるCVE通知。 誰も読み切れないアラート。 「これは本当に直すべきか」という一次判断。
そこを手伝うAI。
派手ではない。だが、現場には効く。
CVE対応で必要なのは、アラートを増やすことではない。
本当に危ないものを、見失わないことだ。
本記事はAikido公式ヘルプドキュメント(2026年7月6日時点)に基づく。feature flag配下の機能仕様・課金条件は今後変更される可能性がある。
Aikido Community Japan
公開日: 2026/7/6
最終更新: 2026/7/6
セキュリティの最新情報をお届けします。