我们为什么开源了我们的安全项目

当 Nathaniel McCallum 和我着手进行现在名为 Enarx 的项目时，我们在一开始就做出了一个决定：Enarx 的代码将是开源的，这一立场得到了我们的雇主 Red Hat 的全力支持（请参阅我的博客上的标准免责声明）。全部开源，并且永远开源。

这是一个我们从未后悔过的决定，也是我们坚持的原则。当我们有足够的代码进行演示并准备展示时，我们就在 GitHub 上创建了一个存储库并将其公开。有一个非常小的例外，那就是即将推出的芯片功能的一些细节是根据 NDA¹ 与我们共享的，发布我们可能为它们编写的任何代码都将违反 NDA。但是，在适用这种情况（这种情况很少发生）时，我们绝对清楚地向供应商表明，我们打算尽快开源代码，并且我们游说他们尽早发布详细信息（这可能比他们希望的要早），以便更多专家可以查看他们的设计和我们的代码。

可审计性和信任

这使我们想到了使 Enarx 开源的最重要的原因：可审计性和信任。Enarx 是一个与安全相关的项目，我坚信不仅 安全应该在开放的环境中进行，而且如果有人真的要将他们的敏感数据、算法和工作负载信任给一个软件，那么他们希望尽可能多的专家查看、审查、批评和改进它，无论是运行该软件的人、他们的员工、承包商，还是（更好的是）更广泛的安全社区。检查代码的人越多，您就越应该 信任它。这对于任何安全软件都很重要，但对于像 Enarx 这样的软件来说，这至关重要，Enarx 旨在保护您最敏感的工作负载。

捕捉漏洞

Enarx 中存在漏洞。我知道：我正在编写一些代码，² 而且我昨天发现了一个（我放进去的），就在我即将进行演示的时候。³ 编写完美的代码非常非常困难，我们知道，如果我们开源我们的源代码，那么更多的人可以帮助我们修复问题。

共同体

对于 Nathaniel 和我来说，开源是一个道德问题，对此我们毫不歉意。我认为对于 Enarx 团队的大多数人（如果不是全部）来说，情况也是如此。这包括许多 Red Hat 员工（请参阅标准免责声明），因此这不应该令人感到意外，但我们也有来自许多背景的非 Red Hat 贡献者。我们认为 Enarx 应该是一项公共利益，并为外部知识产权的 共同体做出贡献。

更多脑力

开源某物不仅使其更容易修复错误：它还可以提高您生产产品的质量。您应用于问题的脑力越多，您制造出优秀产品的机会就越大——前提是脑力得到有效应用（这并非总是易事！）。在最近的一次设计会议上，一位参与者在会议结束时说：“我相信我可以实现其中的一些内容，但我对这个主题了解不多，我担心我没有为这次讨论做出贡献。” 事实上，他们通过提问和澄清一些要点做出了贡献，我们向他们保证，我们希望吸纳经验丰富的资深开发人员，以利用他们的专业知识和知识，并找出假设并验证设计，而不是因为我们期望每个人都成为项目所有部分的专家。

让聪明人在设计和编码中参与进来，可以传播专业知识和知识，并有助于防止工作变成孤立的、与世隔绝的“象牙塔”式构建，很少有人理解，几乎不可能验证。

不仅仅是代码

我们在开源领域所做的不仅仅是编码。我们在开源中管理我们的架构、我们的设计会议、我们的协议设计、我们的设计方法论、⁴ 我们的文档、我们的错误跟踪、我们的聊天、我们的 CI/CD 流程：所有这些都是开源的。唯一的例外是我们的 漏洞管理 流程，该流程需要在有限的时间内进行机密曝光。以下是您可以找到我们资源的地方

• 代码
• Wiki
• 设计在 wiki 和 征求意见 仓库中
• 问题 和 拉取请求
• 聊天 （感谢 Rocket.chat！）
• CI/CD 资源感谢 Packet！
• 站立会议

我们也非常重视多样性，项目贡献者受 贡献者盟约行为准则 的约束。

简而言之，Enarx 是一个开放的项目。我确信我们可以做得更好，我们也将为此而努力，但我们的基本原则是，开放总体上是好的，并且对于安全至关重要。如果您同意，请来访问！

1. 保密协议
2. 令团队中的许多人（包括我自己）感到惊讶的是。至少它不是用 Perl 编写的。
3. 我修复了它。诚然，是在演示之后。
4. 我们刚刚转向 sprint 模式，其详细信息是我们公开设计和同意的。

本文最初发表在 Alice, Eve, and Bob 上，并经作者许可进行改编和转载。