FFmpeg的维护者最近在 Twitter 上开火，公开指责 DeepMind 报告的那些漏洞——他们称之为“AI 产出的垃圾报告”。引发争议的焦点，是报告中自带的披露时间线，以及报告者强加给FFmpeg的修复压力。这件事迅速引起了轩然大波。

支持谷歌的一方通常会抛出熟悉的论调：谷歌发现并负责任地报告这些项目的漏洞，是在做公共服务，让项目得以修补，简直是拯救了整个行业。

FFmpeg的反驳则很直接：光提 Bug，不给补丁（Patch），就是没价值。这只会给社区的志愿者白白增加工作量。这些志愿者大多是些凭着爱好，努力让 90 年代老旧编解码器工作的逆向工程宅，他们可不是专门写企业级安全代码的。他们从没同意承担这种安全支持义务。

维护者们认为，面对发现的大量漏洞，以及大公司要求“立即修复”的施压，极大地打击了他们的热情。最糟糕的是，这种压力已经导致至少一位重要的社区成员退出了项目。从项目维护能力的角度来看，这些漏洞报告带来的反而是负面效应。

维护者们希望漏洞研究人员能花更多时间协助修复，而不是只忙着发现漏洞。他们不认为谷歌是善意的：谷歌在意的只是如何把 DeepMind 的漏洞发现工具吹嘘得更厉害，好卖给企业客户，根本不是真心想让FFmpeg更安全。

我个人很喜欢看老技术宅在 Twitter 上掐架，难得有机会围观。现在，我们也来加入讨论，贡献一点看法吧。

我之前就提出过：发现漏洞本身不产生价值，只有修复才算数。如果你的修复能力已经饱和，却还要投入资源去发现更多漏洞，那回报率就是负的。

大多数的漏洞研究人员——无论公司实体还是漏洞赏金猎人——都不是什么“善意的 Bug 发现者”。这不能怪个人，而是激励机制在驱动：它只奖励研究员能发现多少 Bug，能发多少篇博客。

这个问题在 LLM（大语言模型）热潮之前就存在，而对于开源软件（OSS）维护者来说，现在情况变得更糟。就连cURL的维护者都快被逼疯了。

我们这些运营公开漏洞赏金项目的“苦命人”，每天都在处理这些问题。我敢肯定，我的漏洞赏金平台供应商现在肯定后悔签下了这场“垃圾报告盛宴”之前的长期分流合同。

所有人都快被报告淹没了。无论是谷歌、其他厂商，还是第 98 个发垃圾邮件的漏洞赏金骗子，提供更多报告，并不会增加任何价值。他们只会夺走开源维护者工作中的乐趣。

这个问题很难解决，我们在此也无法提供方案。不过，我乐见业界的风向正在转变，不再将外部漏洞披露视为一个毋庸置疑的“善举”。

制造“痛苦噪音”的不只是谷歌、安全厂商和发垃圾邮件的漏洞赏金猎人。内部安全团队也是帮凶。

安全工程师普遍认为自己的价值在于发现问题，并把精力集中于此。他们惯常的工作流程，是以一张 JIRA 派单告终，附带危言耸听的严重性（Severity）和 SLA（服务等级协议）警告，把报告扔给工程团队去处理。修复，成了开发团队的活儿。

很多公司甚至有整个团队专门负责“漏洞发现”，即使他们的安全问题待办列表（Backlog）早已堆积如山。那些最成功的安全供应商，倾向于关注识别尽可能多的问题，并集成简易的 JIRA 接口，而不是真正去修复。

如果运气好，我们提供的重现步骤会详细清晰。如果表现得特别有帮助，我们或许会提供一些修复建议，而不是只抛下一句“参数化你的查询吧，哈哈”（parameterize your queries lol）。但即使在最佳情况下，你也只是在给团队扔去数小时、数天甚至数周的工作量，让它去与其他所有待办事项竞争，其中很可能还包括了其他好几个安全问题。

我们对修复本身的贡献微乎其微，我们只是告诉别人他们有问题。我们偷走了他们的工作乐趣。

我们为这种现状找到了各种借口：

• 很难理解一个项目的具体背景，让开发团队自己处理会更快。
• 很多安全工程师缺乏软件工程专业知识，这让他们感到压力。
• 此外，开发团队需要学习如何编写安全代码，修复问题能帮助他们学习。他们需要体会到自己制造问题的痛苦；如果别人帮他们修复，他们只会继续制造问题！

这些话，在某种程度上是对的。这些是需要解决的难题。但这并非现状存在的真正原因。

我们不喜欢修复这些问题，原因和开发人员不喜欢一样：修复工作枯燥乏味，它不直接影响营收，不计入我们的 KPI，在简历上听起来也不够酷。

安全工程师最常见的抱怨是：“我只想发现问题，不想修复。那才是我觉得有趣的部分！”既然觉得不有趣，我们就会回避。我们围绕着“发现的问题数量”来制定指标，这样就能通过拉高燃尽图（burndown chart）来获得晋升。

与此同时，我们把这些漏洞燃尽图变成了开发团队的问题。那 9001 个我们“好心”找到的漏洞没修完，都是他们的错。那些懒惰的开发人员！

对于解决“有趣的问题”来说，这是一种极好的现状。但这并不能增加真正的安全价值。

这是一个黄金法则：在漏洞被修补并部署上线之前，我们没有降低任何风险。

待办问题列表不断增长，意味着我们在浪费时间发现更多问题，而非降低已知的风险。因此，以衡量问题发现数量为主的 OKR、KPI 和指标，都是安全项目的虚假指标；它们不增加任何安全价值。

我们真正要做的是：

• 将指标与安全价值交付挂钩，而非问题发现。
• 与利益相关团队积极协作。
• 将人力资源集中在直接修复问题的构建者（Builders）身上。
• 将厂商预算投入到问题修复上。
• 不断提醒自己：这一切都是值得的。

1. 将指标与价值挂钩

大多数安全指标最终都与“发现率”挂钩，并将“缓解率”（及成本）抛给了其他团队。我本可以嘲笑那些推广虚假指标的厂商，但尴尬的是，MITRE 也在这么做。这种做法将修复的所有权（以及确保组织安全的责任）从安全项目本身转移到了利益相关团队。

前 Google Cloud CISO 菲尔·维纳布尔斯（Phil Venables）在他的理想指标体系中排除这些指标是正确的。过度关注虚假指标，只会给下游团队带来不对称的工作负担。

如果我的待办列表（无论是漏洞、错误配置、渗透测试/红队报告，还是安全设计工单）过长，这强烈表明我的安全项目将过多的精力投入到了问题发现，而非修复上。我只是在甩锅，没有增加价值。

与“已交付的安全价值”挂钩的指标应包括：

• 已修复的漏洞总数，而非报告总数。
• 已纠正的错误配置、代码异味（Code Smells）和 Bug 数量。
• 已部署的安全框架、已完成的代码变更、已构建的服务控制策略或 Terraform 模块，以及任何能主动消除未来一整类问题的措施。

关键在于将指标与修复率对齐。这能让安全项目继续掌握价值交付的所有权，并激励我们寻找规模化修复问题的方法，或赋能利益相关团队来修复。安全项目应该因修复率的提高和实际风险的缓解而获得奖励，并在修复率下降时被问责。

2. 积极介入（Take an Active Hand）

为了驱动这些指标，我们需要积极介入。在我们的待办列表接近清空之前，我们应该将大部分精力集中在问题修正上。虽然我们需要帮助团队建立风险所有权，但这并不意味着我们可以彻底放弃自身的责任。

你不需要自己去修补每一个依赖项，也不需要亲自修复每一个 Bug Bounty 报告的根本原因。我的意思是：修复率是你的责任，是你的主要指标，你个人需要采取措施来提高它。具体方法取决于你的组织情况。很多人都分享过这里的选项：自动化补丁（Auto-patching）、安全护栏（Guardrails）、铺设好的道路（Paved Roads）、有用的可见性，等等。甚至可以尝试引入 AI 来解决。

重点是，我们需要审视我们发现的问题数量，找出最佳的减少方法，然后他妈的去把它构建出来（go fucking build it）。一个安全项目的价值在于其集中可见性和执行能力。

但，是的，你应该卷起袖子，自己动手修复一些东西。这能增加实际价值，当我们亲自动手时，我们的利益相关者会更加尊重我们。

3. 招聘构建者，主动建设

为了构建事物，我们需要将人力集中在有能力构建的人身上。我们需要具有安全意识的软件工程师，他们能构建内部服务、框架、构建工具、Terraform，或任何所需的其他工具。这意味着要招聘能写代码的人。是那种能开发和拥有生产服务的人，而不是只会做代码审查或写几个“感觉不错”的 Python 脚本的人。

我不是唯一一个主张让更多软件工程师转做安全工程师的人。这是一个普遍的呼声！说“雇用他们”是容易的，难点在于找到合适的人。

我将有几篇文章讨论招聘，但这里先给出一些建议：

• 招聘软件工程师，然后培训他们的安全知识。安全知识本身并没有那么难；关键是要有“在意安全”的激励机制。你可以提供这种激励！运营导向的软件工程师很棒，他们知道如何管理基础设施，他们也同样乐于抱怨开发人员，而且通常非常感激能摆脱 24/7 的随叫随到，因此相对容易招聘。现在的程序员市场并不火热，所以招人并不难。
• 如果你公司里有具备安全意识，但不在安全团队工作的软件工程师，把他们挖过来。或者反过来做：给工程团队预算，让他们招聘专注于安全工作的嵌入式软件工程师。
• 推动现有安全工程师提升技能。明确你需要的能力，并允许候选人花时间磨练他们的代码筛选能力。我们需要的开发技能通常也不是那么难，我发现稍加推动，人们为了得到或保住工作，能很快提升技能。
• 保持耐心。最终会找到合适的人。

4. 购买修复，而非问题

同样，我们希望将厂商预算投入到能修复问题的工具上，而不是发现问题的工具上。对于大多数安全项目来说，这是一个巨大的转变，原因如上：实际修复问题很困难，即使通过厂商来修复，也需要大量的部署和设置工作，并且解决方案的调整能力较差。相比之下，买一个无代理扫描器，扔出 5000 张 JIRA 派单，然后宣布季度工作完成，要容易得多。但只要我们努力，就能实现转变。

首先，你需要满足基本的扫描需求：一个经过分流的 Bug Bounty 项目、一个廉价的 CSPM（有很多开源选项）。开启GuardDuty、Falco/Tetragon，或者使用一些 Sigma 规则与日志存储或 Grafana 配合来构建一个 SIEM。在关键位置撒上金丝雀令牌（canary tokens）。安全代码检查工具（Linters）和一些 LLM 提示对于代码扫描来说，效果也惊人地好。别忘了购买 Burp Suite 许可证。这些不应该花很多钱。

然后，我们可以将预算的绝大部分花在主动降低风险的工具上。这可能包括让自动化补丁更容易实现、为基础设施配置添加安全护栏，或部署提供 Web 过滤、WAF 和DDoS 防御的边缘安全解决方案。你可能已经拥有了带有托管响应的 EDR。市面上有一些基于 Agent 的安全公司可以尝试，尽管我个人尚未找到一个真正值得投入的。

抱歉，建议不多。大多数厂商细分市场都集中在扫描、测试、可观测性或态势管理上。在短期 POC（概念验证）中展示“价值”很容易：你只需部署扫描器，然后展示仪表板。而真正有价值的工具必须深入地与现有系统交互来提供保护，这使得部署难度大得多。Wiz 的 POC 可能只需一周，而我部署 Cloudflare 则需要 3 到 12 个月。

我们陷入了一个“鸡生蛋，蛋生鸡”的困境。在我们停止关注“可见性”之前，市场不会提供“修复工具”；但在厂商提供这些更好的工具之前，我们又无法将需求转向它们。不幸的是，需求的改变可能需要首先发生。

在等待市场变化期间，我们可以：

• 将厂商预算转为人头预算，招聘构建者。这可能会涉及会计和物流问题，但通常是可行的。
• 使用厂商预算赞助开源项目。找到能真正修复问题的开源工具更容易。投资回报率巨大：相对较小的金钱或时间投入，就能获得维护者大量的时间，并影响项目路线图。我（好吧，我的公司）赞助了zizmor，现在它有了修复模式，太棒了。这是我们今年花得最值的钱。你不仅可以在停止赞助后继续使用该工具，还可以在你下一份工作中，立即、免费地使用它。

我刚才建议的任何一项，在短期内都不容易。

交付价值的指标更难达成。积极介入需要技术能力更强的团队，以及更大的精力投入来更新技能树，以应对技术变化。招聘和培训那些技术型构建者需要更多时间。市场上好的“修复型”厂商不多，所以更难找，带你去吃大餐的销售代表也少了。完成任何项目的最后一英里工作都是枯燥乏味的。

传统的安全团队运营模式无疑更轻松。但交付价值是困难的。正因为如此，它才具有价值。

然而，这不仅仅是为了你的组织好。你个人也会更快乐。宜家效应（IKEA effect）是真实存在的。修复问题、眼看着漏洞消失，并且知道它们不会再出现，这种反馈回路比管理分配给其他团队的派单要更有成就感。

正是这种对重复性、低回报工作的专注，导致了网络安全行业的倦怠危机。你今天清理了 10 个工单，知道明天还得清理 10 个，永远如此，这没有任何奖励感。当我们感到有能力解决每天面临的问题时，我们的工作满意度才会更高。