想了解为什么大多数企业安全团队不应盲目追随AI热潮来自行构建复杂的安全工具，而应专注于提升日常工作效率的内部生产力工具吗？从专业技能缺口到总拥有成本，再到合规与责任风险，这些关键因素将重新定义安全团队在AI时代的角色与优先事项。

本文译自 There’s only one kind of tool security teams should be building with AI^[1]

安全团队应利用 AI 构建的工具只有一种

我不太确定过去一年里我在社交媒体（尤其是在 LinkedIn 上）做了些什么，但最近我的信息流中充斥着安全从业者构建各种很酷工具的帖子。围绕 LLM 的兴奋感让人们觉得现在任何人都可以成为产品开发者，这意味着安全团队可以自行构建自己的产品。

碰巧的是，许多认为 AI 将推动企业内部构建安全工具而非从供应商购买的人是我的朋友。他们聪明且深思熟虑，我只是恰好尊重地不同意他们的观点。在这篇文章中，我将解释为什么我不同意他们的看法，以及为什么我们离企业开始大规模构建自己的安全工具的时代还很遥远。同时，我也确实认为安全团队应该在内部构建某种特定类型的工具（但这些工具并不能真正替代网络安全供应商）。

大多数企业不会（也不应该）构建自己的安全工具的几个简单原因

构建产品所需的专长

大多数企业不会构建自己的安全工具的首要原因是缺乏工程专业知识。在一个许多人声称软件可以自己编写的世界里，这听起来可能有悖常理，但请听我说。在成为一名创始人之前，我曾多年担任产品负责人，亲眼目睹过很多次写代码和构建功能性产品之间的巨大差异。能够在真实的企业环境中运行的软件并不是一些简单的 CRUD（创建 – 读取 – 更新 – 删除）应用。安全工具尤其需要深厚的领域知识、架构严谨性、性能优化、边界情况处理，以及在复杂异构环境中运行的能力。Claude Code 并不能免费提供这些能力。

AI 让写代码变得非常快速，但它也让系统思维和架构设计等技能变得更加重要。AI 不会神奇地赋予企业多年来对网络、身份模型、日志管道、合规性细节或操作流程的深刻理解。这种专业知识仍然需要来自某个地方，而大多数公司并没有资深工程师闲着等待重新发明安全供应商已经花费十年时间完善的东西。

我认为 AI 将加深以工程为中心的安全团队与其他团队之间的差距。如果你是一家类似湾区风格、以产品驱动的公司，并且已经有强大的安全工程师在构建内部工具，那么 AI 将极大地放大这一点。它将让你的团队更快地制作原型、更快地构建内部工具、自动化更多工作流程等等。如果你在像 OpenAI、Anthropic、Google、Airbnb、Canva、Figma、Notion、Uber、Reddit 或 Discord 这样的公司工作——这些公司的 DNA 是工程驱动的——你应该 100% 利用 AI 来构建比以往更多的东西。对于这些公司来说，我的朋友 Frank Wang 是对的^[2]，他们将在内部构建大量工具。

对于世界上的其他公司来说，如果昨天构建内部安全产品还不现实，那么 AI 不会神奇地让明天变得可能。那些没有工程人才的公司不会因为现在能负担得起的三名 SOC 分析师有了 Claude 就突然开始构建自己的工具。昨天受到大量监管压力的公司今天肯定不会看到这种压力减少。我可以继续举这些例子，但这不是重点。AI 会扩大能够构建安全产品的公司比例吗？肯定会。如果让我猜，我认为这个比例会从 1-2% 增长到 4-7%，但不会达到 70% 甚至 30%（这些数字是我随便说的，没人有确切数据），但我敢打赌实际数字是个位数。

所有这些让我认为，虽然有些安全工具确实可以在内部构建，但安全团队不太可能构建那些技术复杂、需要大规模运行、处理大量数据、需要代理等的工具。

保护公司所需的专业知识

如果找到工程人才已经非常困难，那么再想想找到资深安全人才有多难。关于所谓的“网络安全人才短缺”有很多讨论，但声称安全领域过度饱和的人和声称我们需要 400 万（或现在的任何数字）安全工程师的人都错了。我多年前就解释过实际情况^[3]。其实很简单：网络安全领域有太多人寻找入门级工作，而资深专业人士却很少。

深入了解检测工程、事件响应、云安全与工程、身份（我是指深入理解——比如能够手动找到攻击路径）、网络漏洞利用、合规要求和对手行为的人极其稀少。大多数安全工具，无论是专注于预防、检测、响应、修复还是恢复，本质上都是“编码”了少数高度专业化研究人员和工程师的专业知识，然后将这些知识分发给数百或数千名客户。从某种意义上说，安全供应商将非常有限的专业知识工业化，将稀缺的安全人才转化为软件。

显然，这种模式并不完美。安全供应商构建的逻辑可能是通用的，可能会忽略个别环境的细微差别，等等，但它做得非常好的一点是向最终客户交付大多数企业无法独自承担或吸引的专业知识。

现在想象一下，如果每家公司都开始尝试在内部构建安全工具会发生什么。我们将不再只有几千家供应商争夺前 1% 的安全工程师，而是会有数万（或数十万？）家企业都在试图招聘、留住并管理自己的内部检测工程师、云安全架构师、威胁猎手和安全平台构建者。数学上根本行不通，因为没有足够的安全专业知识。与普遍的看法相反，AI 不会改变这一点。

所有这些让我想到，虽然一些安全工具确实可以内部构建，但安全团队不太可能去构建那些需要专门安全专业知识的工具。

构建成本正在下降，但拥有成本却没有显著降低

公司不会开始构建自己的工具的另一个重要原因是拥有成本。

AI 确实在降低前期开发成本，但它并没有改变总体拥有成本的方程式。我完全理解为什么人们对使用 AI 构建软件感到如此兴奋，但构建软件不仅仅是快速推出炫酷的新功能。它还涉及维护。当 API 发生变化时，谁来更新集成？当技术债务过多时，谁来重构系统？谁会一直负责调试？AI 将越来越多地处理这些任务，但在企业规模上，仍然需要人类来确保一切正常运作。每个软件供应商都必须应对值班轮换、文档编写、知识传递、功能请求、错误修复、基础设施扩展、合规性、审计和模型再训练等问题，而长期维护的成本通常远远高于初始构建成本。

购买软件不仅仅是购买软件本身，还包括随之而来的许多无形资产，例如可靠性、安全性、能够通过跨司法管辖区的复杂审计、大规模运营弹性、在最糟糕的情况下可以信赖的合作伙伴等等。当公司对内部构建过于兴奋时，所有这些因素都需要考虑在内，大多数团队一旦意识到构建成本与维护成本之间的差距有多大，就会选择放弃内部构建。

所有这些让我认为，虽然一些安全工具确实可以内部构建，但安全团队不太可能尝试构建那些拥有成本非常高的工具（这适用于许多安全产品，因为大多数产品需要不断更新才能保持有效性）。

责任在构建与购买决策中扮演着关键角色

当公司内部构建软件时，他们需要承担一切不顺利的后果。如果出现问题，或者发生事故（无论是服务中断还是安全漏洞），都没有供应商合同可以依赖，也没有共享责任模型。他们必须独自面对任何后果。

对于企业的许多领域来说，这些风险是可以接受的。比如说，如果营销团队需要一个仪表板来跟踪广告活动的表现，那么构建一个从内部 CRM 数据提取信息并在美观的 UI 中展示的工具是合理的。又比如，人力资源团队花费了太多时间处理休假请求，那也可以通过内部自动化来解决。

安全则是另一回事，因为它直接关系到合规性、监管要求、客户信任和品牌声誉。很少有 CISO 会在资源已经不足的团队开始自行构建安全工具时睡得安稳，这不仅是因为这可能增加漏洞的风险，还因为这可能使合规性变成一场噩梦。审计员可能不会接受“我们自己构建的”作为控制的证明，而是开始要求提供文档、测试、变更管理和独立验证。当这种情况发生时，内部工具很快就会从优势变为负担。

在这些关于自行构建的讨论中，人们忽略的另一个因素是保险。网络保险承保人不仅仅会问公司是否有安全措施；他们还会询问公司使用了哪些工具，这些工具是否被行业认可，是否得到维护、审计和支持等。即使他们没有提前询问这些问题，但如果一家大型企业遭到攻击，并且发现关键的安全控制被内部构建的工具取代而不是由专业供应商提供，这可能会引发严重的问题，在某些情况下甚至可能导致保险失效。总之，责任问题是一个重要的考虑因素。对于只需要 SOC 2 认证即可向企业销售的技术公司来说，这可能没那么重要，但对于上市公司或受监管行业的公司来说，它们显然有更多需要失去的东西。

所有这些让我认为，虽然一些安全工具确实可以内部构建，但安全团队不太可能构建那些可能使他们承担责任并有可能在监管机构、审计员或保险公司方面引发问题的工具。

内部构建的工具通常缺乏行业级的情报

正如我所说，安全供应商构建的产品可能提供某种程度的通用覆盖，但有时这反而是优点，而非缺点。供应商可以看到许多不同环境中的模式（攻击技术、配置错误趋势、漏洞利用链、误报模式、真实世界的数据泄露等）。这种可见性创造了一种网络效应，客户越多，他们的检测逻辑、威胁模型和防御策略就越完善。

内部工具只能看到一个环境，因此即使在某些公司中它可以高度定制化以满足他们认为的需求，但与供应商为多个客户服务所构建的工具相比，它总是缺乏广度。内部工具无法受益于共享情报，甚至无法从其他公司发生的事件中学到教训。对于安全产品而言，这是一个巨大的差距，因为接触大量“恶意行为”的例子是实现全面覆盖的必要条件。CrowdStrike 或 Palo Alto 的检测技术只有在公司能够同时看到如此多的环境时才能真正复制，我认为无论企业多么庞大或成熟，都无法在单一企业内部真正复制这一点。

所有这些都让我想到，尽管一些安全工具确实可以在内部构建，但那些受益于行业范围网络效应的安全工具，安全团队不太可能自行开发，因为没有这些网络效应，这些工具的价值将非常有限。

首席信息安全官（CISO）不应急于构建自己的安全工具的两个额外原因

这将使招聘和新员工入职变得极其复杂

安全团队总是资源受限，无法承受让新的分析师或工程师花费数月时间仅仅学习内部系统后才能有所贡献的情况。当新人加入公司时，他们需要快速上手，并从第一天开始提供价值。

当公司使用标准工具时，入职过程会快得多，因为新员工通常已经熟悉他们将要使用的工具，或者可以依赖现有的文档和供应商支持。而定制工具则往往文档质量较差，更多依赖“部落知识”（即不成文的经验），这使得招聘更加困难，入职周期更长，因为没有人会带着对你们内部自定义堆栈的现成经验加入。

你必须自己构建集成

没有任何安全团队可以仅靠单一工具完成所有需求。不可避免地，工具数量会膨胀，所有的 SIEM、EDR、CSPM、DSPM、云平台、身份提供商（IdP）、漏洞扫描器、工单平台等都需要相互通信。维护这些集成是一项巨大的工作，虽然我们必须承认许多网络安全供应商在这方面并不总是做得很好，但当你构建自己的工具时，集成问题就完全成了你的责任。

如果你构建了定制工具，那么你就要负责每一个连接器。AI 可以帮助编写它们，但 API 会发生变化，认证机制可能会中断，供应商会更新端点，最终你会发现自己不得不维护这些“管道”，而不是改进公司的安全性。我个人认为这不是安全团队时间的良好利用方式，但我相信会有不少人持不同意见。

安全团队将构建大量自己的“胶水”工具和生产力工具（并且他们应该这样做）

总结一下，我认为安全团队无法大规模构建自己的安全工具，特别是：

• • 技术复杂、需要在大规模环境下运行、处理大量数据、需要代理程序等的工具。
• • 总拥有成本（TCO）非常高的工具（这适用于许多安全产品，因为大多数产品需要持续更新才能保持有效性）。
• • 需要专门安全专业知识的工具。
• • 可能使公司面临法律责任或与监管机构、审计人员或保险公司产生问题的工具。
• • 受益于行业范围网络效应且没有这种效应就会价值有限的工具。

这留下了一个领域，我认为我们将看到大量内部构建的工具。我指的是那些能够提高安全团队效率、专注于他们日常实际花费最多时间的任务的工具。

我之前写过一篇文章：大多数安全团队的工作与追踪高级对手无关^[4]。在几年前的那篇文章中，我解释道：“尽管许多人受到黑客思想的启发而加入网络安全行业，但绝大多数安全工作与主动尝试抓捕对手毫无关系。在企业中的网络安全团队工作与其他团队类似，大部分时间花在以下方面：

• • 沟通，包括开会、发送和回复电子邮件及 Slack 或 Teams 中的消息、回答问题、准备报告和状态更新、跟踪关键绩效指标（KPI），以及与其他部门协调。
• • 跨职能协作，包括阅读和撰写文档、理解不同部门如何开展工作、协调涉及多个团队的复杂计划、向员工和职能部门领导解释各种控制措施的重要性，以及协商最低限度的实际安全措施。
• • 安全布道，包括解释为什么密码不能保存在电子表格中或通过短信发送（即使通过加密消息平台也不行）、为什么服务账户不能拥有域管理员权限、为什么人们应该使用 Yubikey 而不是基于短信的多因素认证（MFA）等等。最重要的是，所有这些都需要在不成为阻碍他人工作和实现公司收入目标的情况下完成，同时避免破坏与组织内其他人的关系。
• • 购买和维护安全工具，包括进行差距分析、测试新的安全解决方案、定期评估现有安全工具的实施情况、解决配置相关问题，以及决定哪些政策适合在环境的哪些部分实施。
• • 资源规划，包括谈判预算和人员编制、为特定领域的安全投资提供理由、组建、组织和重组团队，以及与人力资源和招聘人员合作制定招聘和员工薪酬计划。
• • 培训和入职，包括阅读和撰写文档，并指导新员工快速了解组织内的运作方式。

许多人可能会认为这些事情很无聊，但这正是办公室工作的本质——我们所做的许多工作都是平凡的任务，只需要完成即可，而不是那些能够充分利用我们的技能和能力的最令人兴奋的项目。每一份办公室工作都有一个部分是活在 Excel 表格和 PowerPoint 演示文稿中的。”来源：大多数安全团队的工作与追踪高级对手无关^[5]

这就是安全团队应该自动化的部分，正如亚马逊所称的，所有这些无差别的繁重工作。我坚信，除非你是工程驱动型安全团队中的前 1%，否则像预防、检测、响应和恢复这类任务最好交给安全厂商处理。而利用 AI 构建的内容，则是用来打造“胶水”，即自动化其间一切的工具。这关乎自动化工作流程、自动化工作本身，并提升生产力。

过去，安全团队的能力受限于其安全编排、自动化与响应（SOAR）平台的功能，但现在他们可以超越这些平台曾经提供的能力。如今的机会并不是淘汰核心安全供应商并用氛围代码解决方案取而代之，而是构建定制化的生产力工具，让安全团队更高效。

提高个人生产力并消除胶水工作，是安全团队应聚焦其 AI 驱动自动化努力的方向。要做好这一点，需要对内部流程、程序以及真实环境中存在的所有快捷方式和边缘情况有深刻理解——这是任何外部供应商都无法完全复制的上下文。

同时，安全团队不应试图重新构建那些需要大量工程专业知识、安全知识或依赖网络效应的成熟产品，仅仅为了“省钱”。一旦考虑工程时间、维护和持续改进的成本，维护任何有意义的内部工具几乎总是比订阅外部服务更昂贵。老实说，我们以前在脚本中已经见过这种情况的结果。起初是一个快速提升生产力的小胜利，但最终却慢慢演变成另一个脆弱的系统需要维护。真正节省成本并产生影响的机会，在于自动化组织内真正独特的内容：其独特的系统、工作流程和机构知识。

更新：在发布这篇文章后，我的朋友 Guillaume Ross 发给我一条信息，总结得比我更好：“现在编写 Shell 脚本变得非常容易，但构建一个数据湖并非如此。当然，湾区风格的安全团队现在可以构建任何东西，但其他人可能更适合使用 Claude Code 来生成 SOAR 剧本、解析日志或以代码形式创建检测规则。他们应避免尝试构建任何需要收集大量数据并依赖基础设施的严肃项目。”

引用链接

[1] There’s only one kind of tool security teams should be building with AI: https://ventureinsecurity.net/p/theres-only-one-kind-of-tool-security[2] 我的朋友 Frank Wang 是对的: https://franklyspeaking.substack.com/p/the-changing-buy-vs-build-calculus[3] 我多年前就解释过实际情况: https://ventureinsecurity.net/p/lets-get-real-there-is-no-such-thing[4] 大多数安全团队的工作与追踪高级对手无关: https://ventureinsecurity.net/p/most-of-the-security-teams-work-has[5] 大多数安全团队的工作与追踪高级对手无关: https://ventureinsecurity.net/p/most-of-the-security-teams-work-has