huhusmang/Awesome-LLMs-for-Vulnerability-Detection · 上手攻略

• 仓库：huhusmang/Awesome-LLMs-for-Vulnerability-Detection
• 链接：https://github.com/huhusmang/Awesome-LLMs-for-Vulnerability-Detection
• 分类：ai（LLM × 软件安全 / 漏洞检测）
• 作者：spark
• 更新：2026-08-22

一、是什么

Awesome-LLMs-for-Vulnerability-Detection 是一个社区维护的精选论文 / 项目 / Agent Skill 索引，专注于"用大语言模型做软件漏洞检测"这个交叉方向。仓库由 huhusmang 维护，README 主表只展示 2025 年及之后的论文，2024 年及之前的单独归档在 docs/papers_archive.md，分类覆盖：

• 论文（Papers）：函数级（function-level）、仓库级（repository-level）、智能体化（agentic）、智能合约（smart-contract）四大场景的检测方法
• 数据集与基准（Datasets & Benchmarks）：从 PrimeVul、VulnGym 到 CVE-Bench 等
• 项目（Projects）：OpenAnt、DeepAudit、AutoCVE、Darkmoon、strix、deepsec 等
• Agent Skills：codex-security（OpenAI）、defending-code-reference-harness（Anthropic）、security-audit-skill（Cloudflare）

README 主表里几乎每一条都带"Paper + GitHub"两列链接，对寻找可复现实现的工程师非常友好。仓库还内置了 arxiv.md 自动抓取工作流，作者说明这个 workflow 重构自 gai4se/LLM4SE，并使用 arxiv Python 库。

二、解决什么问题

"LLM for code"这个赛道很热，但"LLM for vulnerability detection"是更窄、更工程的子集。研究者与工程师进入这个方向会遇到三个典型痛点：

1. 关键词搜索散：论文分散在 arXiv 的 cs.CR、cs.SE、cs.CL，ACL/ICSE/NDSS/USENIX Security 等顶会，以及单独的 preprint。Google Scholar + arXiv 关键词组合（"LLM" + "vulnerability" + "detection"）容易漏关键论文。
2. 论文与代码不对齐：很多论文写了 95% 的方法描述，但 GitHub 链接要么缺失要么是匿名 4open.science，要复现得自己翻 appendix。
3. 场景分类混乱：函数级、仓库级、智能体化、智能合约这四种"漏洞检测"在数据规模、prompt 策略、evaluation metric 上差异巨大；把不同场景的论文混在一起读，会得出错误的"什么方法最好"结论。

Awesome-LLMs-for-Vulnerability-Detection 的解法是人工编辑 + 工作流半自动抓取：作者手动维护主表（确保标题、年份、venue、GitHub 都对齐），同时用 arxiv.md workflow 做每日增量补充。这种"人 + 自动化"混合模式比纯人工 awesome 列表新、比纯自动论文榜准。

特别值得注意的是，agent skill 这一节单独成表——把"LLM × 安全"的产品化方向（codex-security、Cloudflare 的 6 阶段安全审计 skill、Anthropic 的 threat modeling reference harness）显式列出。这是大多数同类 awesome 列表没覆盖的角度。

三、快速安装

仓库本质是只读内容站，没有传统意义的"安装"。常见使用方式：

方式 A：浏览器浏览

直接打开 https://github.com/huhusmang/Awesome-LLMs-for-Vulnerability-Detection ，表格里每条都带 arXiv 链接，点进去看 abstract 和 GitHub。

方式 B：克隆做个人检索库

git clone https://github.com/huhusmang/Awesome-LLMs-for-Vulnerability-Detection.git
cd Awesome-LLMs-for-Vulnerability-Detection

# 用 ripgrep 检索论文
rg -i "smart.?contract" README.md            # 找智能合约相关
rg -i "repository.?level" README.md          # 找仓库级
rg "github.com/vercel-labs" README.md        # 找特定机构的项目

仓库同时提供 docs/papers_archive.md（2024 年及之前），clone 后可以一起检索。

方式 C：本地起一个 arxiv.md 自动抓取

仓库里有 arxiv.md（不是文件而是文档段落说明工作流）；如果你想 fork 后跑自己的"每日 arXiv 抓 LLM4VD 关键词"，可以参考作者说明的代码栈：

# 1. 装依赖
pip install arxiv               # https://github.com/lukasschwab/arxiv.py

# 2. fork 后修改 .github/workflows/ 下的关键词（默认看起来覆盖 cs.CR/SE/CL 中 LLM + 漏洞相关）
# 3. 在 repo Settings → Secrets 加 LLM API key（如果 workflow 还做摘要）
# 4. 启用 GitHub Actions

⚠️ 作者没有公开默认 workflow 用什么 LLM 摘要；fork 后改摘要模型前最好先读 workflow yaml。

四、核心用法

1. 按场景定位论文

仓库的论文主表按时间倒序排列，但没有显式按"函数级 / 仓库级 / 智能体化 / 智能合约"分组。需要在 README 里用 rg 或 GitHub 的搜索框定位：

# 函数级（含 "function-level" 关键词）
rg -i "function.?level" README.md

# 仓库级（含 "repository" 关键词）
rg -i "repository" README.md

# 智能合约（solana / ethereum / solidity / smart contract）
rg -i "smart.?contract|solidity|ethereum" README.md

# 智能体化（agent / multi-agent）
rg -i "agent" README.md

2. 找带开源代码的论文

README 主表的最后一列是 GitHub 链接；用 ripgrep 一次性拉所有 GitHub URL：

rg -o 'https://github\.com/[A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+' README.md | sort -u

⚠️ 抓到的不全是漏洞检测项目的 repo——README 里也可能引用 awesome 自身的相关仓库（如 OwenSanzas/LLM-For-Software-Security 这类综合性 survey）。手动过滤一遍。

3. 跟踪"agent skill"产品化方向

直接读 README 里的"🧩 Agent Skills"小节，三个最有代表性的官方 skill：

• codex-security（OpenAI）：基于 Codex agent 的仓库级漏洞扫描
• defending-code-reference-harness（Anthropic）：threat modeling、scanning、triage、patching 一条龙
• security-audit-skill（Cloudflare）：6 阶段审计 + 并行 hunting agent + 对抗验证

这三个 skill 在仓库里被列入 README，说明它们被作者视为"工业级 reference"，比大多数论文项目更接近生产可用。

4. 看"项目"小节选可执行工具

README 的"🚀 Projects"小节收录了 6 个活跃项目（注意 Stars 与维护活跃度是动态的）：

⚠️ 表中"Darksmoon"我读 README 拼的是 Darkmoon / Dark-Moon（GitHub 仓库名是 ASCIT31/Dark-Moon）——README 里写的是 "Darkmoon" 但仓库名是 "Dark-Moon"，引用时注意两个写法。

5. 历史论文回溯

docs/papers_archive.md 收录 2024 及更早的论文。读这份文件，能搞清楚这个方向"在 LLM 时代之前"就已经有什么样的 baseline（如早期 CodeBERT、GraphCodeBERT 路线）。

五、典型适用场景

• 研究员写相关综述：写 "LLM for Vulnerability Detection" survey 时，用这份列表做 primary source pool，省 1-2 周搜索。
• 企业安全团队选型：找"能用 coding agent 扫自己代码库"的工具时，直接看 README 的 Projects + Agent Skills 两小节。
• CTF / 红队爱好者：找能跑通的开源 pentest 工具（strix、Darkmoon、DeepAudit 都是候选）。
• AI × 安全方向研究生：做新论文时，反向 check 自己的方法 vs 已收录论文有没有 novelty 撞车。
• 工程师想从传统 SAST 转到 LLM 路线：用 repository-level 关键词找起点论文（如 LLM-based Vulnerability Detection at Project Scale, arXiv 2601.19239）。
• 教学场景：老师开"AI × 软件安全"课程时，把这份仓库当成 syllabus 索引。

六、坑与注意

1. 不是"实时"学术综述：作者说明主表只展示 2025+，但仓库没有承诺每日更新。不要假设它能替代 arXiv daily 检索——只是高质量种子集。
2. 年份格式有混用：README 主表里有 2025 和 2026 两列，但部分论文没有标注 venue 缩写，容易被误以为是 arXiv 预印本（实际可能在审稿 / 已发表）。
3. GitHub 链接有效性：README 里很多 GitHub 链接是匿名 / 单字母（anonymous.4open.science/r/CORRECT），这些是审稿期 / preprint 期的"匿名代码"，数月后可能失效。复现前先查 arXiv 最新版。
4. arXiv ID 的 26xx 前缀：本仓库大部分论文 arXiv ID 是 2608.xxxxx 这种格式（对应 2026-08），不是 2403/2501 这种旧 ID。注意别把 2608 当成 2008 年的老 ID。
5. Agent Skills 列表会过期：OpenAI / Anthropic / Cloudflare 的产品都在快速演化，README 里列的可能是 preview / 实验版。生产部署前先看官方 docs 最新版。
6. 拼写不一致：README 里同时出现 "Darkmoon" 和 GitHub 仓库名 "Dark-Moon"，引用时要标注两个等价写法。
7. 2024 及之前论文已归档：2024 之前的论文不在主表而在 docs/papers_archive.md。只看 README 会漏掉早期重要工作（如 CodeBERT、GraphCodeBERT 时代的方法）。
8. 没有标注"代码是否在维护"：有些 GitHub 链接指向的 repo 已经 1-2 年没 commit。点进去看 last commit 时间再决定要不要 clone。
9. 作者没有公开"为什么收 / 为什么拒"：入选标准不透明，可能漏掉某些社区里很活跃但作者没关注的工作。建议配合 Awesome-LLM4SVD 等其它 list 交叉验证。

七、与同类对比

最强差异点：把论文 + 项目 + Agent Skill 三类放一起，并明确标注"工业级 reference skill"（OpenAI / Anthropic / Cloudflare 三家），这是同类列表少有的覆盖面。

八、一句话推荐结论

对 LLM × 软件安全方向的研究者、工程师与教学者而言，这是当下覆盖论文 + 项目 + Agent Skill 三个层面最完整的精选索引——比 Papers With Code 精细、比纯论文 awesome 实用、比官方产品文档独立。如果你要进入这个方向，从这份列表的 2026 年论文 + Agent Skills 三个官方 reference 开始读，能在一周内建立完整的认知地图。