FLOSS 最佳实践标准（所有级别）
这是自由/自由和开源软件（FLOSS）项目的最佳实践集，以在通过，银色和金色徽章级别获得核心基础设施计划（OpenSSF）最佳实践徽章。您可以仅使用标准或其他信息来显示此列表。您还可以仅查看通过，银和金标准，以及标准统计信息。
有关这些条件的更多信息，请参见条件讨论。
通过
基本
基本项目网站内容
FLOSS许可证
文档
其他
-
项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。
[sites_https]
-
该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。
[discussion]
-
项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。
[english]
-
必须维护该项目。
[maintained]
变更控制
公开的版本控制的源代码存储库
唯一版本编号
发行说明
-
该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。
{N/A理由}
{满足URL}
[release_notes]
-
发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。
{N/A理由}
[release_notes_vulns]
报告
错误报告流程
漏洞报告流程
质量
可工作的构建系统
自动测试套件
新功能测试
警告标志
-
该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。
{允许N/A}
[warnings]
-
该项目必须处理警告。
{允许N/A}
[warnings_fixed]
-
建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。
{允许N/A}
[warnings_strict]
安全
安全开发知识
使用基础的良好加密实践
-
项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。
{允许N/A}
[crypto_published]
-
如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。
{允许N/A}
[crypto_call]
-
项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。
{允许N/A}
[crypto_floss]
-
项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。
{允许N/A}
[crypto_keylength]
-
项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。
{允许N/A}
[crypto_working]
-
由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。
{允许N/A}
[crypto_weaknesses]
-
项目产生的软件中的安全机制应该对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。
{允许N/A}
[crypto_pfs]
-
如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。
{允许N/A}
[crypto_password_storage]
-
由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。
{允许N/A}
[crypto_random]
安全交付防御中间人（MITM）的攻击
修正公开的漏洞
其他安全问题
分析
静态代码分析
动态代码分析
白银
基本
先决条件
基本项目网站内容
项目监督
-
该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。
{满足URL}
[dco]
-
该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。
{满足URL}
[governance]
-
该项目必须采取行为守则，并将其发布在标准的位置。
{满足URL}
[code_of_conduct]
-
该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。
{满足URL}
[roles_responsibilities]
-
如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。
{满足URL}
[access_continuity]
-
项目必须具有2个或更多的“公交车因子”。
{满足URL}
[bus_factor]
文档
无障碍和国际化
其他
-
如果项目站点（网站，存储库和下载URL）存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法将密码存储为具有每用户盐值的迭代散列（例如，PBKDF2，Bcrypt或Scrypt）。如果项目站点不存储密码，请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[sites_password_security]
变更控制
之前的版本
-
该项目必须维护最常用的旧版本的产品或提供较新版本的升级路径。如果升级路径很困难，项目必须记录如何执行升级（例如，给出更改的接口描述和详细的建议步骤以帮助升级）。
{N/A理由}
{满足理由}
[maintenance_or_update]
报告
错误报告流程
漏洞报告流程
质量
编码标准
可工作的构建系统
-
本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器（环境）变量（例如CC，CFLAGS，CXX，CXXFLAGS和LDFLAGS），并将它们传递给编译器和链接器。构建系统可以使用附加标志来扩展它们，但不能简单地用自己的替换提供的值。如果没有生成本地二进制文件，请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[build_standard_variables]
-
构建和安装系统在在相关标志中要求时，应该保留调试信息（例如，“install -s”未被使用）。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[build_preserve_debug]
-
如果子目录中存在交叉依赖关系，则由项目生成的软件的构建系统必须不能递归地构建子目录。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[build_non_recursive]
-
该项目必须能够重复从源代码文件生成的过程，并获得完全相同的比特位结果。如果没有发生构建（例如，直接使用源代码而不是编译使用的脚本语言），请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[build_repeatable]
安装系统
外部维护的组件
自动测试套件
新功能测试
警告标志
安全
安全开发知识
使用基础的良好加密实践
-
由项目产生的软件中的默认安全机制不得取决于具有已知严重弱点（例如，SHA-1密码散列算法或SSH中的CBC模式）的加密算法或模式。
{允许N/A}
{满足理由}
[crypto_weaknesses]
-
该项目应该支持多种加密算法，如果一个被破解，用户可以快速切换。普通的对称密钥算法包括AES，Twofish和Serpent。通用密码散列算法的选择包括SHA-2（包括SHA-224，SHA-256，SHA-384和SHA-512）和SHA-3。
{允许N/A}
{满足理由}
[crypto_algorithm_agility]
-
该项目必须支持在与其他信息（如配置文件，数据库和日志）分离的文件中存储身份验证凭据（如密码和动态令牌）以及私有加密密钥，并允许用户更新和替换它们，而无需重新编译代码。如果项目从不处理身份验证凭据和私有加密密钥，请选择“不适用”（N/A）。
{允许N/A}
{满足理由}
[crypto_credential_agility]
-
该项目产生的软件应该支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本和SSHv1等不安全协议将被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。
{允许N/A}
{满足理由}
[crypto_used_network]
-
项目生成的软件（如果支持或使用TLS）应该至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。
{允许N/A}
{满足理由}
[crypto_tls12]
-
由项目生成的软件必须，如果它支持TLS，则在使用TLS（包括子资源）时默认执行TLS证书验证。如果软件不使用TLS，请选择“不适用”（N / A）。
{允许N/A}
{满足理由}
[crypto_certificate_verification]
-
项目生成的软件（如果支持TLS）必须在发送具有私有信息（如安全Cookie）的HTTP头之前执行证书验证。如果软件不使用TLS，请选择“不适用”（N/A）。
{允许N/A}
{满足理由}
[crypto_verification_private]
安全发布
-
该项目必须加密签名旨在广泛使用的项目结果的发布，并且必须有一个书面流程，向用户解释如何获取公共签名密钥并验证签名。这些签名的私钥不得在项目网站上直接向公众发布。如果发行版本不适用于广泛使用，请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[signed_releases]
-
建议在版本控制系统中，每个重要版本标签（作为主要版本的一部分的标签，次要版本或修复公开提到的漏洞）都按照signed_releases中的要求进行加密签名，并可验证。
{满足理由}
[version_tags_signed]
其他安全问题
-
项目结果必须检查来自潜在不受信任来源的所有输入，以确保它们有效（ *白名单*），如果对数据有限制，则拒绝无效输入。
{N/A理由}
{满足理由}
[input_validation]
-
加固机制应该用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。
{N/A理由}
{满足理由}
[hardening]
-
该项目必须提供一个保证案例，证明其满足安全要求。保证案例必须包括：对威胁模型的描述，明确确定信任边界，确定设计原则得到适用，以及常见安全弱点已经被消减。
{满足URL}
[assurance_case]
分析
静态代码分析
动态代码分析
-
如果由项目生成的软件包含使用内存不安全语言编写的软件（例如，C或C ++），则项目必须至少使用一个动态工具（例如，fuzzer或web应用扫描程序）与一种检测缓冲区覆写等内存安全问题的机制组合例行使用。如果项目不生成以内存不安全语言编写的软件，请选择“不适用”（N/A）。
{N/A理由}
{满足理由}
[dynamic_analysis_unsafe]
黄金
基本
先决条件
项目监督
其他
变更控制
公开的版本控制的源代码存储库
-
必须使用通用的分布式版本控制软件（例如，git，mercurial）作为项目的源代码存储库。
{满足理由}
[repo_distributed]
-
该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。
{满足URL}
[small_tasks]
-
项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。
{满足理由}
[require_2FA]
-
项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。
{满足理由}
[secure_2FA]
质量
编码标准
可工作的构建系统
自动测试套件
安全
使用基础的良好加密实践
-
项目生成的软件必须支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本以及SSHv1等不安全协议必须被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。
{允许N/A}
{满足理由}
[crypto_used_network]
-
由项目生成的软件必须，如果支持或使用TLS，至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。
{允许N/A}
{满足理由}
[crypto_tls12]
安全交付防御中间人（MITM）的攻击
-
项目网站，存储库（如果可通过网络访问）和下载站点（如果单独）必须包括具有非允许值的密钥加固头。
{满足URL}
[hardened_site]
其他安全问题
-
该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。
{满足理由}
[security_review]
-
加固机制必须用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。
{N/A理由}
{满足URL}
[hardening]
分析
动态代码分析
基准等级1
通用
控制
-
当用户尝试读取或修改项目权威存储库中的敏感资源时，系统必须要求用户完成多因素认证过程。
{N/A理由}
{满足URL}
[osps_ac_01_01]
-
当添加新的协作者时，版本控制系统必须要求手动分配权限，或默认将协作者权限限制为可用的最低权限。
{N/A理由}
{满足URL}
[osps_ac_02_01]
-
当尝试直接提交到项目的主分支时,强制机制必须阻止该更改的应用。
{N/A理由}
{满足URL}
[osps_ac_03_01]
-
当尝试删除项目的主分支时,版本控制系统必须将此视为敏感活动,并要求明确确认意图。
{N/A理由}
{满足URL}
[osps_ac_03_02]
-
当CI/CD管道接受输入参数时,该参数必须在管道中使用之前进行清理和验证。
{N/A理由}
{满足URL}
[osps_br_01_01]
-
当CI/CD管道在其功能中使用分支名称时,该名称值必须在管道中使用之前进行清理和验证。
{N/A理由}
{满足URL}
[osps_br_01_02]
-
当项目将URI列为官方项目渠道时,该URI必须仅通过加密渠道交付。
{N/A理由}
{满足URL}
[osps_br_03_01]
-
当项目将URI列为官方分发渠道时,该URI必须仅通过加密渠道交付。
{N/A理由}
{满足URL}
[osps_br_03_02]
-
项目必须防止在版本控制系统中意外存储未加密的敏感数据,例如机密和凭据。
{N/A理由}
{满足URL}
[osps_br_07_01]
-
当项目发布版本后,项目文档必须包含所有基本功能的用户指南。
{N/A理由}
{满足URL}
[osps_do_01_01]
-
当项目发布版本后,项目文档必须包含缺陷报告指南。
{N/A理由}
{满足URL}
[osps_do_02_01]
-
在活跃期间,项目必须有一个或多个机制用于公开讨论提议的更改和使用障碍。
{N/A理由}
{满足URL}
[osps_gv_02_01]
-
在活跃期间,项目文档必须包含贡献流程的说明。
{N/A理由}
{满足URL}
[osps_gv_03_01]
-
活跃期间，源代码的许可证必须符合OSI开源定义或FSF自由软件定义。
{N/A理由}
{满足URL}
[osps_le_02_01]
-
活跃期间，已发布软件资产的许可证必须符合OSI开源定义或FSF自由软件定义。
{N/A理由}
{满足URL}
[osps_le_02_02]
-
活跃期间，源代码的许可证必须保存在相应仓库的LICENSE文件、COPYING文件或LICENSE/目录中。
{N/A理由}
{满足URL}
[osps_le_03_01]
-
活跃期间，已发布软件资产的许可证必须包含在已发布的源代码中，或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中。
{N/A理由}
{满足URL}
[osps_le_03_02]
-
活跃期间，项目的源代码仓库必须在静态URL上可公开读取。
{N/A理由}
{满足URL}
[osps_qa_01_01]
-
版本控制系统必须包含所有更改的可公开读取的记录，包括谁进行了更改以及更改的时间。
{N/A理由}
{满足URL}
[osps_qa_01_02]
-
当包管理系统支持时，源代码仓库必须包含一个依赖项列表，该列表涵盖直接的语言依赖项。
{N/A理由}
{满足URL}
[osps_qa_02_01]
-
活跃期间，项目文档必须包含被视为子项目的任何代码库的列表。
{N/A理由}
{满足URL}
[osps_qa_04_01]
-
活跃期间，版本控制系统中不得包含生成的可执行工件。
{N/A理由}
{满足URL}
[osps_qa_05_01]
-
活跃期间，版本控制系统中不得包含无法审查的二进制工件。
{N/A理由}
{满足URL}
[osps_qa_05_02]
-
在活动期间，项目文档必须包含安全联系人。
{N/A理由}
{满足URL}
[osps_vm_02_01]
基准等级2
通用
控制
-
当执行CI/CD任务且未指定权限时，CI/CD系统必须将任务的权限默认为管道中授予的最低权限。
{N/A理由}
{满足URL}
[osps_ac_04_01]
-
当创建正式发布时，该发布必须分配一个唯一的版本标识符。
{N/A理由}
{满足URL}
[osps_br_02_01]
-
当创建正式发布时，该发布必须包含功能和安全修改的描述性日志。
{N/A理由}
{满足URL}
[osps_br_04_01]
-
当构建和发布管道摄取依赖项时，它必须使用标准化工具（如果可用）。
{N/A理由}
{满足URL}
[osps_br_05_01]
-
当创建正式发布时，该发布必须进行签名或在包含每个资产加密哈希值的签名清单中进行说明。
{N/A理由}
{满足URL}
[osps_br_06_01]
-
当项目发布版本后，项目文档必须包含项目如何选择、获取和跟踪其依赖项的描述。
{N/A理由}
{满足URL}
[osps_do_06_01]
-
在活动期间，项目文档必须包含有权访问敏感资源的项目成员列表。
{N/A理由}
{满足URL}
[osps_gv_01_01]
-
在活动期间，项目文档必须包含项目成员的角色和责任的描述。
{N/A理由}
{满足URL}
[osps_gv_01_02]
-
在活动期间，项目文档必须包含代码贡献者指南，其中包括可接受贡献的要求。
{N/A理由}
{满足URL}
[osps_gv_03_02]
-
处于活跃状态时，版本控制系统必须要求所有代码贡献者在每次提交时断言他们有合法授权提交相关的贡献。
{N/A理由}
{满足URL}
[osps_le_01_01]
-
当向主分支提交时，必须通过或手动绕过提交的任何自动化状态检查。
{N/A理由}
{满足URL}
[osps_qa_03_01]
-
在接受提交之前，项目的CI/CD管道必须运行至少一个自动化测试套件，以确保更改符合预期。
{N/A理由}
{满足URL}
[osps_qa_06_01]
-
当项目发布版本时，项目文档必须包括设计文档，展示系统中的所有操作和参与者。
{N/A理由}
{满足URL}
[osps_sa_01_01]
-
当项目发布版本时，项目文档必须包括对已发布软件资产的所有外部软件接口的描述。
{N/A理由}
{满足URL}
[osps_sa_02_01]
-
当项目发布版本时，项目必须执行安全评估，以了解软件中可能发生的最可能和最具影响力的潜在安全问题。
{N/A理由}
{满足URL}
[osps_sa_03_01]
-
处于活跃状态时，项目文档必须包括协调漏洞披露（CVD）的政策，并有明确的响应时间框架。
{N/A理由}
{满足URL}
[osps_vm_01_01]
-
处于活跃状态时，项目文档必须提供一种方法，用于直接向项目内的安全联系人私下报告漏洞。
{N/A理由}
{满足URL}
[osps_vm_03_01]
-
处于活跃状态时，项目文档必须公开发布有关已发现漏洞的数据。
{N/A理由}
{满足URL}
[osps_vm_04_01]
基准等级3
通用
控制
-
当在CI/CD管道中为作业分配权限时，源代码或配置必须仅分配相应活动所需的最低权限。
{N/A理由}
{满足URL}
[osps_ac_04_02]
-
当创建正式发布版本时，该发布版本中的所有资产必须明确关联到发布标识符或资产的其他唯一标识符。
{N/A理由}
{满足URL}
[osps_br_02_02]
-
项目必须定义管理项目使用的秘密和凭证的策略。该策略应包括存储、访问和轮换秘密和凭证的指南。
{N/A理由}
{满足URL}
[osps_br_07_02]
-
当项目已发布版本时，项目文档必须包含验证发布资产完整性和真实性的说明。
{N/A理由}
{满足URL}
[osps_do_03_01]
-
当项目已发布版本时，项目文档必须包含验证软件发布作者的预期身份的说明。
{N/A理由}
{满足URL}
[osps_do_03_02]
-
当项目已发布版本时，项目文档必须包含关于每个发布版本支持范围和持续时间的描述性声明。
{N/A理由}
{满足URL}
[osps_do_04_01]
-
当项目已发布版本时，项目文档必须提供描述性声明说明何时发布版本或版本将不再接收安全更新。
{N/A理由}
{满足URL}
[osps_do_05_01]
-
在活跃期间，项目文档必须有一个策略，要求在授予对敏感资源的提升权限之前审查代码协作者。
{N/A理由}
{满足URL}
[osps_gv_04_01]
-
当项目已发布版本时，所有编译的已发布软件资产必须附带软件物料清单。
{N/A理由}
{满足URL}
[osps_qa_02_02]
-
当项目已发布包含多个源代码仓库的版本时，所有子项目必须执行与主代码库一样严格或更严格的安全要求。
{N/A理由}
{满足URL}
[osps_qa_04_02]
-
在活跃期间，项目文档必须清楚地记录测试何时以及如何运行。
{N/A理由}
{满足URL}
[osps_qa_06_02]
-
在活跃期间，项目的文档必须包含一项政策，即对项目生成的软件的所有重大更改都应该在自动化测试套件中添加或更新功能测试。
{N/A理由}
{满足URL}
[osps_qa_06_03]
-
当向主分支提交时，项目的版本控制系统必须在合并之前要求至少一名非作者人工审批更改。
{N/A理由}
{满足URL}
[osps_qa_07_01]
-
当项目发布版本时，项目必须执行威胁建模和攻击面分析，以理解和防护针对系统内关键代码路径、函数和交互的攻击。
{N/A理由}
{满足URL}
[osps_sa_03_02]
-
在活跃期间，软件组件中不影响项目的任何漏洞必须在VEX文档中予以说明，并以不可利用性细节补充漏洞报告。
{N/A理由}
{满足URL}
[osps_vm_04_02]
-
在活跃期间，项目文档必须包含一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。
{N/A理由}
{满足URL}
[osps_vm_05_01]
-
在活跃期间，项目文档必须包含一项政策，在任何发布之前解决SCA违规问题。
{N/A理由}
{满足URL}
[osps_vm_05_02]
-
在活跃期间，对项目代码库的所有更改必须根据记录的恶意依赖项和依赖项中已知漏洞的政策自动评估，然后在违规的情况下阻止，除非声明并抑制为不可利用。
{N/A理由}
{满足URL}
[osps_vm_05_03]
-
在活跃期间，项目文档必须包含一项政策，定义SAST发现的修复阈值。
{N/A理由}
{满足URL}
[osps_vm_06_01]
-
在活跃期间，对项目代码库的所有更改必须根据记录的安全弱点政策自动评估，并在违规的情况下阻止，除非声明并抑制为不可利用。
{N/A理由}
{满足URL}
[osps_vm_06_02]