2013 年棱镜门爆发后不久，Linux 基金会执行董事Jim Zemlin接受采访时说了一句很有底气的话：开源天然安全，Linux 没有后门。

他的理由是代码公开，几千名开发者盯着看，恶意改动很难不被发现。当时很多人都认同这个说法——大家正对闭源系统的黑箱感到不安。

13 年后再看，我觉得 Zemlin 的方向大致没错，但这个论断的成立条件比当时想象的要苛刻得多。

代码公开只是起点，真正的安全来自持续的审查、清晰的责任和有效的兜底机制。

当时的两个核心假设

Zemlin 的自信主要建立在两个假设上。

第一，代码公开就等于可审计。源码摆在那儿，理论上谁都能看，总有人会发现问题。

第二，社区规模够大，监督就够强。人多眼杂，恶意代码应该混不进来。

这两个假设听起来很有道理，但它们都忽略了一个关键现实：审计是需要真实成本的。代码公开不等于有人真的在看，看了也不等于看得及时，看得及时也不等于问题能被快速修复和分发。

透明本身不产生安全，审查行为才产生安全。

透明并没有消灭漏洞

后来的事实反复打了脸。

2014 年的 Heartbleed 漏洞在 OpenSSL 里隐藏了两年，影响了全球大量服务器。代码一直是公开的，但没人及时发现。

类似的还有 Linux 内核的dirty COW（潜伏近 9 年），以及 2021 年的Log4Shell。2024 年的xz-utils 后门事件更直接：有人长期潜伏向开源项目植入后门，最终是一个微软工程师因为 sshd 登录变慢才偶然发现的。

这些案例没有推翻开源本身，但清楚地说明了一点：代码看得见，不代表真的有人在认真看。

从“透明”转向”治理”

当透明不足以保证安全时，问题就自然转向了治理层面。

最基础的是SBOM（软件物料清单），至少要知道自己用的到底是哪些依赖。进一步还需要签名验证和可重复构建，确保下载的二进制确实来自公开源码。

更现实的挑战在于维护者结构。很多关键项目长期依赖少数甚至单个维护者，企业大量使用却很少提供人力或资金支持。xz-utils 后门就把这个结构性风险暴露得非常清楚。

治理还包括激励机制、责任分散、漏洞响应速度等。透明让问题变得可见，但真正解决问题，还是得靠持续的治理动作。

AI 时代让事情更复杂

现在的情况还在继续恶化。

AI 代码生成工具大量使用后，代码的来源和许可证边界变得模糊。你能审计人类写的代码，但很难完全审计 AI 生成的部分。

开源大模型也带来类似问题。权重文件可以公开下载，但权重不等于行为可解释。模型的行为是否可解释、训练数据是否有污染、是否存在隐藏的后门，远不是看代码就能解决的。

AI Agent 自动提交 PR、自动修复漏洞的时代，责任归属也会变得更加模糊。

真正该做的事

完全审计所有依赖对大多数人和企业来说都不现实，但有一些基础动作还是可以先做起来：

• 引入依赖前看看维护者是谁、更新频率如何；
• 生成并保留 SBOM，出事时至少知道从哪里查起；
• 对关键组件做签名验证，不要完全信任包管理器；
• 定期关注 CVE 和安全公告。

这些事情不能消灭风险，但至少能先解决“不知道自己用了什么”这个最基础的问题。

公开是起点，不是终点

Zemlin 当年的判断没有完全错，开源的透明度确实是优势。但他和当时的很多人一样，低估了把透明转化为真实安全的难度。

开源安全从来不是”代码公开就安全了”这么简单。它需要透明 + 治理 + 合理的经济激励 + 对 AI 时代新风险的应对。

代码公开只是第一步。后面还有很长的路要走，而这条路，需要更多人真正去负责。