Raddit 仓库级案例卡
建议你仓库级案例只准备 Raddit。它是 Go + React 的 Web 应用，有 22 个 answer-key 漏洞，覆盖面比较全：SQL 注入、路径穿越、任意上传、命令注入、SSRF、IDOR、JWT 问题、敏感信息暴露、硬编码凭据、XSS、CSRF、登录限流缺失等。
1. 一句话版本
Raddit 最适合说明 Agent 和传统扫描器互补：扫描器能抓到 SQLi、命令注入、SSRF、部分 XSS 这类局部 sink，但 Agent 更容易把路由、鉴权、对象所有权、JWT 配置、CSRF、响应字段这些跨文件问题串成安全 case。
2. 数字怎么讲
最清楚的一组数字：
- Agent 最好 run：21/22 answer-key items
- Semgrep Code：8/22
- CodeQL：7/22
- ZAP：3/22
可以这么说：
Raddit 这个仓库有 22 个 answer-key 漏洞。最好的一次 Agent run 在 discovery/triage 层覆盖了 21/22，而 Semgrep 是 8/22，CodeQL 是 7/22，ZAP 是 3/22。这个对比不是说扫描器没用，恰好相反，扫描器在 SQL 注入、命令注入、SSRF 这种局部 sink 上很准；但 Raddit 里很多问题需要理解路由、中间件、当前用户、对象所有权、JWT 配置和前后端渲染，所以 Agent 的仓库级上下文更占优势。
3. 漏洞类型怎么讲
可以按三组讲，不要试图背 22 个。
第一组是扫描器也擅长的局部漏洞：SQL 注入、命令注入、SSRF、路径相关问题、React XSS。它们通常有明显危险 API 或 sink，比如 SQL 字符串拼接、shell command、服务端请求 URL、文件路径拼接、dangerouslySetInnerHTML。
第二组是 Agent 更容易补上的仓库级逻辑问题：IDOR 删除帖子、用户可控 role 导致提权、JWT alg:none、弱 JWT secret、硬编码 admin 凭据、admin debug 信息泄露、password hash 暴露、CSRF。这些问题通常要跨文件看路由注册、认证中间件、handler、model 字段、配置默认值和响应序列化。
第三组是大家都容易漏的缺失型控制：登录 rate limiting。这个不是某一行危险调用，而是“应该存在的控制没有出现”。论文里 Raddit 的 Agent、CodeQL、Semgrep、ZAP 都没覆盖这个点，所以面试里可以主动承认它是一个短板。
4. 为什么选 Raddit
Raddit 好讲，因为它不是只靠一个数字赢。它能体现三件事：
第一，Agent discovery 的覆盖面更广。它从 39 个文件里产生 105 个候选，triage 后保留 70 个 case，最后在 answer-key 上 discovery/triage 覆盖 21/22。
第二，传统扫描器依然有价值。Semgrep 和 CodeQL 的命中少一些，但它们命中的 SQLi、命令注入、SSRF、路径问题通常信号很强，成本也低。
第三，Agent 也有工程代价和误差。Raddit 的 MiniMax run 最后有 1 个 reviewed false positive，实际 delivery 也比理想 delivery 更碎：理想是 9 个 delivery，实际生成 23 个。这说明 Agent 能扩大覆盖，但后续还要优化 triage、合并和交付组织。
5. 面试官可能追问
Q：为什么 Agent 比 Semgrep/CodeQL/ZAP 覆盖多？
我会说主要不是因为 Agent 会神奇识别所有漏洞，而是它看的上下文更像人类 reviewer。比如 IDOR 要看路由、当前用户、数据库查询和对象归属；JWT 问题要看 token 生成、验证、默认 secret、算法选择；CSRF 要看 cookie 认证和状态变更接口。这些不是单个 sink 就能完全判断的。
Q：那传统扫描器是不是没价值？
不是。扫描器很适合做低成本、高确定性的第一层信号，比如 SQLi、命令注入、SSRF、路径穿越。我的理想设计不是替代扫描器，而是把扫描器输出作为 discovery 的输入之一，再由 Agent 做去重、上下文分析、修复和交付。
Q：Raddit 里 Agent 漏了什么？
最典型的是登录 rate limiting。这个点难在它是缺失型控制，不像 SQL 拼接或 shell command 那样有明显危险调用。要发现它，需要主动检查认证流程有没有限流、中间件或防爆破策略。这个也是我后续会优化 discovery prompt 和 checklist 的方向。
Q：Agent 多发现了会不会带来很多误报？
会有这个风险。Raddit 的 MiniMax run 里手工复核后有 1 个 false positive，也有一些 duplicate 或 defense-in-depth case。所以这个系统不能只追求召回，还要靠 triage、analyzer 和 delivery planning 控制 review 成本。
6. 最推荐背的一段
我仓库级案例会讲 Raddit。它有 22 个 answer-key 漏洞，最好的一次 Agent run 覆盖 21/22；对比下 Semgrep 是 8/22，CodeQL 是 7/22，ZAP 是 3/22。这个差距主要来自问题类型：扫描器擅长 SQLi、命令注入、SSRF、XSS 这种局部 sink，但 Raddit 里还有 IDOR、JWT 配置、CSRF、用户 role 提权、敏感字段暴露这些跨文件、跨业务逻辑的问题。Agent 的优势是能把路由、中间件、handler、model 和配置连起来看。不过它也不是完美的，比如登录 rate limiting 这种缺失型控制就漏了，而且 delivery 还有碎片化问题。