4.3 KiB
title, created, updated, type, tags, sources, confidence
| title | created | updated | type | tags | sources | confidence | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| LLM Assisted Vulnerability Research | 2026-07-02 | 2026-07-02 | concept |
|
|
medium |
LLM Assisted Vulnerability Research
LLM assisted vulnerability research は、LLM / coding agent を「全部の脆弱性を探して」と広く投げるのではなく、攻撃面・信頼境界・不変条件を小さく切り、証拠で潰しながら脆弱性を探す作業様式である。Devansh の記事は、Parse Server、HonoJS、ElysiaJS、harden-runner、BullFrog、Better-Hub などで見つけた複数の脆弱性を例に、LLM の価値は巨大な AGENTS.md や長い checklist ではなく、薄い threat model と検証 loop にあると整理している。^[raw/articles/devansh-llm-vulnerability-research-2026.md]
この論点は agent-harness-engineering の「context をどう狭く保つか」と、scrutineer / strix の human-gated security workflow に近い。違いは、Scrutineer や Strix が道具・workflow として外形化しているのに対し、このページの焦点は人間 researcher が Codex / Claude などを使う時の探索単位、prompt frame、verification budget の配分にある。
実務上のパターン
- 広すぎる依頼を避ける:
find all vulnerabilitiesは threat model がなく、generic CWE 的な観測や到達不能な理論上の問題を増やしやすい。まず「誰が、どの入口から、何を越えようとするのか」を短く固定する。 - 小さな threat model を作る: 過去 CVE、security advisory、設計文書、既知の bug class から、その project が過去に失敗した境界を抽出する。Parse Server なら key type / authorization boundary、HonoJS なら JWT / JWKS algorithm handling、harden-runner なら GitHub Actions runner の outbound egress が焦点になる。
- thin slice に分割する: auth、session、request parsing、file upload、deserialization、sandbox boundary、plugin boundary など、実際の攻撃面に対応する小さな単位で読む。巨大 context へ全体を詰めるより、slice ごとに entry point、sensitive sink、guard、attacker-controlled input を確認させる。
- 不変条件を破らせる:
only admins can call X、JWT issuer/audience/algorithm must be pinned、read-only key must never write、egress controls must see every network pathのように、コードが守るべき条件を列挙し、各条件を攻撃者が破れるか調べる。 - 検証に token と時間を使う: 「モデルが言った」段階で止めず、unit / integration test、PoC request、crash reproduction、sanitizer build、fuzzer、static/invariant check で、成立・不成立を証拠化する。ここは ci-cd-runtime-security の実行時証跡や ai-evaluation-infrastructure の評価 loop と同じ発想である。
Context 設計の教訓
記事は、over-scaffolding、bloated AGENT.md / SKILLS.md、過剰な事前計画が、脆弱性探索では逆に needle-in-the-haystack 問題を悪化させると主張している。これは長文 context の中央にある重要情報が拾われにくいという context rot / lost-in-the-middle 系の問題と接続する。
実務的には、安定 scaffold は 1 ページ程度の threat model、不変条件、crown-jewel 機能に抑え、残りの budget は focused slice audit と verifier loop に使うのがよい。これは agent-oriented-cli-design の「道具が少ない文脈で正確に使える」設計ともつながる。
Prompt frame と安全上の注意
記事には「脆弱性があると仮定する」「exploit を書かせる」「auditor ではなく adversary として考えさせる」など、LLM の探索圧を上げる prompt frame が並ぶ。防御研究の中では有効なことがある一方、攻撃化も容易なので、実行対象、権限、ネットワーク境界、報告先、人間 gate を固定する必要がある。
Yuta の wiki では、この種の知見は無制限な攻撃手順ではなく、ai-agent-command-safety、ai-agent-enabled-cyberattacks、ai-agent-identity-security と並べて、agent を防御研究に使う時の boundary design として扱う。