David Wheeler 是一位长期领导者，为美国政府在与开源软件相关的问题上提供咨询和工作。他的个人网页是关于开放标准、开源软件和计算机安全的常用参考资料。David 正在领导一个新项目，CII 最佳实践徽章项目，该项目是 Linux 基金会的 核心基础设施倡议 (CII) 的一部分，旨在加强开源软件的安全性。在本次访谈中，他谈到了这对政府和其他用户意味着什么。
让我们从一些基本知识开始。什么是徽章项目？它是如何产生的？
2014 年，在 OpenSSL 密码库中发现了心脏出血漏洞。作为回应，Linux 基金会创建了核心基础设施倡议 (CII)，以资助和支持作为全球信息基础设施关键要素的开源软件 (OSS)。CII 已经识别并资助了特定的重要项目，但它无法资助所有 OSS 项目。因此，CII 也在资助一些普遍提高 OSS 安全性的方法。
最新的 CII 项目专注于普遍提高安全性，即最佳实践徽章项目。我是该项目的技术负责人。我们认为，遵循最佳实践的 OSS 项目更有可能保持健康并产生更好的软件，包括具有更好的安全性。但这需要人们知道这些最佳实践是什么，以及给定的项目是否遵循了这些实践。
为了解决这个问题，我们首先查阅了大量文献和 OSS 项目，以确定一套广泛接受的 OSS 最佳实践。然后，我们开发了一个网站，OSS 项目可以在该网站上报告他们是否应用了这些最佳实践。在某些情况下，我们可以检查项目的网站并自动填写一些信息。我们使用这些信息（自动和非自动）来确定项目是否充分遵循了最佳实践。如果项目充分遵循了最佳实践，则该项目将获得“通过”徽章。
我应该在此指出，徽章项目本身就是一个 OSS 项目。您可以在 其项目站点 上查看。我们非常希望得到更多参与，所以请加入我们！为了回答显而易见的问题，是的，它确实获得了自己的徽章。其他获得徽章的 OSS 项目包括 Linux 内核、curl、Node.js、GitLab、OpenBlox、OpenSSL 和 Zephyr。相比之下，心脏出血漏洞之前的 OpenSSL 未能满足许多标准，这表明这些标准抓住了关于项目的重要因素。
如果您参与 OSS 项目，我鼓励您获得徽章。如果您正在考虑使用 OSS 项目，我鼓励您查看该项目是否具有徽章。您可以在 CII 最佳实践徽章计划 中查看更多信息。
您能告诉我更多关于徽章标准的信息吗？
当然。当然，没有任何一套实践可以保证软件永远不会有缺陷或漏洞。但是，一些实践鼓励良好的开发，从而提高质量的可能性，而这正是我们关注的重点。
为了制定标准，我们审查了许多关于 FLOSS 项目应该做什么的文件；最具影响力的来源可能是 Karl Fogel 的著作 Producing Open Source Software。我们还研究了许多现有的成功项目。我们还从包括 Karl Fogel、Greg Kroah-Hartman（Linux 内核）、Rich Salz（OpenSSL）和 Daniel Stenberg（curl）在内的大量人员那里获得了对标准草案非常有帮助的评论。
一旦确定了初始标准，就将其分为以下几类：基本知识、变更控制、报告、质量、安全和分析。我们最终得到了 66 个标准。每个标准都有一个标识符和文本。例如，标准 floss_license 要求，“软件必须作为 FLOSS 发布。”标准 know_common_errors 要求，“至少一位主要开发人员必须知道导致此类软件中漏洞的常见错误类型，以及至少一种对抗或减轻每种错误类型的方法。”这些标准在线提供，LWN.net 的一篇文章更详细地讨论了这些标准。典型的 OSS 项目只需大约一个小时即可填写表格，部分原因是我们会自动填写一些信息。如果能有更多帮助来自动化此过程，将不胜感激。
随着徽章项目获得更多反馈以及使用的最佳实践集发生变化，这些标准将缓慢变化，可能每年变化一次。我们还打算在当前的“通过”级别之上添加更高的徽章级别，暂定名为“金牌”和“白金”级别。但是，项目团队决定分阶段创建标准；一旦我们对当前的标准集有了经验，我们就更有可能创建好的标准。一些拟议的更高级别标准的列表已经发布；如果您有任何想法，请发布问题或加入徽章项目邮件列表。
在深入研究这个领域时，您的发现中最令您惊讶的是什么？
也许最令人惊讶的是，许多 OSS 项目没有描述如何报告安全漏洞。当然，许多项目都描述了。许多项目，例如 Mozilla Firefox，描述了如何向专用电子邮件地址报告漏洞，并提供了用于发送加密电子邮件的 PGP 密钥。一些项目，例如 Cygwin，制定了明确的政策，即所有缺陷报告都必须公开报告（在他们的情况下是通过邮件列表），并且他们明确禁止通过私人电子邮件报告。我不喜欢“一切公开”政策（因为它们可能会让攻击者抢占先机），但是当每个人都知道规则时，就更容易处理漏洞。但是，许多项目根本没有告诉人们如何报告漏洞。这导致了很多问题。安全研究人员应该使用公共问题跟踪器或邮件列表报告漏洞，还是做其他事情？如果项目希望使用加密接收私人报告，应该如何加密信息？应该使用哪些密钥？如果项目没有提前考虑漏洞报告和处理，则可能会减慢漏洞报告和处理的速度。
对此感到惊讶有几个原因。首先，开发人员没有预料到他们的代码中存在漏洞，并且他们应该准备好解决这些漏洞，这应该令人惊讶。新闻中充斥着漏洞报告！其次，提前解决这个问题非常容易；只需在项目网站上解释如何报告漏洞即可。只需要一到三句话！当然，写下这些内容需要项目成员思考他们将如何处理漏洞，这很有价值。最好在漏洞报告之前决定如何处理漏洞。
什么没有让您感到惊讶，但可能会让其他人感到惊讶？
一些可能让您感到惊讶的事情是：
1. 仍然有一些项目（主要是较旧的项目）不支持公共版本控制存储库（例如，使用 Git），这使得其他人难以跟踪更改或协作。
2. 仍然有一些项目（主要是较旧的项目）没有（有用的）自动化构建或自动化测试套件。这使得改进变得更加困难，并且更容易让缺陷溜过检测。当在依赖项中发现漏洞时，这也使得升级依赖项变得困难，因为没有简单的方法来验证更改几乎肯定无害。
3. 许多项目（主要是较新的项目）被许多人认为是 OSS，但由于它们根本没有许可证，因此使用它们是不合法的。在大多数国家/地区，没有许可证或其他标记的软件通常无法合法使用、分发或修改。这在 GitHub 上尤其是一个问题。Ben Balter 在 2015 年的演示文稿 Open source licensing by the numbers 中发现，在 GitHub 上，拥有 1,000 颗或更多星标的项目中，有 23% 的项目根本没有许可证。诚然，在 1976 年之前，美国没有附加版权标记的作品不受版权限制，但那已经是很久以前的事了。如今，几乎所有国家的法律都要求开发人员在软件可以被他人合法使用之前对其进行许可，而且这种情况不太可能改变。即使您认为法律不适用于您，省略 FLOSS 许可证也往往会抑制项目使用、共同开发和审查（包括安全审查）。
4. 大多数开发人员仍然不知道开发安全软件的基本原则，也不知道导致漏洞的常见错误是什么。
我们希望徽章计划将有助于解决这些问题。
对于在开源软件使用方面遇到困难的政府而言，这项倡议有哪些经验教训？
大型组织分为两种：一种是知道自己正在使用 OSS 的组织，另一种是不知道自己正在使用 OSS 的组织。没有第三种。如果您为专有软件许可证付费，如果您查看内部，您会发现几乎所有专有软件中都有大量 OSS。定制软件通常建立在 OSS 之上并由 OSS 构建。
许多管理者都在苦苦挣扎，因为他们不了解计算机行业已经发生的变化，即 OSS 是计算领域的一支主要力量，并且将长期存在。仍然有一些管理者没有拥抱变革，而是想假装变革没有发生，或者试图回到某些神话般的“美好旧时光”，而这些时光实际上并没有那么美好。对于那些试图阻止所有 OSS 使用的人，我建议一种简单的补救方法：停止试图让时光倒流，而是拥抱已经发生的变革。
另一种挣扎是那些部分接受这一现实，但想要管理风险却不知道如何管理的人。目标是正确的，但他们的方法通常是误导性的。我反复听到“但是你不知道谁开发了 OSS”，例如。在大多数情况下，这是错误的，因为谁编写了每一行通常都是公开记录（它包含在版本控制系统数据中）。荒谬的是，这些人很乐意接受专有软件，即使他们不知道是谁编写的代码。一个相关的问题是，许多人希望使用公司的注册地点作为恶意代码的唯一风险衡量标准，这是一个错误。例如，一家公司可能在美国注册，但这并不意味着其开发人员和测试人员都在美国或都是美国公民。公司注册就像船舶注册；这是一种与现实无关的法律虚构。此外，您可能是某个国家的公民，但仍然可以创建恶意代码来攻击该国政府。“这是否来自我国的公司”之类的简单测试对于管理风险没有太大帮助；我们需要更好的方法。
对于那些希望引入 OSS，但也希望管理其风险的人来说，这项倡议肯定会提供一些帮助。我们专注于各种更可能产生良好软件的最佳实践，而不是专注于公司注册等法律虚构。潜在用户可以通过徽章项目了解最佳实践以及特定项目的表现。
当然，最佳实践徽章项目无法解决所有问题。我们无法告诉您某个给定的 OSS 是否会解决您的问题；只有您才能了解您的需求。有许多不同的 OSS 支持模型；在某些情况下，简单的下载并依赖社区是一种好方法，而在另一些情况下，您真的应该使用一家提供专业支持的公司。我们正在努力提供人们做出更好决策所需的一些信息。
另一方面，当我们上次交谈时，您表示美国政府分叉项目的风险仍然是一个大问题。您今天对此有何看法？
首先，快速澄清一下。我使用术语“分叉”来表示任何复制项目并打算修改它的行为。如果您计划将修改提交回主项目，则分叉非常好。问题是“项目分叉”，即旨在创建一个新的独立项目的分叉。项目分叉会抑制协作，而不是鼓励协作，这就是项目分叉成为问题的原因。
美国政府不跟踪其资助的项目分叉，因此我无法自信地回答这个问题。从轶事来看，我认为这个问题略有减少，但仍然是一个大问题。公共存储库（尤其是在 GitHub 上）的日益普及有助于减少政府资助项目中的项目分叉。公共存储库以及预期将使用公共存储库的期望大大提高了透明度。如果一家公司知道它将被迫公开其项目分叉，它将正确地担心它可能会被要求为站不住脚的事情辩护。套用路易斯·德姆比茨·布兰代斯大法官的话，透明度通常是最好的消毒剂。此外，如果政府强迫公司将其项目分叉作为 OSS 提供，则项目分叉的一些经济激励就会消失，并且其改进可能会合并回主项目（称为“修复”分叉的过程）。
也就是说，政府中仍然存在太多不正当的激励。一个明显的例子是，如果承包商从头开始开发软件而不是重用现有软件，他们可以获得明显更高的利润。许多项目重新发明轮子，因为他们为此获得了报酬，而纳税人承担了费用。
更严重的是，供应商知道，如果他们能够将其客户锁定在他们的产品中，他们就可以勒索高出几个数量级的资金。如果没有办法逃脱产品或服务，供应商就可以不断提高价格而没有任何限制，并且供应商没有动力提供新技术或良好的支持。政府的整个采购系统都假定工作和未来工作存在公开竞争，理论上这提供了一种制衡力量。但在实践中，情况往往并非如此。
在计算中，数据权（也称为知识产权或技术数据权）是权力的同义词。除非您拥有数据权，否则您无法更改软件，也无法对未来的替代维护者进行竞争性投标，即使您最初为该软件的开发付费。然而，许多政府雇员并不理解这一点。承包商理解这一点，并且受到激励去利用天真的政府雇员，他们不理解这一点。数据权可以说是比需求重要得多，因为需求不断变化，而数据权决定了谁可以修改软件以响应新的需求。承包商甚至会要求对软件拥有专有权，即使他们没有支付大部分开发费用，或者使用诸如创建专有的“通信总线”之类的技巧，其主要目的是将政府锁定在该承包商中。如果承包商获得专有权，那么政府将永远失去对其维护进行有效竞争的能力。同样，第三方软件供应商通常具有专有接口，或者创建标准接口的专有扩展，以阻止用户更换为竞争供应商。这并不是说所有承包商或第三方供应商都是邪恶的，或者所有政府雇员都是无知的；远非如此。政府需要这些人！但是，不正当的激励，加上政府方面的天真，往往会导致政府被锁定在承包商或第三方供应商中的情况，然后他们可以对不良结果收取任意价格。我猜测，如果政府真的能够对软件进行充分和公开的竞争，它每年至少可以节省数百亿美元。确切的数字不如问题重要；我们显然有一个需要解决的问题。
我认为，对此有很大帮助的是要求使用政府资金开发的软件以开源软件的形式向公众发布，除非有令人信服的理由不这样做。这将大大减少从头开始重新创建一切或试图将政府锁定在单个承包商中的动机。我们也可能希望对那些未能进行市场调查以寻找替代方案的人处以经济处罚；这是法律和合同要求的，但通常没有做到。我确信还有其他应该做的事情；关键是当前系统存在许多问题。
与美国政府有关的人员还应该了解哪些其他事情？
正如我上次提到的，最大的问题之一是大多数采购人员不理解几乎所有 OSS 都是商业软件。根据美国法律、《联邦采购条例》(FAR) 和《国防部 FAR 补充条例》(DFARS)，如果软件具有非政府用途并已获得公众许可，则该软件是商业软件。特别是，请参阅美国法典第 41 篇第 103 条，该条定义了术语“商业项目”。
由于几乎所有 OSS 都符合商业软件的定义，因此几乎所有 OSS 都是商业软件。一旦您理解了这一点，您就会理解，要使用 OSS，您只需遵循商业软件的规则，并且美国法律对商业项目的偏好 (10 USC 2377) 包括 OSS。这种理解使许多决策变得非常简单明了，但这仍然没有被广泛理解。
David A. Wheeler 为国防分析研究所 (IDA) 工作，但在本次访谈中，他不代表 IDA、美国政府或 Linux 基金会发言。
评论已关闭。