36 lines
4.3 KiB
Markdown
36 lines
4.3 KiB
Markdown
---
|
|
title: LLM Assisted Vulnerability Research
|
|
created: 2026-07-02
|
|
updated: 2026-07-02
|
|
type: concept
|
|
tags: [llm, agent, security, quality, workflow]
|
|
sources: [raw/articles/devansh-llm-vulnerability-research-2026.md]
|
|
confidence: 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 として扱う。
|