1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@shalXXXX(shal 0618)

LLM エージェントによる脆弱性探索の公開研究から考える、パッチ適用期限の決め方

1
Posted at

LLM エージェントに脆弱性を探させ、悪用まで試させる研究が、2024 年から 2026 年にかけて一気に増えました。この記事では、公開された論文・競技・企業の発表から「どこまでできるようになったか」を確かめ、防御側がパッチ適用の期限をどう決め直すべきかを、優先度付けの小さなコードと合わせて整理します。

攻撃の手順やプロンプトは扱いません。扱うのは研究の結果と、守る側の運用です。脅威レポート全体の読み解きは LLM で攻撃はどう変わったか：2026 年の脅威レポートから読む悪用の実態と防御側の優先順位 にまとめています。

公開研究でわかっている LLM エージェントの実力

時期 発表 わかったこと
2024 年 4 月 Fang ら（arXiv:2404.08144） 既知の脆弱性 15 件を対象に、CVE の説明を渡すと GPT-4 のエージェントが 87% を悪用できた。説明なしでは 7%
2025 年 3 月 CVE-Bench（arXiv:2503.17332） 実在の Web アプリの重大な CVE 40 件で評価。概要では最良のエージェントでも成功は最大 13%
2025 年 7 月 Google Big Sleep SQLite の脆弱性 CVE-2025-6965 を、悪用される前に見つけたと発表。3.50.2 で修正
2025 年 8 月 DARPA AIxCC 決勝 脆弱性の発見から修正までを自動で行うシステムを競い、Team Atlanta が優勝、Trail of Bits が 2 位。決勝進出チームのシステムは公開される
2026 年 2 月 Anthropic（Claude Opus 4.6） OSS で、これまで知られていなかった深刻度の高い脆弱性を 500 件以上見つけたと発表。人が確認したうえで報告し、一部は修正済み

この表から読み取れることは 3 つあります。

「説明があれば悪用できる」は早くから示されていた
Fang らの結果は、公開された CVE の説明がエージェントにとって強い手がかりになることを示しています。言い換えると、脆弱性が公開された瞬間から、悪用を試すまでの手間が下がっています。防御側が「公開から悪用まで数週間はある」と見込む根拠は弱くなりました。

ただし、何でも自動で破れるわけではない
CVE-Bench のように実在のアプリで条件をそろえて測ると、成功率はまだ低い値にとどまります。同じ論文の中でも設定によって数字が変わっており、ベンチマークの成功率は評価条件込みで読む必要があります。

発見の速さは、防御側にも同じように効く
Big Sleep、AIxCC、Anthropic の発表は、いずれも防御側が使った例です。見つかる脆弱性が増えるということは、修正版の公開とパッチの数も増えるということです。適用する側の処理能力が追いつかなければ、「直っているのに当てていない」期間が長くなります。

公開から悪用までの時間はすでに数日単位

Google（Mandiant）の分析では、2023 年に悪用された脆弱性について、公開から悪用までの平均日数（Time-to-Exploit）は 5 日でした。2018〜2019 年の 63 日、2021〜2022 年の 32 日から大きく縮んでいます。同じ分析では、2023 年に悪用が確認された 138 件のうち、およそ 7 割がゼロデイ（修正版が出る前の悪用）でした。

この数字は LLM の影響だけを示すものではありません。ただ、エージェントが CVE の説明から悪用を試せる段階に来ていることと合わせると、月 1 回まとめてパッチを当てる運用では、外部に公開している機器は間に合わないと考えるのが自然です。

期限を「深刻度」ではなく「悪用の証拠」と「届くかどうか」で決める

CVSS の深刻度だけで期限を決めると、深刻度は高いが悪用されていない脆弱性に手が取られ、実際に悪用されている脆弱性が後回しになることがあります。公開されている判断材料として、次の 2 つが使えます。

  • CISA KEV カタログ: 実際に悪用が確認された脆弱性の一覧です。米国連邦機関向けの指令 BOD 22-01 では、2021 年以降に CVE が付いたものは原則 2 週間以内の対応を求めています
  • EPSS: FIRST が管理する指標で、今後 30 日以内に悪用が観測される確率を推定します。2025 年 3 月に第 4 版が公開されました

これに「インターネットから届くかどうか」を組み合わせると、期限の決め方は次のようになります。日数は例で、自組織の体制に合わせて決めてください。

条件 期限の例 考え方
KEV 掲載かつ外部公開 2 日 悪用の証拠があり、攻撃者から直接届く
KEV 掲載（内部のみ） 14 日 BOD 22-01 の原則と同じ
EPSS 0.1 以上かつ外部公開 7 日 悪用の見込みが高く、届く
外部公開 30 日 届くので、月次より遅らせない
その他 90 日 通常の更新サイクルで対応

パッチがまだないものは、期限までに「公開をやめる」「回避策を入れる」を行う、と決めておくのが要点です。ゼロデイの割合が高い以上、パッチ待ちのあいだも期限は進めます。

期限を自動で割り当てる最小例

検出した脆弱性に、上の表のルールで期限と対応を割り当てるコードです。KEV と EPSS の値は、実運用ではそれぞれの公開データから取り込みますが、ここでは検証のため固定値で与えています。CVE 番号は架空の値です。

実行環境は Python 3.13.16 で、標準ライブラリだけを使っています。

from dataclasses import dataclass
from datetime import date, timedelta

# 例として置いた社内ルール（日数は自組織で決める）
RULES = [
    # (名前, 条件, 期限日数)
    ("KEV掲載・外部公開", lambda f: f.in_kev and f.internet_facing, 2),
    ("KEV掲載・内部",     lambda f: f.in_kev, 14),
    ("EPSS高・外部公開",  lambda f: f.epss >= 0.1 and f.internet_facing, 7),
    ("外部公開",          lambda f: f.internet_facing, 30),
    ("その他",            lambda f: True, 90),
]

@dataclass
class Finding:
    cve: str
    asset: str
    published: date      # 脆弱性の公開日
    in_kev: bool         # CISA KEV に載っているか
    epss: float          # EPSS スコア（0〜1）
    internet_facing: bool
    fix_available: bool

def triage(f: Finding, today: date) -> dict:
    name, days = next((n, d) for n, cond, d in RULES if cond(f))
    due = f.published + timedelta(days=days)
    action = "パッチ適用" if f.fix_available else "公開停止・回避策"
    return {
        "cve": f.cve, "asset": f.asset, "rule": name, "due": due,
        "action": action, "overdue": today > due,
    }

findings = [
    Finding("CVE-TEST-0001", "VPN 装置",     date(2026, 10, 12), True,  0.92, True,  True),
    Finding("CVE-TEST-0002", "社内 Wiki",    date(2026, 10, 1),  True,  0.40, False, True),
    Finding("CVE-TEST-0003", "顧客ポータル", date(2026, 10, 9),  False, 0.15, True,  False),
    Finding("CVE-TEST-0004", "顧客ポータル", date(2026, 9, 20),  False, 0.01, True,  True),
    Finding("CVE-TEST-0005", "経理端末",     date(2026, 8, 1),   False, 0.02, False, True),
]

today = date(2026, 10, 15)
results = sorted((triage(f, today) for f in findings), key=lambda r: r["due"])
for r in results:
    mark = "期限切れ" if r["overdue"] else "-"
    print(" | ".join([str(r["due"]), r["cve"], r["asset"], r["rule"], r["action"], mark]))

実行結果です。

2026-10-14 | CVE-TEST-0001 | VPN 装置 | KEV掲載・外部公開 | パッチ適用 | 期限切れ
2026-10-15 | CVE-TEST-0002 | 社内 Wiki | KEV掲載・内部 | パッチ適用 | -
2026-10-16 | CVE-TEST-0003 | 顧客ポータル | EPSS高・外部公開 | 公開停止・回避策 | -
2026-10-20 | CVE-TEST-0004 | 顧客ポータル | 外部公開 | パッチ適用 | -
2026-10-30 | CVE-TEST-0005 | 経理端末 | その他 | パッチ適用 | -

ルールは上から順に評価し、最初に当てはまったものを使います。同じ「顧客ポータル」でも、EPSS の高い CVE-TEST-0003 は 7 日、低い CVE-TEST-0004 は 30 日になります。CVE-TEST-0003 はパッチがないので、対応は公開停止か回避策になります。

期限の起点を公開日にしている点にも意味があります。検出した日を起点にすると、スキャンの間隔がそのまま猶予になってしまいます。KEV への追加日を起点にする運用もありますが、どちらにしても「自分たちが気づいた日」ではなく外部の日付で数えるようにします。

期限を守れる体制にするために

期限を短くするだけでは、守れない期限が増えるだけです。合わせて見直したいのは次の点です。

資産の台帳と「外部公開」の判定を自動化する
上のコードの internet_facing が手作業の判定だと、そこで漏れます。攻撃側のエージェントは公開資産を短時間で調べ尽くすので、外から見える資産を定期的に自分で調べ、台帳と突き合わせます。

管理画面や VPN 装置は、パッチより先に「届かない」構成にする
外部公開の行の期限が最も厳しいのは、届くからです。管理インターフェースをインターネットから切り離せば、その機器は表の下の行に移り、未知の脆弱性に対しても時間を稼げます。

防御側も LLM エージェントで探す
AIxCC の決勝システムは公開が進んでおり、Trail of Bits の Buttercup は GitHub で公開されています。自社のコードや依存ライブラリを、攻撃者より先に同じ種類の道具で調べられる時代になっています。ただし、見つかった候補は人が再現・確認してから扱います。Anthropic の発表でも、報告前に人が検証したとしています。

参考

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?