Cal.com 转向闭源:开源安全面临深度清算

2 阅读7分钟

\n\n调度基础设施初创公司 Cal.com 宣布核心代码闭源。官方称 AI 技术的进步使得识别开源代码漏洞更简单,为保障安全必须减少代码暴露,这一举措引发了对开源安全性的深度审视。

译自:Cal.com goes private: A security reckoning for open source

作者:Paul Sawers

Cal.com 是一家为开发者和企业构建调度基础设施的开源初创公司,其于周二宣布,鉴于 AI 进步带来的日益严峻的安全隐患,它将把其核心代码库转为闭源。

关于 AI 对开源项目日益增长的影响 已有很多报道,原本就时间紧迫的维护者正在与大量伪装成贡献的机器生成的“AI 垃圾内容”作斗争。但是,能够系统性发现软件漏洞的 AI 系统的出现,将对话推向了一个更严肃、以安全为中心的方向。

Anthropic 最近发布了 Claude Mythos,这是一个实验性系统,据称它可以识别并利用广泛使用的软件中的漏洞——包括 OpenBSD 中一个已有 27 年历史的缺陷。OpenBSD 是一款专注于安全的类 Unix 操作系统,长期以来被认为是同类中最稳固的系统之一。

虽然其能力目前仅通过 Project Glasswing 提供给选定的合作伙伴,但其影响已经显现。对于围绕开源代码构建的公司来说,透明度与安全性之间的权衡正面临新的审视。

“如果你有了金库的蓝图,抢劫银行就会变得更容易。”

Cal.com 是首批对这一转变采取行动的公司之一。CEO 兼联合创始人 Bailey Pumfleet 告诉 The New Stack,代码的可见性越高,系统就越容易受到攻击。

“如果你有了金库的蓝图,抢劫银行就会变得更容易,”Pumfleet 说道。“观察事物的内部运作并对其进行逆向工程以发现漏洞要容易得多。”

当被问及这种风险是归结于可见性还是代码维护方式时,Pumfleet 表示两者都是因素——但开放性确实显著增加了暴露风险。

“单纯地开放代码就会大幅增加风险,”他说道。“这不仅仅是关闭代码或加固代码的问题;而是我们要两者兼顾。单纯的加固不足以降低风险。”

“开源版的 Calendly”

成立于 2021 年的 Cal.com 致力于构建 Calendly 的开源替代方案,为开发者提供一种将调度功能直接嵌入到自己应用程序中的方法。

公司无需从头构建预订系统,而是可以利用 Cal.com 的基础设施来处理从会议链接到可用性管理的一切事务。其理念是将调度视为基础设施——可以插入到其他产品中,而不是作为独立工具使用。

Cal.com 运行中

Cal.com 运行中

该公司已从风险投资和天使投资人手中筹集了超过 3000 万美元,包括 Reddit 联合创始人 Alexis Ohanian 的公司 Seven Seven Six 和 YouTube 联合创始人 Chad Hurley。

与大多数商业开源初创公司一样,提供源代码供人们研究和测试的一大卖点是,它允许开发者验证系统的工作方式,根据自己的需求进行调整,并在自己的基础设施上运行。

在“左版 (copyleft)”GNU Affero 通用公共许可证 (AGPL) 下可用,Cal.com 允许用户这样做——但规定任何修改软件并将其作为服务运行的人必须公开这些更改。

但随着时间的推移,支撑 Cal.com 托管平台的代码库已开始与公开代码库产生分歧,越来越多的商业和企业功能是在开源仓库之外开发的。现在,这种分离变得明确了。

分歧的抉择

Cal.com 并没有完全移除其开源项目,而是在其公开分享的内容和在生产环境中运行的内容之间划分了界限。

伴随着这一转变,该公司发布了 Cal.diy,这是其平台的开源版本,现在采用宽松的 MIT 许可证。虽然它保留了核心调度引擎和预订基础设施,但一系列与商业产品相关的的功能已被移除,包括团队管理、工作流、分析和企业级身份验证。

Cal.com 正是在其公开分享的内容和在生产环境中运行的内容之间划分了界限。

实际上,这为业余开发者提供了一个可自托管的平台版本,而驱动 Cal.com 托管服务的代码(以及该产品的未来开发)现在则存放在一个封闭的仓库中,远离自动化扫描器的窥视。

这一举措正式确定了已经开始出现的界限。Cal.com 表示,最近几个月一直在公共代码库之外重写关键组件,开源项目已与生产中使用的系统产生分歧。

“我们只是想保留 Cal.diy,以此作为向社区免费提供的一种方式,并以尽可能宽松的许可证进行分享。”

“Cal.diy 是 Cal.com 的核心部分,处理所有的调度,只是剥离了所有的企业功能,”Pumfleet 说道。“话虽如此,我们的代码库此后已经与开源版本脱钩,因为我们重写了身份验证和数据处理等关键安全部分。我们只是想保留 Cal.diy,以此作为向社区免费提供的一种方式,并以尽可能宽松的许可证进行分享。”

是为了安全,还是另有所图?

Cal.com 将此举完全定位为对不断变化的安全形势的回应,认为 AI 的进步使得识别和利用公开代码中的漏洞变得更加容易。

最近一波由 AI 驱动的漏洞研究,包括 Anthropic 的 Mythos 项目,使这些担忧成为了焦点。但 Cal.com 联合创始人兼董事长 Peer Richelsen 告诉 The New Stack,远离开源开发的决定其实早就在进行中。

“我们在 Claude Mythos 和 OpenBSD 漏洞宣布之前很久就做出了这个决定,但时机令人心惊,”Richelsen 说道。

与此同时,Pumfleet 表示,公司已经看到了“黑客攻击成本的大幅下降”,以及一波在开源项目中寻找漏洞的新型 AI 扫描器的出现。

因此,将其核心平台转为闭源提出了一个显而易见的问题:鉴于 Cal.com 最初的宗旨是作为 Calendly 的开源替代方案,这样做是否有疏远客户的风险?

“我们已经与一些内部客户进行了交谈,他们只是很感激我们正在采取措施,以最佳方式保护他们的数据,”Pumfleet 说道。“我不认为会有大量客户因此而离开,因为最终客户更关心数据的安全性,而不是某样东西是否开源。”

Cal.com 还确认,目前正在自托管的客户在过渡期间将被提供访问私有、本地 GitHub 仓库的权限。

“我确实知道很多其他拥有类似背景的商业开源公司正在重新评估开源。”

这样的举动并非没有先例。早在当前这波由 AI 驱动的安全担忧之前,建立在开源基础上的公司就已经转向了更具限制性的模式——这通常是对商业压力的回应,从限制云服务商的使用到加强对变现的控制。这通常涉及剥离企业功能、更改许可证或限制对其部分代码库的访问。

那么,这段历史提出了一个更广泛的问题:Cal.com 的举动是否预示着开源的新现实,还是公司只是在以不同的理由遵循熟悉的剧本?

就 Pumfleet 而言,他拒绝了此举是为了加强控制的观点。

“这个决定完全是出于安全考虑,”Pumfleet 说道。“我们已经拥有了对开源产品的控制权,闭源并不能让我们获得太多额外利益。这纯粹是关于在安全方面降低风险。”

Richelsen 持更广泛的观点,认为这个问题远远超出了 Cal.com 的范畴。“我们认为任何开源应用都处于风险之中,应该将应用的所有部分或敏感部分转为私有,”他说道。

Pumfleet 表示,其他人可能会效仿:“我确实知道很多其他拥有类似背景的商业开源公司正在重新评估开源,”他说道。全 端 工智能