当 AI 成了“自动黑客”，开源还守得住吗？Cal.com 关源引发的一场安全路线之争

Cal.com 这次“关门”的消息，在开发者圈子里不亚于一颗小炸弹。

这家以开源日程预约工具闻名的公司宣布，正在把核心代码库逐步从开源模式转走。CEO Bailey Pumfleet 给出的理由非常有这个时代的气质：AI 已经能大规模自动发现漏洞，扫代码、找入口、尝试利用，成本几乎接近零。在这种情况下，透明不再只是协作的前提，也可能变成攻击者的捷径。

如果把这句话放在三年前听，很多人会觉得是危言耸听。但放在 2026 年，它更像一句让人不舒服、却很难反驳的行业现实。今天的软件安全，确实正在经历一个肉眼可见的结构性变化：过去是人找漏洞，慢、贵、稀缺；现在越来越像机器找漏洞，快、便宜，而且不知疲倦。

Cal.com 的转身，不只是一次“关源”

先别急着把这事简单归类成“开源理想主义的退潮”。Cal.com 的决定，背后其实有很强的现实压力。

有意思的是，公开发文反对这一决定的，不是传统意义上的开源布道者，而是一家做 AI 安全代理的公司 Strix。它在文章里坦率承认：自己做的东西，某种程度上正是 Cal.com 所担心的那类技术。Strix 表示，他们最近还在和 Cal.com 团队合作，按照负责任披露流程报告平台里的漏洞，而且 Cal.com 工程团队响应很快、态度专业。也就是说，这不是一场简单的口水战，双方甚至在同一张安全棋盘上一起下过棋。

这也是这件事最耐人寻味的地方。Cal.com 并不是突然“背叛开源”，更像是被现实推着做出一次痛苦收缩。对一家面向真实客户、真实业务、真实攻击面的 SaaS 公司来说，安全事故不是 GitHub issue，而是客户信任、合规责任和品牌损失。尤其在预约、会议、企业协作这些场景里，一次权限绕过、一个 webhook 授权缺陷，都可能牵出真实的组织通讯录、会议信息和工作流数据。

所以，从企业经营视角看，Cal.com 的动作不难理解：如果 AI 真让攻击者拥有了“无限实习生”，那把源码继续摆在外面，的确会让人睡不踏实。

但闭源真的能挡住 AI 黑客吗？

Strix 的核心反驳也很尖锐：现在的 AI 安全代理，未必需要读你的源码。

这是很多人理解漏洞挖掘时最容易停留在旧时代的地方。过去我们说“开源更容易被找漏洞”，默认前提是攻击者会看代码、做静态分析、顺着调用链找问题。可今天更强的一类 AI 工具，已经越来越擅长黑盒和灰盒测试。它们会自动和真实接口交互，切换浏览器状态，分析网络请求，组合业务流程，在完全拿不到仓库访问权限的情况下，照样能发现授权绕过、逻辑漏洞、输入验证缺陷，甚至一些很微妙的业务边界错误。

说得直白一点：你把门牌号摘了，不代表小偷就找不到门。

这也是为什么“安全依赖模糊化”一直不是一个特别可靠的策略。软件安全史上，这个教训已经重复很多次。无论是早年的闭源桌面软件，还是后来各种藏接口、藏文档、藏实现细节的 Web 服务，真正的攻击面往往都暴露在运行中的系统本身。API 在那里，登录流程在那里，权限模型在那里，第三方集成在那里。只要服务还在线，攻击者就有足够多的地方试探。

AI 的可怕之处，不在于它突然发明了新型漏洞，而在于它把“试探”这件事工业化了。以前一个外部研究员花三天才能测完的流程，现在 AI 代理可能一小时就能跑完几十种变体。它不会累，不会烦，也不会因为周末停工。攻击面仍然公开存在，差别只是今天有人拿着显微镜自动巡逻。

开源神话正在褪色，但开源未必输了

过去开源社区最常被引用的一句话，是“足够多的眼睛会让 bug 变浅”。这句名言并没有错，只是它建立在一个重要假设上：那些“眼睛”主要来自善意的开发者和维护者。

而现在，坏人的“眼睛”也被 AI 大幅增强了。于是问题来了：开源还天然更安全吗？答案恐怕没那么浪漫了。开源从来不是护身符，它只是让更多人能看见系统。至于看见的人是修补者还是攻击者，取决于整个生态的防守能力是否跟得上。

这正是 Cal.com 事件真正刺痛行业的地方。它不是在宣布“开源已死”，而是在逼大家承认：开源曾经依赖的人海式协作优势，正在被机器化攻击削弱。如果社区的修复速度、审计能力、响应机制都没有同步 AI 化，那么“公开”带来的增益就可能被“自动化利用”抵消，甚至反噬。

不过，我依然不认为闭源会成为未来主流答案。理由很简单：闭源只是在减少外部可见性，不是在消灭风险本身。相反，它还可能带来另一个老问题——安全验证更依赖内部团队和少数审计方，透明度下降，外部监督变弱，普通用户更难判断系统到底安不安全。对于基础设施软件、开发工具、企业协作平台这类产品，信任很多时候恰恰来自可验证性。

所以这场争论，真正该被讨论的不是“开源还是闭源更道德”，而是“在 AI 时代，什么样的安全机制还能跑赢攻击自动化”。

真正的分水岭，是把 AI 放进防线里

Strix 给出的答案是“用 AI 对抗 AI”。这听起来像安全行业的标准营销语，但我认为方向并没错。

软件开发过去十几年最显著的变化，是 CI/CD 把发布节奏彻底加快了。代码提交、测试、上线，越来越像流水线。问题是，安全审计并没有同步完成工业化升级。很多团队依然靠上线前扫描一次、每季度做一次渗透测试、出问题再补洞。这样的节奏，对付人工攻击都已经吃力，更别说对付 24 小时在线、低成本试错的 AI 代理。

更合理的做法，是把安全测试直接嵌进开发流程本身。开发者一开 pull request，自动化安全代理就开始尝试利用新改动；权限模型一调整，系统就自动验证有没有越权路径；新的 webhook、插件、OAuth 集成一上线，AI 先替攻击者把坑踩一遍。说白了，别等黑客来测试你的产品，你得让机器先在自家院子里闹一遍。

这件事在行业里其实已有预兆。GitHub Copilot 把写代码门槛拉低后，更多公司开始意识到“代码产能”暴涨的另一面，是“潜在漏洞产能”也在同步暴涨。开发速度越快，安全越不能靠人工追赶。接下来几年，AI 安全代理、自动化红队、持续验证，可能会像单元测试和代码检查一样，成为现代软件团队的默认配置。

这场争议，最后考验的是谁更配得上“信任”

站在记者视角看，Cal.com 这次转向很像一个行业信号：开源公司正在重新计算透明的成本，而 AI 正在改写这道账。

我能理解 Cal.com 的焦虑，甚至某种程度上同情它。今天的创业公司本就要在增长、性能、稳定性、合规之间同时走钢丝，现在又多了一项：防 AI。你可以把代码关起来，先给自己争取一点心理安全感，这不是懦弱，是商业世界里很真实的自保反应。

但如果把视线放长一点，真正能决定谁活下来的，恐怕不是仓库权限设成 private 还是 public，而是谁能建立起更快的修复闭环、更强的自动验证能力，以及更能被用户理解和信任的安全叙事。

开源世界未来大概会分化。一类公司会继续高举透明旗帜，但前提是必须配套更强的 AI 防守系统；另一类公司则会转向“有限开放”或“开放外围、闭合核心”的混合模式，既保留社区参与，也降低核心风险暴露。两条路都能走，但都不再轻松。

唯一可以确定的是，那种“把代码放上 GitHub，自然会有人帮你看着安全”的时代，正在结束。以后拼的不是谁更勇敢，而是谁更自动化，谁更诚实，谁更快地把漏洞从发现带到修复。

这场关于 Cal.com 的争论，表面看是开源与闭源之争，底层其实是一个更残酷的问题：当 AI 同时武装了黑客和守门人，软件行业到底准备好用什么方式继续相信彼此？