FLOSS 最佳实践标准（黄金徽章）

这是自由/自由和开源软件（FLOSS）项目的最佳实践集，以在通过，银色和金色徽章级别获得核心基础设施计划（OpenSSF）最佳实践徽章。您可以仅使用标准或其他信息来显示此列表。您还可以仅查看通过，银和金标准，以及全套标准。

有关这些条件的更多信息，请参见条件讨论。

黄金

基本

先决条件

• 该项目必须拥有银级徽章。 ^{[achieve_silver]}

项目监督

• 项目必须具有2个或更多的“公交车因子”。 {Met URL} ^[bus_factor]
• 该项目必须至少有两个不相关的重要贡献者。 {Met URL} ^{[contributors_unassociated]}

  详细信息:

  如果同一组织（作为雇员或承包商）支付工作费用，并且组织将从项目的结果中受益，则贡献者是相关联的。如果通过其他组织得到财务补助（例如，源自政府或非政府组织，支付给不同组织的科学补助金不会导致捐助者关联），不视为来自同一组织。重要贡献者定义为过去一年对项目做出了不平凡的贡献。一个重要贡献者的良好指标的例子是：编写至少1,000行代码，贡献50个提交或至少提交20页的文档。

其他

• 该项目必须在每个源文件中包含一个版权声明，确定至少一个相关年份和版权所有者。 {Met justification} ^{[copyright_per_file]}

  详细信息:

  这可以通过在每个文件开头附近的注释中加入以下内容：“Copyright [year this project or content started] - [most recent year modified], [project founder] and the [project name] contributors.”

• 项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现： SPDX-License-Identifier: [SPDX license expression for project]。 {Met justification} ^{[license_per_file]}

  详细信息:

  这可以通过在自然语言中包含许可证标识来完成。该项目还可以包括完整许可证文本，或者指向许可证文本的稳定URL。请注意，license_location条款要求项目许可证在标准位置。有关SPDX许可证表达式的更多信息，请参阅SPDX教程。请注意与 copyright_per_file 的关系，其内容通常在许可证信息之前。

变更控制

公开的版本控制的源代码存储库

• 必须使用通用的分布式版本控制软件（例如，git，mercurial）作为项目的源代码存储库。 {Met justification} ^{[repo_distributed]}
• 该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 {Met URL} ^{[small_tasks]}

  详细信息:

  此标识通常通过在项目使用的一个或多个标签的问题跟踪器中标记所选问题来完成，例如 up- for-grabs ，仅限第一时间，“小修复”，微任务或IdealFirstBug。这些新任务不需要添加功能；他们可以改进文档，添加测试用例或其他有助于项目的内容，并帮助贡献者更了解项目。

• 项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。 {Met justification} ^{[require_2FA]}
• 项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 {Met justification} ^[secure_2FA]

  详细信息:

  满足此条款的2FA机制将是一种基于时间的一次性密码（TOTP）应用程序，可自动生成在一段时间后更改的验证码。请注意， GitHub支持TOTP 。

质量

编码标准

• 该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 {N/A justification} {Met URL} ^{[code_review_standards]}

  详细信息:

  另请参阅 two_person_review 和contribution_requirements 条款。

• 该项目必须至少有50％的修改（作者之外的人提出的）在发布之前审查，以确定是否是一个有价值的修改，并且没有已知的问题，会反对其包含 {Met justification} ^{[two_person_review]}

可工作的构建系统

• 该项目必须具有可重复构建。如果没有发生构建（例如，直接使用源代码而不是编译的脚本语言），请选择“不适用”（N/A）。 {N/A justification} {Met URL} ^{[build_reproducible]}

  详细信息:

  可重复的构建意味着多方可以独立地重做从源文件生成信息的过程，并获得每比特完全相同的结果。在某些情况下，这可以通过强制某种排序来解决。 JavaScript开发人员可能会考虑使用npm shrinkwrap和webpack的OccurenceOrderPlugin。 GCC和clang用户可能会发现-frandom-seed选项有用。通常可以通过指定可用于重新构建的特定容器或虚拟机的加密散列来为外部方定义构建环境（包括工具集）。 可重复构建项目具有文档指导如何执行此操作。

自动测试套件

• 测试套件必须以该语言的标准方式进行调用。 {Met URL} ^{[test_invocation]}
• 该项目必须实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 {Met URL} ^{[test_continuous_integration]}

  详细信息:

  在大多数情况下，这意味着每个在项目上全职工作的开发人员至少每天都会整合。

• 如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少90％语句覆盖率。 {N/A justification} {Met justification} ^{[test_statement_coverage90]}
• 如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％分支覆盖率。 {N/A justification} {Met justification} ^{[test_branch_coverage80]}

安全

使用基础的良好加密实践

• 项目生成的软件必须支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本以及SSHv1等不安全协议必须被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。 {N/A allowed} {Met justification} ^{[crypto_used_network]}
• 由项目生成的软件必须，如果支持或使用TLS，至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。 {N/A allowed} {Met justification} ^{[crypto_tls12]}

安全交付防御中间人（MITM）的攻击

• 项目网站，存储库（如果可通过网络访问）和下载站点（如果单独）必须包括具有非允许值的密钥加固头。 {Met URL} ^{[hardened_site]}

  详细信息:

  请注意，GitHub是已知满足的。 https://securityheaders.io/ 等网站可以快速查看。主要头加固包含：内容安全策略（CSP），HTTP严格传输安全性（HSTS），X-Content-Type-Options（“nosniff”），X-Frame-Options和X-XSS-Protection。

其他安全问题

• 该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。 {Met justification} ^{[security_review]}

  详细信息:

  这可以由项目成员完成和/或独立评估。此评估可能由静态和动态分析工具支持，但还必须进行人工审查，以确定工具无法检测到的问题（特别是设计问题）。

• 加固机制必须用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 {N/A justification} {Met URL} ^[hardening]

分析

动态代码分析

• 必须在发布之前，至少将一个动态分析工具应用于软件任何候选发布的主要生产版本。 {N/A justification} {Met justification} ^{[dynamic_analysis]}
• 项目应该在其生成的软件中包含许多运行时断言，并在动态分析期间检查这些断言。 {N/A justification} {Met justification} ^{[dynamic_analysis_enable_assertions]}