FLOSS 最佳实践标准（所有级别）

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

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

通过

基本

基本项目网站内容

项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 ^{[description_good]}
项目网站必须提供有关如何获取和提供反馈（错误报告或增强功能）以及如何贡献的信息。 ^[interact]
关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） {Met URL} ^{[contribution]}
关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 {Met URL} ^{[contribution_requirements]}

FLOSS许可证

项目生产的软件必须作为FLOSS发布。 ^{[floss_license]}
建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 ^{[floss_license_osi]}
项目必须将其许可证在其源代码存储库中的标准位置发布。 {Met URL} ^{[license_location]}

文档

项目必须为项目生成的软件提供基本文档。 {N/A justification} ^{[documentation_basics]}
项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 {N/A justification} ^{[documentation_interface]}

其他

项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 ^{[sites_https]}
该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 ^[discussion]
项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 ^[english]
必须维护该项目。 ^[maintained]

变更控制

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

该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 ^{[repo_public]}
项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。 ^[repo_track]
为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 ^{[repo_interim]}
建议使用通用分布式版本控制软件（例如，git）作为项目的源代码存储库。 ^{[repo_distributed]}

唯一版本编号

项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 ^{[version_unique]}
建议使用语义版本控制（SemVer）格式进行发布。 ^{[version_semver]}
建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。 ^{[version_tags]}

发行说明

该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 {N/A justification} {Met URL} ^{[release_notes]}
发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 {N/A justification} ^{[release_notes_vulns]}

报告

错误报告流程

项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。 {Met URL} ^{[report_process]}
项目必须使用问题跟踪器来跟踪每个问题。 ^{[report_tracker]}
该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。 ^{[report_responses]}
该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 ^{[enhancement_responses]}
该项目必须有一个公开的报告和回复的档案供后续搜索。 {Met URL} ^{[report_archive]}

漏洞报告流程

项目必须在项目网站上发布报告漏洞的流程。 {Met URL} ^{[vulnerability_report_process]}
如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 {N/A allowed} {Met URL} ^{[vulnerability_report_private]}
该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 {N/A allowed} ^{[vulnerability_report_response]}

质量

可工作的构建系统

如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 {N/A allowed} ^[build]
建议使用通用工具来构建软件。 {N/A allowed} ^{[build_common_tools]}
该项目应该仅使用FLOSS工具来构建。 {N/A allowed} ^{[build_floss_tools]}

自动测试套件

该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 ^[test]
测试套件应该以该语言的标准方式进行调用。 ^{[test_invocation]}
建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。 ^[test_most]
建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 ^{[test_continuous_integration]}

新功能测试

该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 ^{[test_policy]}
该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 ^{[tests_are_added]}
建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 ^{[tests_documented_added]}

警告标志

该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 {N/A allowed} ^[warnings]
该项目必须处理警告。 {N/A allowed} ^{[warnings_fixed]}
建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 {N/A allowed} ^{[warnings_strict]}

安全

安全开发知识

该项目必须至少有一个主要开发人员知道如何设计安全软件。 ^{[know_secure_design]}
该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 ^{[know_common_errors]}

使用基础的良好加密实践

项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 {N/A allowed} ^{[crypto_published]}
如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。 {N/A allowed} ^{[crypto_call]}
项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 {N/A allowed} ^{[crypto_floss]}
项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 {N/A allowed} ^{[crypto_keylength]}
项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 {N/A allowed} ^{[crypto_working]}
由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。 {N/A allowed} ^{[crypto_weaknesses]}
项目产生的软件中的安全机制应该对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。 {N/A allowed} ^[crypto_pfs]
如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列。 {N/A allowed} ^{[crypto_password_storage]}
由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 {N/A allowed} ^{[crypto_random]}

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

该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 ^{[delivery_mitm]}
不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 ^{[delivery_unsigned]}

修正公开的漏洞

被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 ^{[vulnerabilities_fixed_60_days]}
项目在得到报告后应该迅速修复所有致命漏洞。 ^{[vulnerabilities_critical_fixed]}

其他安全问题

公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 ^{[no_leaked_credentials]}

分析

静态代码分析

如果至少有一个FLOSS工具以所选择的语言实现此条款，则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 {N/A justification} {Met justification} ^{[static_analysis]}
建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 {N/A allowed} ^{[static_analysis_common_vulnerabilities]}
使用静态代码分析发现的所有中，高严重性可利用漏洞必须在确认后及时修复。 {N/A allowed} ^{[static_analysis_fixed]}
建议每次提交或至少每天执行静态源代码分析。 {N/A allowed} ^{[static_analysis_often]}

动态代码分析

建议在发布之前，至少将一个动态分析工具应用于软件任何发布的主要生产版本。 ^{[dynamic_analysis]}
建议如果项目生成的软件包含使用内存不安全语言编写的软件（例如C或C++），则至少有一个动态工具（例如，fuzzer或web应用扫描程序）与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写，请选择“不适用”（N / A）。 {N/A allowed} ^{[dynamic_analysis_unsafe]}
建议由项目生成的软件包括许多运行时断言，在动态分析期间检查。 ^{[dynamic_analysis_enable_assertions]}
通过动态代码分析发现的所有严重性为中，高的可利用漏洞必须在确认后及时修复。 {N/A allowed} ^{[dynamic_analysis_fixed]}

白银

基本

先决条件

项目必须拥有通过徽章。 ^{[achieve_passing]}

基本项目网站内容

关于如何贡献的信息必须包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 {Met URL} ^{[contribution_requirements]}

项目监督

该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。 {Met URL} ^[dco]
该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。 {Met URL} ^[governance]
该项目必须采取行为守则，并将其发布在标准的位置。 {Met URL} ^{[code_of_conduct]}
该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。 {Met URL} ^{[roles_responsibilities]}
如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。 {Met URL} ^{[access_continuity]}
项目必须具有2个或更多的“公交车因子”。 {Met URL} ^[bus_factor]

文档

该项目必须有一个文档化的路线图，描述项目打算做什么，至少在下一年做什么。 {Met URL} ^{[documentation_roadmap]}
该项目必须包括项目生成的软件的架构（也称为高级别设计）的文档。如果项目不产生软件，请选择“不适用”（N/A）。 {N/A justification} {Met URL} ^{[documentation_architecture]}
该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容（其“安全需求”）。 {N/A allowed} {Met URL} ^{[documentation_security]}
该项目必须为新用户提供“快速启动”指南，以帮助他们快速使用该软件。 {N/A justification} {Met URL} ^{[documentation_quick_start]}
项目必须努力使文档与当前版本的项目结果（包括项目生成的软件）保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的，但是错误地包括一些不再是真实的旧信息，那么将其视为缺陷，然后像往常一样进行跟踪和修复。 {N/A justification} {Met justification} ^{[documentation_current]}
项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就，包括此最佳实践徽章。 {Met URL} ^{[documentation_achievements]}

无障碍和国际化

该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。 {N/A justification} {Met justification} ^{[accessibility_best_practices]}
该项目产生的软件应该被国际化，以便为目标受众的文化，地区或语言进行简单的本地化。如果国际化（i18n）不适用（例如，该软件不会生成针对最终用户的文本，并且不排序可读文本），请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[internationalization]}

其他

如果项目站点（网站，存储库和下载URL）存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法将密码存储为具有每用户盐值的迭代散列（例如，PBKDF2，Bcrypt或Scrypt）。如果项目站点不存储密码，请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[sites_password_security]}

变更控制

之前的版本

该项目必须维护最常用的旧版本的产品或提供较新版本的升级路径。如果升级路径很困难，项目必须记录如何执行升级（例如，给出更改的接口描述和详细的建议步骤以帮助升级）。 {N/A justification} {Met justification} ^{[maintenance_or_update]}

报告

错误报告流程

项目必须使用问题跟踪器来跟踪每个问题。 {N/A justification} {Met justification} ^{[report_tracker]}

漏洞报告流程

除了要求匿名的报告者外，该项目必须对过去12个月内解决的所有漏洞报告的报告者表示感谢。如果过去12个月没有修复漏洞，请选择“不适用”（N/A）。 {N/A justification} {Met URL} ^{[vulnerability_report_credit]}
该项目必须有一个书面的流程来响应漏洞报告。 {Met URL} ^{[vulnerability_response_process]}

质量

编码标准

该项目必须确定其使用的主要语言的具体编码风格指南，并要求贡献一般情况下符合此要求。 {N/A justification} {Met URL} ^{[coding_standards]}
如果至少有一个FLOSS工具可以应用于所选择的语言，项目必须自动执行其选定的编码风格。 {N/A justification} {Met justification} ^{[coding_standards_enforced]}

可工作的构建系统

本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器（环境）变量（例如CC，CFLAGS，CXX，CXXFLAGS和LDFLAGS），并将它们传递给编译器和链接器。构建系统可以使用附加标志来扩展它们，但不能简单地用自己的替换提供的值。如果没有生成本地二进制文件，请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[build_standard_variables]}
构建和安装系统在在相关标志中要求时，应该保留调试信息（例如，“install -s”未被使用）。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[build_preserve_debug]}
如果子目录中存在交叉依赖关系，则由项目生成的软件的构建系统必须不能递归地构建子目录。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[build_non_recursive]}
该项目必须能够重复从源代码文件生成的过程，并获得完全相同的比特位结果。如果没有发生构建（例如，直接使用源代码而不是编译使用的脚本语言），请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[build_repeatable]}

安装系统

该项目必须提供一种使用常用惯例轻松安装和卸载由项目生成的软件的方法。 {N/A justification} {Met justification} ^{[installation_common]}
最终用户的安装系统必须遵守用于在安装时选择构建工件写入位置的标准约定。例如，如果在POSIX系统上安装文件，它必须遵守DESTDIR环境变量。如果没有安装系统或没有标准惯例，请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[installation_standard_variables]}
该项目必须为潜在开发人员提供一种快速安装所有项目成果和支持环境所必需的环境，包括测试套件和测试环境。必须通过常规惯例执行。 {N/A justification} {Met justification} ^{[installation_development_quick]}

外部维护的组件

项目必须以计算机可处理的方式列出外部依赖关系。 {N/A justification} {Met URL} ^{[external_dependencies]}
项目必须监视或定期检查其外部依赖（包括便利副本）以检测已知的漏洞，并修复可利用的漏洞或将其验证为不可利用的漏洞。 {N/A justification} {Met justification} ^{[dependency_monitoring]}
该项目必须满足下述情况之一：
1. 可以轻松识别和更新重用的外部维护组件; 或
2. 使用系统或编程语言提供的标准组件。
这样，如果在重用的组件中发现了一个漏洞，将容易更新该组件。 {N/A justification} {Met justification} ^{[updateable_reused_components]}
该项目应避免使用已弃用或过时的功能和API，如果FLOSS替代品在其使用的技术集合（“技术堆栈”）中以及项目支持的大多数用户中可用（以便用户可以随时访问该替代品）。 {N/A justification} {Met justification} ^{[interfaces_current]}

自动测试套件

必须将自动测试套件应用于至少一个分支的共享代码库的每次签入。该测试套件必须生成关于测试成功或失败的报告。 {Met justification} ^{[automated_integration_testing]}
该项目必须为过去六个月内修复的至少50％的错误，在自动化测试套件中添加回归测试。 {N/A justification} {Met justification} ^{[regression_tests_added50]}
如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％语句覆盖率。 {N/A justification} {Met justification} ^{[test_statement_coverage80]}

新功能测试

该项目必须具有正式的书面策略，一旦添加了主要的新功能，新功能的测试必须被添加到自动测试套件中。 {N/A justification} {Met justification} ^{[test_policy_mandated]}
该项目必须在其关于变更建议的书面指导中包括要为主要新功能添加测试的策略。 {N/A justification} {Met justification} ^{[tests_documented_added]}

警告标志

在实际允许时，项目必须最大限度地严格修复项目生成的软件中的警告。 {N/A justification} {Met justification} ^{[warnings_strict]}

安全

安全开发知识

该项目必须实施安全设计原则（来自“know_secure_design”）（如适用）。如果项目不生产软件，请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[implement_secure_design]}

使用基础的良好加密实践

由项目产生的软件中的默认安全机制不得取决于具有已知严重弱点（例如，SHA-1密码散列算法或SSH中的CBC模式）的加密算法或模式。 {N/A allowed} {Met justification} ^{[crypto_weaknesses]}
该项目应该支持多种加密算法，如果一个被破解，用户可以快速切换。普通的对称密钥算法包括AES，Twofish和Serpent。通用密码散列算法的选择包括SHA-2（包括SHA-224，SHA-256，SHA-384和SHA-512）和SHA-3。 {N/A allowed} {Met justification} ^{[crypto_algorithm_agility]}
该项目必须支持在与其他信息（如配置文件，数据库和日志）分离的文件中存储身份验证凭据（如密码和动态令牌）以及私有加密密钥，并允许用户更新和替换它们，而无需重新编译代码。如果项目从不处理身份验证凭据和私有加密密钥，请选择“不适用”（N/A）。 {N/A allowed} {Met justification} ^{[crypto_credential_agility]}
该项目产生的软件应该支持所有网络通信的安全协议，如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]}
由项目生成的软件必须，如果它支持TLS，则在使用TLS（包括子资源）时默认执行TLS证书验证。如果软件不使用TLS，请选择“不适用”（N / A）。 {N/A allowed} {Met justification} ^{[crypto_certificate_verification]}
项目生成的软件（如果支持TLS）必须在发送具有私有信息（如安全Cookie）的HTTP头之前执行证书验证。如果软件不使用TLS，请选择“不适用”（N/A）。 {N/A allowed} {Met justification} ^{[crypto_verification_private]}

安全发布

该项目必须加密签名旨在广泛使用的项目结果的发布，并且必须有一个书面流程，向用户解释如何获取公共签名密钥并验证签名。这些签名的私钥不得在项目网站上直接向公众发布。如果发行版本不适用于广泛使用，请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[signed_releases]}
建议在版本控制系统中，每个重要版本标签（作为主要版本的一部分的标签，次要版本或修复公开提到的漏洞）都按照signed_releases中的要求进行加密签名，并可验证。 {Met justification} ^{[version_tags_signed]}

其他安全问题

项目结果必须检查来自潜在不受信任来源的所有输入，以确保它们有效（ *白名单*），如果对数据有限制，则拒绝无效输入。 {N/A justification} {Met justification} ^{[input_validation]}
加固机制应该用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 {N/A justification} {Met justification} ^[hardening]
该项目必须提供一个保证案例，证明其满足安全要求。保证案例必须包括：对威胁模型的描述，明确确定信任边界，确定设计原则得到适用，以及常见安全弱点已经被消减。 {Met URL} ^{[assurance_case]}

分析

静态代码分析

如果至少有一个FLOSS工具能够以所选择的语言实现此条款，则该项目必须至少使用一个具有规则或方式的静态分析工具来查找分析语言或环境中的常见漏洞。 {N/A justification} {Met justification} ^{[static_analysis_common_vulnerabilities]}

动态代码分析

如果由项目生成的软件包含使用内存不安全语言编写的软件（例如，C或C ++），则项目必须至少使用一个动态工具（例如，fuzzer或web应用扫描程序）与一种检测缓冲区覆写等内存安全问题的机制组合例行使用。如果项目不生成以内存不安全语言编写的软件，请选择“不适用”（N/A）。 {N/A justification} {Met justification} ^{[dynamic_analysis_unsafe]}

黄金

基本

先决条件

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

项目监督

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

其他

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

变更控制

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

必须使用通用的分布式版本控制软件（例如，git，mercurial）作为项目的源代码存储库。 {Met justification} ^{[repo_distributed]}
该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 {Met URL} ^{[small_tasks]}
项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。 {Met justification} ^{[require_2FA]}
项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 {Met justification} ^[secure_2FA]

质量

编码标准

该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 {N/A justification} {Met URL} ^{[code_review_standards]}
该项目必须至少有50％的修改（作者之外的人提出的）在发布之前审查，以确定是否是一个有价值的修改，并且没有已知的问题，会反对其包含 {Met justification} ^{[two_person_review]}

可工作的构建系统

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

自动测试套件

测试套件必须以该语言的标准方式进行调用。 {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]}

其他安全问题

该项目必须在过去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]}