AI時代の脆弱性対応、投資すべきは「直す力」

アプリケーションセキュリティ専門家が説く、診断の使い方を変える4つの視点

2026年10月9日(金)小泉真由子（ITジャーナリスト/エディター）

リスト

AIによって攻撃の探索範囲と速度が広がる一方、防御側でも脆弱性の発見やコード修正への活用が期待されている。だが、診断の報告や指摘が増えても、企業がその意味を判断し、実際に直せなければリスクは減らない。ではどうすべきか。2026年9月8日に開催されたウェビナーで、アスタリスク・リサーチ代表取締役の岡田良太郎氏が「AI時代に、自社のアプリケーションセキュリティをどう組み直すべきか」と題して解説した。その内容をレポートする。

放置した脆弱性が見つかるまでの猶予が消える

　ウェビナーで解説を務めた岡田良太郎氏（写真1）は、サイバーセキュリティ分野で20年以上のキャリアを持つセキュリティ専門家・起業家である。Webアプリケーションセキュリティの普及啓発に取り組む国際的な非営利団体OWASP（Open Worldwide Application Security Project）の日本チャプター「OWASP Japan」で、チャプターリーダーも務める。

写真1：アスタリスク・リサーチ代表取締役／OWASP Japan チャプターリーダーの岡田良太郎氏

　AIによる攻撃と聞くと、未知の高度な手法を想像しがちだ。しかし岡田氏によれば、実際に観測されたAI活用型の攻撃で使われていたのは、設定ファイルに残された認証情報や平文保存されたトークン、APIキーなど、従来から問題とされてきた設定や運用上の不備だったという。

　「AIしか知らない魔法みたいなものが使われているというよりは、網羅性とスピードみたいなところでやられています」（岡田氏）

　人間の攻撃者には、調べる範囲や活動時間に限界がある。一方、AIは休まずシステムの弱点を探り続け、行き詰まれば別の手を試す。設定ファイルに残った認証情報のように、社内では「外からは見えないだろう」「目立たないだろう」と考えて放置していた問題も、網羅的に探られれば検出される可能性が高まる。

　「バレないと思ってほったらかしていると、あっさりバレます」と岡田氏が指摘するのは、そうした探索の速度と範囲が広がっているためだ。放置していた問題が見つかるまでの猶予は、以前よりも短くなっている。脆弱性情報を受け取る企業側では、対応すべきものを選び、実際に直さなければならない。その優先順位は、深刻度の高さだけで決められるのだろうか。

深刻度が高いものだけ追っても漏れる

　岡田氏が示した同社の集計（2026年9月3日時点）によれば、米CISA（Cybersecurity and Infrastructure Security Agency：サイバーセキュリティ・インフラストラクチャセキュリティ庁）が公開する悪用確認済み脆弱性のカタログ「KEV（Known Exploited Vulnerabilities）」1694件のうち、211件・約12.5%はCriticalでもHighでもなかった。対応する脆弱性を絞り込む際、深刻度の評価指標であるCVSS（Common Vulnerability Scoring System）を基準にCritical・Highだけを追う方法がある。だが、深刻度の高さと実際の悪用は一致しない。

図1：悪用が確認された脆弱性にも、深刻度がCritical・Highではないものが含まれる（出典：CISA KEVを基にアスタリスク・リサーチが分析、2026年9月3日取得）
拡大画像表示

　深刻度だけで対象を絞ると、すでに攻撃に使われている脆弱性も見落とすことになる。岡田氏は「CVSSが低くて悪用されたというようなところは、みんな大穴として使われる可能性がある」と話す。評価が低いから後回しでよいと見なされた脆弱性が、攻撃者にとっては入りやすい突破口になる、という懸念だ。

　脆弱性情報そのものの量も増えている。CriticalやHighだけを追っても対象は膨らみ、KEVやEPSSで優先度を絞っても、ものによっては週単位の確認では間に合わない。

　しかもKEVは、提供元によって収載範囲が異なる。岡田氏の集計では、CISAのKEVが1694件であるのに対し、民間のVulnCheck KEVは5216件を収載する。どのKEVを見るかによって、「悪用されている」が指す範囲そのものが変わるということだ。今後30日間に悪用が観測・報告される可能性をスコア化するEPSS（Exploit Prediction Scoring System）なども含め、複数の情報を組み合わせる必要がある。

　ただし、見る情報源を増やすだけでは、担当者が処理する量も増えてしまう。そこで岡田氏は、外の情報を追いかけるだけでなく、まず自社で何を使っているかを把握することに目を向けるべきだという。

情報を絞る出発点は自社の部品台帳

　「例えば、自社のコードが1000あります、1万ありますといったところで有限なわけです」と岡田氏が言うとおり、外部で公開される脆弱性情報は膨大でも、自社が実際に使っているソフトウェアや部品は限られている。何を、どこで、どのバージョンで使っているかを把握しておけば、外部の情報を自社の資産と照合し、対応が必要な更新を絞り込める。

　「開発を効率化するその動き自体が、管理すべき部品を増やします。必要なコードを外から調達してくる。しかも学習して知っている範囲なので、ちょっと古いものだったりすることもあります。AIには、オーソライズされていない道具をGitHubのようなリポジトリから持ってきて、自分で活用するという癖があります」（岡田氏）

　AIにコード生成だけでなく、必要な部品を外から選んで持ってくるところまで任せれば便利になる。その一方で、開発者が把握していない古い部品や非公認の道具が入り込めば、サプライチェーンのリスクも高まる。AIが持ち込む部品も、台帳の管理対象に含める必要がある。では、AIが持ち込むリスクも、AI自身に見つけてもらえばよいのだろうか。

●Next：AIに「どの視点で、何を確認させるのか」を決めるのは人間

この記事の続きをお読みいただくには、
会員登録（無料）が必要です