Cal.com 关闭核心代码后：AI 时代的开源与安全

我越来越坚定地支持开源，因为共享代码让社区能够在日常依赖的软件之上构建和改进。这也是 Cal.com 的公告让我担忧的原因：这家日程安排公司表示，出于对 AI 相关安全风险的担忧，将关闭其核心代码库。

Cal.com 一直是一个规模可观的全栈 TypeScript 应用示例，对学习和工具测试很有价值。我认识这个团队，也和他们讨论过这个决定。我曾希望说服他们让主项目保持开放，因此我与这场讨论有个人联系。

Cal.com 联合创始人 Bailey Pumfleet 表示，AI 可能让大规模源码分析和漏洞利用变得更容易。他宣布关闭核心代码库，同时推出一个采用 MIT 许可证的独立项目 cal.diy。这是公司对主代码库采取方式的变化，并不意味着所有开源软件都已消失。

未来开发方式的变化，也需要与先前发布的版本及其许可证区分开来。特定版本的实际权利取决于适用许可证和具体事实。我在这里担心的是今后无法持续访问主产品的开发过程，并不是说旧版本的许可自动消失。

发现漏洞传统上既需要安全知识，也需要理解正在检查的系统。我用一张简单图示把这两者结合起来。这只是思考问题的方式，不是经过测量、能够预测是否发现漏洞的数学公式。

访问源码可以帮助审查者理解组件之间的关系。AI 工具也可能帮助分析不熟悉的代码，让人探索更多潜在问题。但有了源码或模型并不会自动产生有效漏洞利用：上下文、测试、配置和人的判断仍然重要。

我请观众给自己从事安全研究的信心打分，许多人给出了较低分数。这只是非正式的聊天投票，不能证明 TypeScript 能力与安全能力负相关，也不能代表整个开发者群体。它只是说明我担心这两类专长不容易结合。

我的假设是，更强的编码模型可以降低理解代码库和调查安全问题的部分门槛。我用示意数字说明这一点，但这些并非实验测得的阈值。实际需要多少专业知识和时间，取决于目标以及工具的可靠性。

Anthropic 报告称，Claude Mythos Preview 在安全研究中发现了一个已有 27 年历史、现已修复的 OpenBSD 漏洞。OpenBSD 是 BSD 操作系统，并非 Linux 发行版。这是工具辅助发现漏洞的具体例子，不代表所有系统都同样暴露：https://www.anthropic.com/research/mythos-preview。

研究中使用代理从多个起点检查代码库。我对此感到担忧，因为它可以扩大代码审查范围，而不必由人逐一手动阅读每个文件。模型的发现仍需要验证：一个候选问题不等同于已确认且可利用的漏洞。

我认为关闭源码可能在一段时间内增加某些分析的难度，但这不是安全保证。公开客户端和暴露的接口可能揭示系统的一部分，而外部审查者也不会因此自动获得私有服务端代码。

我预测，分析和逆向工程能力的提高可能减少隐藏代码带来的优势。这是预测，没有经过验证的时间表。开源与闭源系统各有不同的暴露面和审查条件；仅凭标签都不能确定具体部署是否安全。

时间和成本也很重要。自动化工具可以持续工作、探索许多可能性，从而改变攻击和防御审查的经济条件。结果取决于访问权限、验证、运行控制和人员，而不只是一个人能运行多少代理。

Tanner Linsley 认为，关闭项目也可能减少善意开发者检查和加固代码的机会。我认为这一点很重要，同时也理解负责客户数据的公司为什么担心漏洞被快速发现。暴露风险和失去共享审查的代价都值得考虑。

防御工具也在进步。我提到一个旨在帮助组织加固代码的安全模型，并把这种情况比作攻击者与防御者之间的竞赛。视频录制时的访问方式和能力只是当时的快照，不是当前产品指南。

Drew Breunig 的文章用经济意义上的“工作量证明”来描述这个问题：安全团队和攻击者都会花资源寻找弱点。文章见 https://www.dbreunig.com/2026/04/14/cybersecurity-is-proof-of-work-now.html。我认为这个框架有启发性，但它是类比，不是普适的安全定律。

计算挑战可以提高自动化滥用的成本，但不能证明请求者是真人，也可能增加正常用户的负担。同样，更多分析预算可以帮助防御者，但支出超过攻击者本身并不能保证发现或修复每个漏洞。

英国 AI Security Institute 在“The Last Ones”这一模拟的 32 步企业网络挑战中评估了 Mythos Preview，并报告 10 次尝试中有 3 次完全成功。这是特定设置下的受控评测，不是模型针对任意真实组织的成功率。

图表比较了累计 token 预算与达到的步骤，文章讨论了每次尝试 1 亿 token 的上限，并称模型在测试范围内仍能取得进展。这一观察不能证明更高预算下会无限进步，也不能得出现实防御支出的简单公式。

支持开源的一个理由是，依赖同一库的组织可以共享发现和修复。贡献到上游的修复可能惠及许多用户，而各自维护的副本需要分别处理。这种好处取决于维护者是否有时间和资源评估并合并工作。

另一方面也有相反的风险：广泛使用的依赖可能成为更有价值的目标，因为一个弱点可能影响大量下游用户。共享审查和高人气都不能保证安全。负责任的披露、及时更新和谨慎管理依赖仍然重要。

文章提出把开发、代码审查和安全加固分成不同阶段。这可以让责任与支出更清晰，但安全也应贯穿整个生命周期的设计和实现。最后做一次扫描无法弥补所有架构或运行问题。

更多自动化报告也给开源维护者带来了额外负担。我谈到围绕 FFmpeg 某个漏洞报告的分歧，并认为有效发现值得重视。具体案例的严重程度和过程应依据技术记录判断；维护者也必须花时间筛选误报并协调修复。

安全报告只有在有人能够复现、评估并修复时才真正有用。研究人员应通过项目适当的披露渠道提供清晰证据；从共享软件受益的组织也应帮助资助维护和保障软件安全的人。

我理解 Cal.com 对保护客户的担忧，但仍为主项目关闭而遗憾。我的观点是，尤其在安全工作的成本上升时，开源仍值得支持。解决问题需要持续维护与协作，不能假定开放或保密中的任何一方会自动解决安全问题。

支持你所依赖的项目，帮助维护者应对真实的安全发现。我们应认真看待 AI 带来的安全风险，同时不必因此宣布开源已经过时。