加载失败
这篇讨论围绕一篇题为《Vulnerability Research Is Cooked》的文章，核心判断是 frontier LLM 和 coding agent 会把漏洞发现、复现和 exploit 生成的成本压到很低。评论里反复拿 fuzzers（模糊测试器）、static analysis（静态分析）和 Claude Code（Anthropic 的 coding agent）做对比，争论模型到底是在真正理解代码，还是在大规模 pattern match。有人引用 Nicholas Carlini（知名 security researcher）的演示、Anthropic 的红队写法，以及 curl 事件来区分“海量 slop 报告”和“可复现 exploit”。话题还延伸到 CI、补丁发布速度、sandbox/Firecracker（AWS 的微虚拟机运行时）/seccomp（Linux 系统调用过滤器）这类隔离技术，以及 memory-safe languages 和 Trusted Types 等长期防线。
许多人认为，如果模型能持续找出漏洞，真正限制安全性的不是发现能力，而是修补与复核能力。代码库里本来就有积压的 bug，QA、release cycle、回归风险和多代码库并行维护都会拖慢修补。还有人指出，很多软件根本不会自动更新，所以即使在 CI 里把新漏洞扫干净，已部署系统也未必能及时受益。
另一组评论强调，如果攻击和防守都能用同样的模型，防守反而可能更占便宜。因为真实攻击常常依赖利用链，攻击者要把整条链都找齐，而防守者只要堵住其中一个脆弱点。有人主张把“跑 agent 找漏洞”直接放进 CI，甚至让新模型先给防守方，用来在发布前批量拦截问题。
怀疑者认为，这个结论更多来自少量示例和厂商叙事，缺少足够硬的数据。之前的模型漏洞报告大量是 slop，新的流程也仍然需要第二步去验证 exploitability，否则只是看起来像漏洞的噪音。还有人指出，当前成功案例很可能主要靠 pattern matching、历史补丁和已知缺陷模式，而不是已经把安全研究“自动化完成”。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
支持者则反复举例说，frontier models 已经能在开源代码里找到可复现的真实漏洞，甚至直接写出 exploit，而不只是 POC。评论里提到用 CTF 式提示、反编译结果和明确的目标约束，模型能挖出 heap/stack 问题、blind SQLi 等具体成果。也有人强调，这类能力的关键不只是“会说”，而是能在大规模代码库上持续产出可验证结果，速度和吞吐都比过去的人工流程高很多。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
不少评论把未来理解为角色迁移：研究者会更多变成 harness、prompt、验证链路和多工具编排的设计者。有人提到 symbolic execution、fuzzing、测试和安全注释/对抗性测试会和 LLM 结合，而 formal verification 只在少数场景里值得付出成本。另一条线是更偏防御的架构选择，比如 memory-safe language、sandbox、Trusted Types、iframe 隔离和 seccomp 之类的限制，会因为 LLM 帮忙写样板代码而更容易落地。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
0day/zero-day: 尚未公开或尚未修补的漏洞，攻击者可直接利用。
exploit chain: 把多个漏洞或步骤串联起来完成一次可行攻击的路径。
fuzzer/模糊测试: 通过大量变异输入寻找崩溃、异常或可利用缺陷的工具。
static analysis/静态分析: 不运行程序，直接分析源码或中间表示来找问题。
formal verification/形式化验证: 用数学方法证明程序满足特定安全或正确性性质。
memory safety/内存安全: 避免越界、Use-after-free、悬空指针等内存错误。