FLOSS 最佳实践标准（白银徽章）
这是自由/自由和开源软件（FLOSS）项目的最佳实践集，以在通过，银色和金色徽章级别获得核心基础设施计划（OpenSSF）最佳实践徽章。您可以仅使用标准或其他信息来显示此列表。您还可以仅查看通过，银和金标准，以及全套标准。
有关这些条件的更多信息，请参见条件讨论。
白银
基本
先决条件
基本项目网站内容
项目监督
-
该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（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]
文档
无障碍和国际化
-
该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。
{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]
漏洞报告流程
质量
编码标准
可工作的构建系统
-
本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器（环境）变量（例如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]
-
该项目必须满足下述情况之一：
- 可以轻松识别和更新重用的外部维护组件; 或
- 使用系统或编程语言提供的标准组件。
这样，如果在重用的组件中发现了一个漏洞，将容易更新该组件。
{N/A justification}
{Met justification}
[updateable_reused_components]
-
该项目应避免使用已弃用或过时的功能和API，如果FLOSS替代品在其使用的技术集合（“技术堆栈”）中以及项目支持的大多数用户中可用（以便用户可以随时访问该替代品）。
{N/A justification}
{Met justification}
[interfaces_current]
自动测试套件
新功能测试
-
该项目必须具有正式的书面策略，一旦添加了主要的新功能，新功能的测试必须被添加到自动测试套件中。
{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]
分析
静态代码分析
动态代码分析
-
如果由项目生成的软件包含使用内存不安全语言编写的软件（例如，C或C ++），则项目必须至少使用一个动态工具（例如，fuzzer或web应用扫描程序）与一种检测缓冲区覆写等内存安全问题的机制组合例行使用。如果项目不生成以内存不安全语言编写的软件，请选择“不适用”（N/A）。
{N/A justification}
{Met justification}
[dynamic_analysis_unsafe]