作者发现，仅凭安全漏洞的传闻，攻击者就能利用AI代理快速定位并利用漏洞。这迫使开源社区必须改变传统的安全响应流程，因为漏洞修复前的保密措施已不再有效。

好的，这是根据您的要求，对原文进行中文重述和精简后的版本：

标题：如今，仅凭一个漏洞的传闻就足以找到安全漏洞

核心观点： 作者发现，在开源软件安全修复流程中，仅仅关于某个安全问题的“传闻”或模糊信息，就足以让攻击者（或自动化系统）快速定位并利用漏洞。传统的安全保密流程（如私下修复、发布公告）已失效，因为攻击者可以利用AI工具，根据一个宽泛的方向（如一个PR、一个邮件列表问题）自行生成漏洞利用代码。

具体事件： 作者为OCaml的cohttp库发布了一个安全补丁，修复了一个路径遍历漏洞。在公开修复的PR后仅几分钟，作者的服务器日志中就出现了针对该漏洞模式的探测。更糟糕的是，作者发现，只要知道漏洞的大致类型（如“路径规范化问题”），就能让自己的AI代理在不到一分钟内生成漏洞利用代码，并在本地服务器上验证成功。

关键时间线变化： * 过去：漏洞从发现到被利用平均需要63天（2018-19年）。 * 现在：平均利用时间已变为“-7天”，意味着漏洞在被公开修复前就已经被利用。 * 案例：一个漏洞从公告发布到首次被尝试利用仅需9小时，即使没有公开的概念验证代码。

对开源维护者的挑战： * “漏洞经济学”已改变： 瓶颈从“发现漏洞”转移到了“修复漏洞”。AI可以大量生成漏洞利用代码，但维护者的验证、分类和发布能力并未同步提升。 * 资源不均： 大型科技公司（如Google）可以构建快速更新机制（如Chrome的每周安全更新、动态补丁），但小型开源项目（如OCaml）缺乏这种基础设施。同时，开源维护者难以获得前沿AI模型（如Claude Fable）的访问权限，而这些模型已被证明能高效生成漏洞利用。

可能的应对方案：

1. 超级私密的补丁开发： 在完全脱离AI监控的私有环境中开发补丁。但GitHub的临时私有分支功能存在限制（无法运行CI、只能合并一个PR等），且无法解决讨论过程中的信息泄露问题。
2. 放弃保密，持续发布： 快速公开修复问题，并通过更好的自动化工具持续发布更新。这需要改进跨生态系统的包管理、更好的扫描工具（如Scrutineer）以及更稳健的质量控制基础设施。
3. 协议层的主动防护： 在补丁正式发布前，先部署临时的缓解规则（如“规范化URL中的百分号编码路径分隔符”）。这类似于云服务商（如Cloudflare）为Log4j漏洞部署的托管规则。但开源社区缺乏分发此类规则的机制。

结论： 作者认为需要结合以上三种方案。短期内，需要为开源贡献者建立轻量级的信任网络，并加强对开源打包、持续发布和分类机制的研究。同时，作者也提出了两个新的研究课题，旨在探索如何通过防御性测试平台和运行时强制规范来应对这一挑战。

以下是对评论内容的总结，涵盖主要观点、论据及不同立场，并保留关键引用：

1. 开源维护者面临的安全压力激增
- 评论1（nickcw）指出，AI工具导致安全披露数量暴增（“In the first 10 years... about 20 security disclosures... over 40 in the last month”），且CVE分配延迟（“3-4 weeks”），维护者需投入大量时间处理。
- 评论9（stephbook）补充，部署和更新流程本身存在瓶颈（“Who updates their software stack within 10 minutes?”），供应链攻击风险使自动更新不可行。

2. AI降低了漏洞发现门槛，但并非全新现象
- 评论2（bri3d）认为，AI只是将传统漏洞挖掘方法规模化（“Backing exploit PoCs out of patches... is a practice as old as vulnerability research”），但民主化后导致低技能攻击者激增。
- 评论5（zingababba）强调，AI已能通过抽象概念（如“talk abstract”）直接发现漏洞，甚至“undersells the current reality”。

3. 软件质量的根本问题在于“意愿”而非技术
- 评论3（godelski）批评行业重速度轻质量（“My bosses just want speed... we’re pushing out bugs faster and faster”），认为AI修复能力再强也无法解决“will to fix things”的缺失。
- 评论7（petesergeant）讽刺性建议，可虚构漏洞传闻让AI“发现”以规避责任（“just tell the agent that one exists, even if it doesn’t”）。

4. 技术解决方案的局限性
- 评论4（loeg）指出，内存安全语言（如Rust）能减少漏洞，但无法解决现有项目或逻辑错误（“Sure, it does not help existing projects”）。
- 评论10（jameshart）质疑AI发现漏洞的“命中率”，认为虚假传闻也可能诱导AI找到真实漏洞（“probably a reasonably high chance of it finding one”）。

5. 对AI时代安全生态的反思
- 评论6（Tomte）以“automated Thomas Pornin”比喻AI自动化漏洞挖掘的讽刺性。
- 评论8（saghm）提出，未来可能通过散布虚假漏洞传闻来操纵攻击者（“start rumors about vulnerabilities... plausible deniability”）。

总结：评论普遍认为AI加剧了安全维护负担，但核心矛盾在于行业对速度的追求压倒质量意愿。技术手段（如内存安全语言）和流程优化（如快速部署）只能部分缓解问题，而AI的“民主化”效应可能催生新的攻防博弈策略。