别被AI冲昏头:企业安全工具自研的边界与真相

过去一年，对国外安全领域撰写者Ross Haleliuk 而言，他也说不清在社交媒体上刷到了多少碎片化内容，但有那么个趋势格外醒目：他在网上的信息流几乎被安全从业者们刷屏，大家都在兴奋地分享自己用大语言模型开发的各类酷炫工具。整个行业弥漫着一种乐观情绪，普遍认为大语言模型的普及让“人人都能成为产品开发者”成为可能，而这也意味着企业安全团队终于可以摆脱对外部厂商的依赖，自主打造专属的安全产品了。

无独有偶，Ross表示，他身边很多聪明且富有洞见的朋友，正是“AI将推动企业内部自研安全工具、逐步替代厂商采购”这一观点的拥护者。他说，他对朋友们的专业能力和判断力向来尊重，但在这个问题上，他恰好持有不同看法。“个人认为，我们距离‘企业纷纷自研安全工具’的时代还非常遥远。网络安全团队确实可以在内部开发某一类特定工具，但这类工具并不能真正替代专业网络安全厂商的核心产品。”

Ross认为，大多数企业无法自研安全工具的首要原因，是缺乏足够的专业能力。他也承认，在如今“AI能自动写代码”的时代，这个观点听起来有些反直觉。对此Ross解释道，在成为创始人之前，他曾担任多年产品负责人，无数次亲眼见证：写几行代码和打造一款真正可用、能经受住企业级环境考验的产品，完全是两个维度的事情。

一款合格的企业级安全工具，绝不是简单写个增删改查（CRUD）应用就能搞定的。它需要深厚的安全领域知识、严谨的系统架构设计、极致的性能优化、完善的边缘场景处理能力，以及在复杂混乱的异构IT环境中持续稳定运行的能力。Ross明确表示，这些核心能力，是Claude Code等AI编程工具无法凭空赋予的。

AI确实让写代码的效率得到了前所未有的提升，但这也让系统思维和架构设计这类高阶能力变得比以往任何时候都更加重要。AI无法凭空赋予企业对自身网络拓扑、身份模型、日志管道、合规细节以及日常运营流程的多年积累认知。这些专业能力依然需要资深工程师来掌握，而大多数企业根本没有闲置的资深工程师，等着去重新打造安全厂商已经打磨了十年甚至更久的成熟产品。

在Ross看来，AI真正会带来的改变，是进一步拉大以工程为核心的安全团队和其他所有安全团队之间的差距。“如果你所在的是硅谷风格、产品驱动的公司，已经有优秀的安全工程师在开发内部工具，那么AI会极大地放大这种优势。它能让你的团队更快地完成原型设计、更快地搭建内部工具、实现更多工作流程的自动化等等。”

Ross表示，如果我们在OpenAI、Anthropic、谷歌、爱彼迎、Canva、Figma、Notion、优步、Reddit或者Discord这类以工程为核心基因的公司工作，那现在绝对应该借助AI开发比以往多得多的内部工具。对于这些公司而言，它们确实会大量进行内部自研。

但对于其他绝大多数企业来说，情况则完全不同。Ross指出，如果昨天自研安全产品还不现实，那么AI也不会在明天就奇迹般地让这件事成为可能。那些原本就没有工程人才储备的公司，不会因为他们雇得起的三个安全运营中心（SOC）分析师现在能用Claude了，就突然具备了开发企业级工具的能力。那些昨天还承受着巨大监管压力的企业，今天也不会突然就没了压力。

Ross也承认，AI确实会扩大有能力自研安全产品的企业比例。他估算，这个比例会从原来的1%-2%增长到4%-7%，但绝对不会达到70%，甚至连30%都不可能。“这些数字是我基于行业观察的估算，目前没有确切的统计数据，但我敢打赌实际数字肯定还是个位数。”

所有这些都让Ross认为，虽然有些安全工具确实可以内部自研，但安全团队不太可能去开发那些技术复杂、需要大规模运行、处理海量数据、需要部署代理程序的核心安全工具。

如果说找到合格的工程人才已经难如登天，那么找到资深安全人才的难度只会有过之而无不及。Ross表示，现在大家都在谈论所谓的“网络安全人才短缺”，但无论是声称安全行业已经人才过剩的人，还是说我们还需要400万安全工程师的人，其实都没有抓住问题的本质。他几年前就解释过真实的情况：网络安全行业里找入门级工作的人太多，而真正能独当一面的资深专业人才太少。

真正精通检测工程、应急响应、云安全与工程、身份安全、网络渗透、合规要求以及攻击者行为的人，在整个行业里都凤毛麟角。大多数安全工具，无论是专注于防护、检测、响应、修复还是恢复，本质上都是将少数高度专业化的研究人员和工程师的专业知识“编码”到软件中，再将这些知识传递给成百上千的客户。从某种意义上说，安全厂商将极其稀缺的专业能力工业化，把稀缺的安全人才转化为了可规模化交付的软件产品。

Ross也承认，这种模式并非完美。安全厂商构建的逻辑可能比较通用，会忽略个别企业环境的细节等等，但它最大的优势在于，能为终端客户提供大多数企业靠自己永远无法负担、也吸引不到的顶尖专业能力。

现在不妨试想一下，如果每家企业都开始尝试内部自研安全工具会发生什么。届时不再是几千家厂商争夺那1%的顶尖安全工程师，而是几十万甚至上百万家企业都要去招聘、留住和管理自己的内部检测工程师、云安全架构师、威胁猎手和安全平台搭建者。

Ross认为，这在数学上根本行不通，因为安全专业人才的总量根本不够。与大众的普遍认知相反，AI也改变不了这一点。所有这些都让Ross认为，虽然有些安全工具确实可以内部自研，但安全团队不太可能去开发那些需要深厚专业安全知识的工具。

Ross指出，企业不愿自研安全工具的另一个重要原因，是总拥有成本（TCO）的现实问题。

AI确实显著降低了工具的前期开发门槛和初始成本，但它完全没有改变软件全生命周期成本核算的底层逻辑。Ross完全理解行业为何对AI驱动的快速开发如此狂热，但他强调，软件开发绝不只是快速推出几个酷炫新功能那么简单，后续漫长的维护工作才是真正的考验。当第三方API发生破坏性变更时，谁来紧急更新集成接口？当技术债务堆积到影响系统稳定性时，谁来承担重构工作？谁又能7×24小时待命排查生产环境的突发故障？

Ross表示，虽然AI未来会越来越多地参与到这些运维工作中，但要让系统在企业级规模下持续稳定运行，人的参与依然不可或缺。任何一家成熟的软件厂商，都要应对轮值待命、文档编写、知识传递、需求迭代、漏洞修复、基础设施扩容、合规审计以及模型重训等一系列常态化工作。而这些维护工作的长尾成本，通常远高于最初的开发投入。

在Ross看来，采购商业软件，本质上是在购买随之而来的大量无形价值：经过市场验证的可靠性、内置的安全防护能力、跨地区复杂审计的通过保障、大规模运营的韧性，以及在最危急时刻出问题时可以信赖的技术支持伙伴。当企业对内部自研过于上头时，必须把这些隐性成本和价值都纳入考量。而大多数安全团队一旦看清一次性开发成本和长期维护成本之间的巨大差距，就会理性地放弃自研的想法。

所有这些都让Ross认为，虽然有些安全工具确实可以内部自研，但安全团队不太可能去尝试开发那些总拥有成本极高的工具——而这一点恰恰适用于绝大多数安全产品，因为安全工具的核心价值就在于持续更新以应对不断演变的威胁。

Ross强调，当企业选择内部开发软件时，所有潜在风险和后果都将由自己全权承担。如果系统崩溃，或者发生安全事件，无论是服务中断还是数据泄露，没有厂商合同可以依靠，也没有责任共担模式可以缓冲。无论发生什么，企业都必须独自面对和处理。

对于企业的很多非核心业务领域来说，这种风险是可以接受的。比如，营销团队想要一个看板来追踪活动效果，开发一个从内部CRM拉取数据并做可视化展示的工具完全合理。再比如，人力资源团队在处理休假申请上花费了太多时间，这类重复性工作也完全可以通过内部自动化来解决。

但安全领域完全是另一回事，因为它直接关系到企业的合规底线、监管要求、客户信任和品牌声誉。Ross直言，如果本就人手不足的安全团队开始凭感觉写代码自研核心安全工具，很少有CISO能睡得安稳。这不仅会显著增加数据泄露的概率，还会让合规工作变成一场噩梦。审计人员几乎不会接受“我们自己开发的”作为控制措施有效的证明，反而会要求提供完整的设计文档、测试记录、变更管理流程和独立验证报告。一旦走到这一步，内部工具很快就会从所谓的”效率优势”变成沉重的运营负担。

Ross还指出，在这些关于“随性编码”的热烈讨论中，人们普遍忽略了另一个关键因素——网络保险。网络保险承保人不会只简单询问企业“有没有做安全防护”，他们会深入追问企业使用了哪些工具、这些工具是否得到行业广泛认可、是否有专业团队持续维护、是否经过第三方安全审计、是否有官方技术支持等等。

即便他们在投保时没有详细核查这些问题，如果一家大型企业发生重大数据泄露，而事实证明关键安全控制措施被未经充分验证的内部自研工具取代、没有使用专业厂商的成熟产品，那会引发极其严重的保险纠纷。在某些极端情况下，甚至会直接导致保险理赔失效。

归根结底，Ross认为责任风险是一个必须放在首位考虑的重要因素。对于只需要通过SOC 2认证就能向企业客户销售产品的初创科技公司来说，影响可能相对有限，但上市公司，尤其是金融、医疗、能源等受强监管行业的企业，一旦出现问题，要承担的损失将是难以估量的。

所有这些都让Ross认为，虽然有些安全工具确实可以内部自研，但安全团队不太可能去开发那些会让自身暴露于重大责任风险之下、可能引发监管处罚、审计失败或保险理赔问题的核心安全工具。

正如Ross之前所说，安全厂商的产品可能提供的是相对通用的防护能力，但有时候这恰恰是它们的核心优势而非缺陷。专业厂商能够看到横跨数千甚至数万个不同企业环境的各类安全模式，包括最新的攻击技术、普遍存在的错误配置趋势、完整的利用链、高频误报模式、真实世界的泄露数据等等。

这种广泛的行业可见性会形成强大的网络效应：客户越多，厂商积累的威胁数据就越丰富，他们的检测逻辑、威胁模型和防御手册就会变得越完善。而这种正循环，是任何单一企业都无法在内部复制的。

相比之下，内部工具只能看到单一企业的有限环境。即便它在某些方面能高度贴合企业自身的独特需求，但与服务众多客户的厂商产品相比，其视野永远存在根本性的局限。内部工具无法共享全行业的威胁情报，也无法从其他公司发生的安全事件中提前吸取教训。

Ross认为，对于安全产品来说，这是一个致命的短板。因为要实现真正全面的防护，必须接触过海量的“恶意行为”样本，了解攻击者的各种手法和变种。CrowdStrike或Palo Alto这类厂商的检测能力，只有当一家企业能同时看到同等数量的全球环境时才有可能复制。而无论一家企业规模多大、安全体系多成熟，都不可能在内部真正复制这种行业级的情报优势。

所有这些都让Ross认为，虽然有些安全工具确实可以内部自研，但安全团队不太可能去开发那些高度依赖全行业网络效应、没有这些效应价值就会大打折扣的威胁检测与防御类工具。

Ross指出，安全团队向来人手紧张，根本耗不起让新分析师或工程师花好几个月时间，只用来学习内部系统才能开始创造价值。新员工加入公司后，企业最需要的是他们能够快速上手，最好入职第一天就能产出实际价值。

如果企业使用行业标准工具，入职流程会顺畅得多。因为新员工往往已经熟悉这些主流工具，即便不熟悉，也能依靠完善的官方文档和厂商技术支持快速掌握。而自研工具通常存在文档质量参差不齐、更新不及时的问题，知识传递几乎全靠口口相传的“部落知识“。这不仅会让招聘变得更加困难——毕竟没人入职前就用过你们公司专属的内部技术栈，还会大幅拉长新员工的入职周期，进一步加剧团队的人手压力。

没有哪个安全团队能只靠一款工具就搞定所有工作。工具多样化是行业的必然趋势，安全信息与事件管理（SIEM）、端点检测与响应（EDR）、云安全态势管理（CSPM）、数据安全态势管理（DSPM）、各类云平台、身份提供商（IdP）、漏洞扫描器、工单系统等等，所有这些工具都需要相互打通才能发挥最大效用。

维护这些集成本身就是一项极其繁重的工作。Ross坦言，虽然不得不承认很多网络安全厂商在集成方面做得并不出色，但如果选择自研工具，集成的责任就100%落到了自己头上。一旦开发了自研工具，企业就得负责维护它与其他所有系统之间的每一个连接器。

AI确实能帮忙快速编写集成代码，但第三方API会变、认证机制会失效、厂商会不定期更新接口。“最后你会发现，自己整天都在修补这些‘数据管道’，而不是在真正提升公司的安全防护能力。”Ross表示，他个人认为这不是安全团队时间的合理利用方式，但也承认肯定有很多人不同意他的看法。

总而言之，Ross认为安全团队不可能大规模自研核心安全工具，尤其是以下几类：

但有一个领域，Ross坚信确实会出现大量内部自研工具，那就是能帮助安全团队更高效完成日常工作的衔接工具和生产力工具。

Ross提到，他之前写过一篇文章，专门探讨安全团队的大部分工作其实和追踪高级攻击者毫无关系。在那篇文章中他解释道，很多人是被黑客技术的魅力吸引进入网络安全行业的，但绝大多数安全工作与主动追踪攻击者相去甚远。在企业的安全团队工作，和在其他任何团队工作没什么两样，大部分时间都花在了这些事情上：

很多人会觉得这些工作很无聊，但这就是办公室工作的本质，也是大多数工作的常态。“我们做的很多事都是必须完成的琐碎任务，而不是那些能充分发挥我们所有技能和能力的激动人心的项目。每一份办公室工作，都有离不开的Excel表格和PPT。”

Ross强调，这些才是安全团队应该优先自动化的内容，也就是亚马逊所说的“无差别的繁重工作”。他坚信，除非是那1%顶尖的、以工程为核心的安全团队，否则防护、检测、响应、恢复这类核心安全能力，还是交给专业的安全厂商来做更好。

AI赋能的真正价值，不在于用“凭感觉写代码”的方案取代核心安全厂商，而在于搭建定制化的生产力工具，让安全团队的日常工作更高效。提升个人生产力、消除繁琐的衔接性工作，才是安全团队应该聚焦的AI自动化方向。要做好这件事，需要对公司内部的流程、制度，以及真实环境中存在的各种捷径和边缘场景有深刻的理解——而这些上下文是任何外部厂商都无法完全复制的。

最后，Ross也提醒，安全团队不应该为了所谓的“省钱”，就试图去重建那些需要大量工程能力、安全专业知识，或者依赖网络效应的成熟产品。一旦把工程师的时间成本、长期维护成本和持续迭代的投入都算进去，维护任何有实际价值的内部工具，总是比订阅厂商服务更贵。

“说实话，这种事我们以前用脚本的时候就见过太多了：一开始只是为了提升效率写的几十行小脚本，慢慢就演变成了另一个脆弱不堪、需要不断维护的‘影子系统’。”Ross说，真正能省钱、能产生实际影响的机会，在于自动化那些真正属于企业独有的东西：独特的系统、独特的工作流程，以及独特的组织知识。