加载失败
这场讨论围绕一篇题为“Vulnerability Research Is Cooked”的文章展开，背景是 Anthropic（做 frontier model 的 AI 公司）公开的 0-day hunt 结果，以及安全研究员在播客/演讲中展示的案例：让 Claude Code（Anthropic 的 coding agent）扫描 source tree 并生成可用 exploit。评论者把它放在 fuzzers、static analysis、symbolic execution 这些传统漏洞发现工具的脉络里比较，也提到 curl（广泛使用的命令行 HTTP 客户端）曾被大量 AI slop 漏洞报告淹没，说明“自动找洞”先会带来噪声问题。讨论还延伸到防守侧能否把同样的模型放进 CI pipeline、patch review 和 verification，以及 memory-safe 语言（如 Rust）、sandboxing（如 seccomp、Firecracker）和 formal verification 是否会因此重新变得划算。
支持者认为 frontier LLM/agent 已经能把漏洞研究从少数专家的手工搜洞，变成可批量执行的流程。评论里多次提到把 Claude 或其他 agent 直接指向 source tree、让它遍历代码并生成 exploit，甚至能在 Ghost 上做出 blind SQL injection 的可用 exploit，而不只是模糊报告。有人还分享了在 CTF、decompilation 和 heap/stack bug hunting 中的实际体验，说明模型在已有上下文下确实能找出真实问题。也有人认为一个人配合 Claude 就能在一天内清空原本要排很久的漏洞队列。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
另一派认为如果攻击者能用 LLM 自动找洞，防守方也能把同样的能力接进 CI、PR review 和补丁验证。因为很多 exploit 依赖多个漏洞串链，防守方只要修掉链条里的弱点，就能把 zero-day 降级成中低危问题，甚至在提交阶段直接阻止它进入代码库。还有人指出，大厂和主要 lab 可能会先把更强的模型交给防守方，或者让它们先用于新补丁回归测试，从而压缩攻击窗口。这个视角下，真正改变平衡的不是“能不能找洞”，而是“谁能更快把洞堵上并验证”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
不少评论把焦点放在发现与修复的非对称性上：真正卡住的常常是 remediation，而不是找到 bug。有人指出 bug tracker 往往并不空，带 reproducible test case 的漏洞也可能因为资源不足长期不修，尤其是安全修复还会受 release cycle、QA 和回归风险限制。另一些人强调普通 bug 和高危 vulnerability 不是一回事，浏览器里常见缺陷不等于能删硬盘、读内存或远程执行的高危问题。也有人总结说，攻击者只需要一次成功，而防守者要长期持续成功，这种不对称始终存在。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
怀疑者认为这波结论更像是基于少量 demo、播客和行业 hype 的外推，而不是扎实数据。有人提到 Anthropic 的 0-day hunt 里，模型很多时候只是根据 change history 和常见弱模式做 pattern-match，真正的 code analysis 并没有展示出“魔法般”的能力。curl 项目被海量 AI slop 漏洞报告轰炸，也被拿来说明“先把噪声过滤掉再谈能力”；否则只是把旧式 spam 自动化了。还有人补充说，当前成果很大程度来自规模和吞吐，而不是模型本身已经比 fuzzers 或静态分析聪明很多。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
反对“漏洞会被一扫而空”的人强调，修一个 bug 往往会引入新的 bug，代码不会自己收敛到完美状态。评论里有人举例说 agent 在重构时会继续堆 special case，只有人类主动提出设计决策，才会去做 DRY 或结构调整。也有人把 liability 放在中心：最终要有人对客户、合规或法院负责，不能只说“agent 知道”就结束。这个分支的共同点是，AI 也许能做大量 grunt work，但不能替代所有工程判断。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
还有一条更长期的路线是把安全问题前移到语言和工程体系本身。评论里反复讨论 Rust、C/C++、Zig、SPARK Ada、formal verification、static analysis、dynamic analysis、fuzzing 和 test generation，并设想把这些工具和 LLM 结合起来做大规模验证。也有人提到 `# SAFETY:` contract、Trusted Types、iframe sandboxing、seccomp 和 Firecracker 这类机制，认为减少攻击面比单纯找漏洞更有效。甚至有人提出做 X-to-safe-lang translators，让 Python 和 JavaScript 先由模型生成，再转换到更安全的目标语言。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
一些评论提醒，真正的限制不只是技术，而是预算和部署环境。有人说很多团队连买一台二手 ThinkPad 都会犹豫，更别说给每个仓库烧 token 去跑大规模漏洞搜索。还有人指出大量 legacy software 并不会自动更新，closed source、embedded 和 on-prem 环境也让修补速度远跟不上发现速度。这个角度下，即使 LLM 能显著提高发现率，现实中的防守能力仍可能被采购、运维和发布节奏拖住。
0-day / zero day: 尚未公开披露、通常也还没有补丁的漏洞，能被直接利用。
exploit chain: 把多个漏洞串联起来形成完整入侵路径的攻击方式。
fuzzing: 向程序喂入大量变异输入，寻找崩溃、异常或可疑行为的测试方法。
static analysis: 不运行程序，直接分析源码或字节码来找缺陷的技术。
formal verification: 用数学证明软件满足规格的安全/正确性方法，成本高但理论上更强。
memory safety: 防止越界、use-after-free 等内存错误的特性，常被视为安全软件的重要基础。
sandboxing: 把程序限制在受控环境中，降低漏洞被利用后的影响范围。