当开源撞上 AI 攻击：Cal.com 关掉代码仓库，敲响了一个时代的警钟

Cal.com 这次的决定，很容易让人感到别扭，甚至有点唏嘘。

这家公司过去五年一直把“开源”当作自己的招牌之一。对很多开发者来说，Cal.com 不只是一个预约排期工具，更像是 Calendly 的开源替代品：你可以自己部署、自己改、自己把它嵌进产品流程里。可现在，它正式宣布核心生产代码库转为闭源，公开给社区的，只剩下一个名为 Cal.diy 的 MIT 许可版本，主要面向爱好者和自托管用户。

表面上看，这像是一家公司成长到某个阶段后的“商业化收口”；但 Cal.com 给出的理由却相当直白：不是钱，不是竞争，而是安全，准确说，是 AI 驱动的安全威胁正在改变游戏规则。

开源的浪漫，遇上 AI 的现实

Cal.com 的说法并不复杂：过去要找出一个大型应用的漏洞，往往需要经验老到的安全研究员或者黑客花上很长时间，逐段看代码、逐层试路径、逐个打点。这个过程既耗脑也耗命，人的注意力和耐心天然有限。

但 AI 没这个毛病。它不会累，不会烦，也不会在凌晨两点因为咖啡喝多了看漏一段认证逻辑。把一个开源代码库丢给模型，再配合自动化安全工具，漏洞扫描、逻辑推演、攻击路径生成，正在变得像 CI/CD 一样流水线化。Cal.com 甚至用了一个很形象的比喻：开源越来越像把保险库的蓝图交给了攻击者。

这话听起来有点刺耳，因为开源世界一直有一句老话："阳光是最好的消毒剂"。代码公开，意味着更多人能审查、发现问题、提交修复。Linux、PostgreSQL、Kubernetes 这些基础设施之所以强大，很大程度上正是靠这种集体审视。

问题在于，AI 把“审查代码”的门槛拉低了，但并没有同步提升“修复漏洞”的速度。于是就出现了一个尴尬局面：攻击者可以 24 小时不间断地用模型找洞，防守方还得排优先级、跑回归测试、协调上线窗口。漏洞发现开始像高频交易，漏洞修复却还是手工作坊。这中间的时间差，就是现实世界里最危险的空档。

Cal.com 为什么在这个时间点转身

从业务属性看，Cal.com 的焦虑不是空穴来风。日程安排听上去不像支付或医疗那么敏感，但它处理的数据并不轻：用户身份、会议链接、邮箱地址、组织架构、客户沟通节奏，甚至可能包含销售线索和商务谈判的时间轨迹。对攻击者来说，这些信息足够拼出一张很有价值的画像。

尤其在企业服务场景里，日历类产品往往不是孤立存在的。它会连着 Google Calendar、Microsoft 365、视频会议系统、CRM、邮件服务、支付模块和身份认证系统。也就是说，一旦某个入口被突破，风险未必只停留在“约会系统挂了”，而可能顺藤摸瓜进入更深的企业流程。这也是为什么很多 SaaS 公司近几年都在重新审视公开代码、插件生态和第三方集成的边界。

Cal.com 在公告里提到，最近几个月已经看到一批 AI 安全创业公司把这类能力产品化，不同平台都能扫描出不同的漏洞，但谁说得最准、哪些是真风险、哪些只是噪音，并没有一个稳定答案。翻译成人话就是：你不仅更容易被攻击了，甚至连自己到底有没有真的安全，都开始变得难以判断。

这也是 AI 时代一个很反直觉的变化。按理说，安全工具更强，大家应该更安心才对；现实却是，工具越多、报告越多、警报越多，团队反而更容易陷入“持续焦虑”。今天你修完一个 SSRF，明天模型又给你挖出一个权限绕过，后天还有个历史依赖里的边缘条件漏洞。修不完，根本修不完。

闭源真能更安全吗？这事没那么简单

我对 Cal.com 的处境能理解，但如果把“闭源”直接等同于“更安全”，那也过于乐观了。

安全行业有个并不新鲜的共识：闭源不等于没有漏洞，攻击者也不一定非得看到源码才能下手。Web 应用的接口、返回结构、前端资源、错误信息、流量特征，都会泄露大量实现细节。尤其在现代 SaaS 架构下，很多攻击本来就更依赖运行时行为，而不只是阅读源码。换句话说，把仓库设为 private，能提高攻击成本，但未必能从根本上解决问题。

真正的变化，更像是“把最容易被自动化利用的那部分信息收起来”，争取一点缓冲时间。这在企业风险管理上说得通。你不能因为大门再厚也可能被撬开，就干脆把门拆了。Cal.com 的选择，本质上是一种概率管理：不能保证绝对安全，但希望减少被 AI 批量化扫描和武器化利用的机会。

但代价也很明显。开源带来的透明度、社区修复能力、开发者信任和生态活力，都会打折。尤其是像 Cal.com 这种曾经把“开放”写进品牌叙事里的公司，一旦转向闭源，社区难免会问一句：你是因为安全，还是终于走到了商业现实那一步？

这不是恶意揣测，而是开源公司历史上太常见的剧情。Elastic 改许可证、HashiCorp 调整授权、Redis 生态争议不断，背后往往都夹杂着商业竞争、云厂商套利、社区贡献与公司收益不对称的问题。Cal.com 这次把主因押在 AI 安全上，确实抓住了新的时代背景，但它也不可能完全脱离开源商业模式的老难题。

留下一个 Cal.diy，是姿态，也是妥协

为了不把桥彻底炸掉，Cal.com 选择保留一个名为 Cal.diy 的开源版本，继续以 MIT 许可证开放。公司表示，生产代码库已经与公开版本明显分叉，特别是在认证和数据处理等核心系统上做了大量重写，所以现在开放出去的，更像是一个社区版、实验版、学习版。

这个安排很有意思。它既能告诉外界“我们没有背叛开源信仰”，也能把最敏感、最贴近生产环境的部分收回去。从公司治理角度看，这是很典型的折中方案：留住开发者 goodwill，同时把真正影响企业客户数据安全的核心资产圈起来。

问题是，这种“双轨制”能维持多久。一个开源项目最怕的不是收费，而是版本之间逐渐失去现实关联。若社区版越来越像演示品，企业版越来越像黑盒，开发者迟早会意识到，自己参与的不是一个共同进化的项目，而是一条被精心分流的支线。长远看，这会侵蚀社区信任。

不过从另一面讲，Cal.com 也许只是第一个把这件事公开说透的公司，而不是最后一个。很多 SaaS 产品即便表面上还保留部分开源，也早已把真正关键的控制层、身份系统、风控模块、数据管道收得很紧。AI 只是让这种趋势变得更有理由、更容易被公众接受。

这场争论，接下来不会只发生在 Cal.com 身上

Cal.com 在文中引用了一个例子：AI 在数小时内发现并生成了针对 BSD 内核一个 27 年老漏洞的可用利用代码。无论这个个案在细节上最终如何被业界消化，它传递的信号都已经很清楚——那些过去依赖“复杂、冷门、没人愿意慢慢看”的系统，正被 AI 一点点剥去幸运外衣。

这会逼着整个行业重新回答一个老问题：开源究竟是安全机制，还是风险放大器？在前 AI 时代，这个问题通常可以被一句“取决于治理质量”带过；但在今天，答案可能变成“取决于系统类型”。做基础设施的、做协议的、做标准的，开源仍然有压倒性的正当性；可一旦涉及大量真实用户数据、复杂业务逻辑和高价值目标，越来越多公司会像 Cal.com 一样，开始把透明度和攻击面放在同一个天平上衡量。

我更关心的，其实不是 Cal.com 会不会被骂“背叛开源”，而是另一个更现实的问题：如果 AI 让审计成本趋近于零，而修复和运营成本依然高昂，那么未来的安全优势，究竟属于更开放的生态，还是属于更封闭、更强控制的系统？

这道题没有简单答案。但可以确定的是，AI 已经不只是帮程序员写代码的助手了，它也正在变成站在城墙外、拿着放大镜和攻城锤的东西。过去我们总说开源是互联网世界最慷慨的发明之一，现在看来，它也许需要一套新的防御哲学，才能活得像从前那样理直气壮。