条款讨论

没有一套实践可以保证软件永远不会有缺陷或漏洞。即使是形式化方法，如果规范或假设错误也可能失败。也没有任何一套实践可以保证项目将维持一个健康且运作良好的开发社区。

然而，遵循最佳实践可以帮助改善项目的成果。例如，一些实践能够在发布前进行多人审查，这既有助于发现其他难以发现的技术漏洞，又有助于在来自不同组织的开发者之间建立信任并促进重复互动的意愿。

本页讨论为开源安全基金会（OpenSSF）最佳实践徽章开发的自由/开放源代码软件（FLOSS）项目的最佳实践集。遵循这些最佳实践的项目将能够自愿自我认证并展示他们已获得相关徽章。项目可以免费使用Web应用程序（BadgeApp）来解释他们如何满足这些实践及其详细条款。

这些最佳实践的创建是为了：

  1. 鼓励项目遵循最佳实践，
  2. 帮助新项目发现这些实践是什么，以及
  3. 帮助用户了解哪些项目正在遵循最佳实践（以便用户可以优先选择这些项目）。

"最佳实践"这个成语的意思是"在一个组织、行业等中被优选或视为标准的程序或一套程序"（来源：Dictionary.com）。这些条款是我们认为在更广泛的FLOSS社区中被广泛"优选或视为标准"的内容。

有关这些条款如何制定的更多信息，请参阅OpenSSF最佳实践徽章GitHub网站。

您也可以查看完整条款。

标准结构

最佳实践条款分为三个级别：

  • 通过侧重于运行良好的FLOSS项目通常已经遵循的最佳实践。获得通过徽章是一项成就；在任何时候，只有约10%追求徽章的项目达到通过级别。
  • 银级是比通过更严格的一套条款，但预计小型和单一组织项目可以实现。
  • 金级甚至比银级更严格，包括小型或单一组织项目无法实现的条款。

每个条款都有一个简短的名称，在条款文本后的方括号内以上标文本显示。

与其他项目的关系

Linux基金会还赞助OpenChain项目，该项目确定"高质量自由和开源软件（FOSS）合规计划"的条款。OpenChain专注于组织如何最好地使用FOSS并为FOSS项目做出贡献，而OpenSSF最佳实践徽章专注于FLOSS项目本身。OpenSSF最佳实践徽章和OpenChain共同努力，帮助改进FLOSS以及FLOSS的使用方式。

标准自动化

在某些情况下，如果项目遵循标准惯例并托管在具有良好API支持的网站（例如GitHub）上，我们会自动测试并填写信息。

我们打算在未来改进这种自动化。欢迎改进自动化的贡献！

然而，我们有意优先考虑"什么是重要的"，即使无法负担得起自动化。我们喜欢自动化测量，但并非所有重要的事情都可以自动化或可以负担得起自动化。

随着时间的变化

我们预计这些实践及其详细条款将随着时间的推移而更新。我们计划添加新条款，但将其标记为"未来"条款，以便项目可以添加该信息并保持其徽章。

非常欢迎通过GitHub网站以问题或拉取请求的形式提供反馈。还有一个用于一般讨论的邮件列表。

关键词

本文档中的关键词"MUST"、"MUST NOT"、"SHOULD"、"SHOULD NOT"和"MAY"应按照RFC 2119中的描述进行解释。添加了附加术语SUGGESTED。总之，这些关键词具有以下含义：

  • 术语"必须"（MUST）是绝对要求，"禁止"（MUST NOT）是绝对禁止。
  • 术语"应该"（SHOULD）表示通常要求的标准，但在特定情况下可能存在忽略它的合理理由。但是，在选择不同的方案之前，必须理解并仔细权衡其全部影响。
  • 术语"建议"（SUGGESTED）用于代替"应该"（SHOULD），当必须考虑该标准时，但不这样做的合理理由比"应该"更常见。
  • 术语"可以"（MAY）提供了一种可以做某事的方式，例如，明确所描述的实现是可接受的。

标准通常表述为应该（SHOULD）做某事，或者建议（SUGGESTED），因为实现可能困难或成本可能很高。

获得徽章

要获得徽章，必须满足所有"必须"（MUST）和"禁止"（MUST NOT）标准，所有"应该"（SHOULD）标准必须满足或提供不满足的理由，并且必须考虑所有"建议"（SUGGESTED）标准（必须评级为满足或不满足，但除非另有说明，否则不需要理由）。在允许的情况下，N/A（"不适用"）的答案被视为满足。在某些情况下，特别是在较高级别的徽章中，可能需要理由和/或网址（URL）。

某些标准具有影响此要求的特殊标记：

  • {N/A allowed} - 允许"N/A"（"不适用"）。
  • {N/A justification} - 允许"N/A"（"不适用"）并且需要理由。
  • {Met justification} - "满足"需要理由。
  • {Met URL} - "满足"需要包含网址（URL）的理由。
  • {Future} - 此标准的答案目前没有影响，但将来可能会要求。

项目必须达到前一级别才能达到下一级别。在某些情况下，"应该"（SHOULD）标准在更高级别的徽章中变成"必须"（MUST），并且一些较低级别的"建议"（SUGGESTED）标准在更高级别的徽章中变成"应该"（SHOULD）或"必须"（MUST）。较高级别还需要更多理由，因为我们希望其他人了解标准如何得到满足。

（许多）加密标准并不总是适用，因为某些软件不需要直接使用加密功能。在这些情况下，请回答N/A。

有一个隐含的通过标准 - 每个项目必须有一个具有稳定网址（URL）的公共网站。这是首先创建徽章条目所必需的。

术语

如果您不熟悉软件开发或运行FLOSS项目，诸如Producing Open Source Software by Karl Fogel等材料可能对您有所帮助。

以下是一些关键术语：

  • 项目是具有项目成员并产生项目成果的活动实体。其成员使用项目站点来协调和传播成果。项目不需要是正式的法律实体。
  • 项目成员是一个或多个人或公司的群体，他们共同努力以产生项目成果。一些FLOSS项目可能具有不同类型的成员，具有不同的角色，但这超出了我们的范围。
  • 项目结果是项目成员共同努力产生的最终目标。通常是软件，但是项目结果可能还包括其他内容。引用“项目产生的软件”的标准是指项目结果。
  • 项目站点是专用于支持开发和传播项目成果的站点，并且在适用的情况下包括项目网站，仓库和下载站点（请参考sites_https ）。
  • 项目网站，又称项目主页，是新用户通常会访问以及查看有关项目信息的万维网（WWW）上的主页；它可能与项目的仓库站点相同（在GitHub上通常如此）。
  • 项目仓库管理和存储项目结果以及项目结果的修订历史记录。这也称为项目源仓库，因为我们仅需要管理和存储可编辑版本，而不是自动生成的结果（在许多情况下，生成的结果不存储在仓库中）。
  • A项目安全机制是交付的项目的软件提供的安全机制。

非标准

条件：

  • 不要求任何特定的技术、产品或服务。例如，它们不要求git、GitHub或GitLab。这些标准确实为常见情况提供指导和帮助，因为这些信息可以帮助人们理解和满足标准。对于使用git或GitHub的项目，有一些特殊的自动化，以帮助这些常见情况下的用户，但它们不是必需的。因此，随着新工具和功能的出现，项目可以快速切换到它们。作为例外，标准确实要求项目网页和TLS。
  • 不要求或禁止任何特定的编程语言。它们确实要求对某些类型的编程语言采取额外的措施，但这是不同的。
  • 从不要求使用专有软件、专有服务或专有技术，因为许多自由软件开发者会拒绝此类标准。项目允许使用它们并依赖它们。
  • 不要求项目内的积极开发或用户讨论。一些高度成熟的项目很少改变，因此可能活动很少。但是，这些标准确实要求，如果向项目报告漏洞，项目应做出响应。
  • 不需要费用就可以获得徽章。
  • 不要求一次实现所有标准；大多数项目随着时间的推移实现它们。

通过级别不包括对单人项目不切实际的标准，例如需要大量资金的标准。许多FLOSS项目规模很小，我们不想剥夺它们的权利。

识别项目

我们的应用程序为每个项目条目提供唯一的id，但这对搜索项目的人没有帮助。就我们的目的而言，项目的真实名称是其仓库的网址（URL），如果不可用，则是项目"主页"网址（URL）。我们限制对仓库网址（URL）的更改速率以防止一些无意义的行为。项目通常具有人类可读的名称，但这些名称不够唯一。

为什么要有标准？

论文 开放徽章在教育中的应用：在开放系统和徽章交叉点的意义是什么？ 确定了徽章系统的三个一般原因（所有这些都适用于此）：

  1. 徽章作为行为的激励因素。我们希望通过识别最佳实践，鼓励项目实施这些最佳实践（如果它们尚未这样做）。
  2. 徽章作为教学工具。有些项目可能不了解其他项目应用的一些最佳实践，或者这些实践如何被实际应用。徽章将帮助他们了解这些实践以及实施它们的方法。
  3. 徽章作为标志或凭证。潜在用户希望使用那些应用最佳实践以持续产生良好结果的项目；徽章使项目能够轻松表明它们正在遵循最佳实践，并使用户能够轻松查看哪些项目正在这样做。

为什么要自我认证？

我们选择使用自我认证，因为这使得大量项目（甚至小型项目）能够参与。有数百万个自由开源软件项目，支付第三方独立评估每个项目的费用无法扩展。项目可能会做出虚假声明的风险是存在的，但我们认为风险很小，用户可以自己检查声明，并且可以覆盖虚假声明。我们还使用自动化来覆盖虚假声明，前提是我们对结果有信心。