FLOSS 最佳实践标准（通过徽章）
这是自由/自由和开源软件（FLOSS）项目的最佳实践集，以在通过，银色和金色徽章级别获得核心基础设施计划（OpenSSF）最佳实践徽章。您可以仅使用标准或其他信息来显示此列表。您还可以仅查看通过，银和金标准，以及全套标准。
有关这些条件的更多信息，请参见条件讨论。
通过
基本
基本项目网站内容
FLOSS许可证
-
项目生产的软件必须作为FLOSS发布。
[floss_license]
- 详细信息:
-
- FLOSS是以符合开源定义或免费软件定义。此类许可证的示例包括 CC0 ， MIT ， BSD 2条款， BSD 3条款修订版， Apache 2.0 ， Lesser GNU通用公共许可证（LGPL），以及 GNU通用公共许可证（GPL）。为了我们的目的，这意味着许可证必须是：该软件也可以用其他许可证（例如，“GPLv2或专有”是可以接受的）。
-
建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。
[floss_license_osi]
- 详细信息:
-
- OSI （开放源代码促进会）使用严格的审批流程来确定哪些许可证是开源软件（OSS）。
-
项目必须将其许可证在其源代码存储库中的标准位置发布。
{Met URL}
[license_location]
- 详细信息:
-
- 一种约定是将许可证发布为名为LICENSE或COPYING的顶级文件，其后可以带有扩展名，例如“ .txt”或“ .md”。另一种约定是使用一个名为LICENSES的目录，其中包含许可证文件。这些文件通常被命名为其SPDX许可证标识符，后跟适当的文件扩展名，如REUSE Specification中所述。请注意，此标准只是源存储库上的要求。从源代码生成某些内容（例如可执行文件，程序包或容器）时，无需包括许可证文件。例如，在为综合R存档网络（CRAN）生成R软件包时，请遵循标准CRAN惯例：如果许可证是标准许可证，请使用标准简短许可证规范（以避免安装另一文本副本）并列出排除文件（例如.Rbuildignore）中的LICENSE文件。同样，在创建Debian软件包时，您可以在版权文件中放置一个指向/ usr / share / common-licenses中的许可证文本的链接，并从创建的软件包中排除许可证文件（例如，通过在调用dh_auto_install之后删除文件） ）。我们鼓励在可行的情况下以生成的格式包含机器可读的许可证信息。
文档
-
项目必须为项目生成的软件提供基本文档。
{N/A justification}
[documentation_basics]
- 详细信息:
-
- 该文档必须在某些媒体（例如文本或视频）中，包括：如何安装它，如何启动它，如何使用它（可能使用教程使用示例）以及如何安全地使用它（例如，做什么和不做什么），如果这是软件的一个适当的话题。安全文档不需要太长篇幅。项目可以使用非项目内容的超文本链接作为文档。如果项目不生产软件，请选择“不适用”（N/A）。
-
项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。
{N/A justification}
[documentation_interface]
- 详细信息:
-
- 外部接口的文档向最终用户或开发人员解释如何使用它。这将包括其应用程序接口（API），如果软件有。如果它是一个库，记录可以调用的主要类/类型和方法/函数。如果是Web应用程序，定义其URL接口（通常是其REST接口）。如果是命令行界面，请记录其支持的参数和选项。在许多情况下，最好是自动生成大部分文档，以便本文档随着软件的更改而保持同步，但这并不是必需的。项目可以使用非项目材料的超文本链接作为文档。文档可以自动生成（实际上这通常是最好的方法）。可以使用Swagger / OpenAPI生成REST接口的文档。代码界面文档可以使用 JSDoc （JavaScript）， ESDoc （JavaScript），pydoc（Python）和Doxygen（很多）。仅在实现代码中添加注释不足以满足本条款；在没有阅读所有源代码的情况下，需要一个简单的方法来查看信息。如果项目不生产软件，请选择“不适用”（N/A）。
其他
-
项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。
[sites_https]
- 详细信息:
-
- 您可以从Let's Encrypt获取免费证书。项目可以使用（例如） GitHub页面实现此条款， GitLab页面，或 SourceForge项目页面。如果您使用具有自定义域的GitHub页面，则可以使用内容传送网络（CDN）作为代理来支持HTTPS，例如博客文章“使用CloudFlare安全加速GitHub页面”，以满足此条款。如果您支持HTTP，我们敦促您将HTTP流量重定向到HTTPS。
-
该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。
[discussion]
- 详细信息:
-
- 可接受机制的示例包括归档邮件列表，GitHub问题和拉请求讨论，Bugzilla，Mantis和Trac。如果满足这些标准，异步讨论机制（如IRC）是可以接受的；确保有一个URL可访问归档机制。允许专有JavaScript，但不鼓励。
-
项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。
[english]
- 详细信息:
-
- 英语是计算机技术的通用语言；支持英语增加了全球不同潜在开发者和检视者的数量。即使核心开发人员的主要语言不是英文，项目也可以达到这个标准。
-
必须维护该项目。
[maintained]
- 详细信息:
-
- 至少，项目应尝试响应重大问题和漏洞报告。可能正在维护一个积极追求徽章的项目。所有项目和人员的资源都有限，典型项目必须拒绝某些提议的更改，因此有限的资源和提议拒绝本身并不表示未维护的项目。
当项目知道将不再维护该项目时，应将此标准设置为“未满足”，并使用适当的机制向其他人指示该项目将不会得到维护。例如，使用“ DEPRECATED”作为其自述文件的第一个标题，在其主页开头附近添加“ DEPRECATED”，在其代码存储库项目说明的开头添加“ DEPRECATED”，在其中添加无需维护的标志其自述文件和/或主页，在任何软件包存储库中将其标记为已弃用（例如npm deprecate ），和/或使用代码存储库的标记系统对其进行归档（例如GitHub的“ archive”设置，GitLab的“ archived”标记， Gerrit的“只读”状态，或SourceForge的“已放弃”项目状态）。可以在这里找到更多讨论。
变更控制
公开的版本控制的源代码存储库
-
该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。
[repo_public]
- 详细信息:
-
- 该URL可以与项目URL相同。该项目可能在特定情况下使用私人（非公开）分支，而更改不会公开发布（例如，在向公众披露漏洞之前修复漏洞）。
-
项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。
[repo_track]
-
为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。
[repo_interim]
- 详细信息:
-
- 项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。
-
建议使用通用分布式版本控制软件（例如，git）作为项目的源代码存储库。
[repo_distributed]
- 详细信息:
-
- Git不是必须，项目在合适场景可以使用集中版本控制软件（如subversion）。
唯一版本编号
-
项目生成的用于每个用户使用的版本必须具有唯一版本标识符。
[version_unique]
- 详细信息:
-
- 本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。
-
建议使用语义版本控制（SemVer）格式进行发布。
[version_semver]
- 详细信息:
-
- 其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。
-
建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。
[version_tags]
发行说明
-
该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。
{N/A justification}
{Met URL}
[release_notes]
- 详细信息:
-
- 发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。
-
发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。
{N/A justification}
[release_notes_vulns]
- 详细信息:
-
- 如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。
报告
错误报告流程
-
项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。
{Met URL}
[report_process]
-
项目必须使用问题跟踪器来跟踪每个问题。
[report_tracker]
-
该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。
[report_responses]
-
该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。
[enhancement_responses]
- 详细信息:
-
- 答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。
-
该项目必须有一个公开的报告和回复的档案供后续搜索。
{Met URL}
[report_archive]
漏洞报告流程
-
项目必须在项目网站上发布报告漏洞的流程。
{Met URL}
[vulnerability_report_process]
- 详细信息:
-
- 例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。
-
如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。
{N/A allowed}
{Met URL}
[vulnerability_report_private]
- 详细信息:
-
- 示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。
-
该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。
{N/A allowed}
[vulnerability_report_response]
- 详细信息:
-
- 如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。
质量
可工作的构建系统
-
如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。
{N/A allowed}
[build]
- 详细信息:
-
- 构建系统确定重建软件（以及以什么顺序）需要执行哪些操作，然后执行这些步骤。例如，它可以调用编译器来编译源代码。如果从源代码创建可执行文件，则必须可以修改项目的源代码，然后通过这些修改生成更新的可执行文件。如果项目生成的软件取决于外部库，则构建系统不必构建那些外部库。如果在修改源代码之后不需要构建任何使用该软件的软件，请选择“不适用”（N/A）。
-
建议使用通用工具来构建软件。
{N/A allowed}
[build_common_tools]
- 详细信息:
-
- 例如，Maven，Ant，cmake，自动工具，make，rake（Ruby）或devtools （R）。
-
该项目应该仅使用FLOSS工具来构建。
{N/A allowed}
[build_floss_tools]
自动测试套件
-
该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。
[test]
- 详细信息:
-
- 该项目可以使用多个自动测试套件（例如，一个是快速运行的测试套件，而另一个更为彻底但需要特殊设备）。
-
测试套件应该以该语言的标准方式进行调用。
[test_invocation]
- 详细信息:
-
- 例如“make check”，“mvn test”或“rake test”。
-
建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。
[test_most]
-
建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。
[test_continuous_integration]
新功能测试
-
该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。
[test_policy]
- 详细信息:
-
- 只要有相应的策略，即使是通过口头传播，也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试，选择“Met”。
-
该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。
[tests_are_added]
- 详细信息:
-
- 主要功能通常在发行说明中提及。不需要完美，只需证明，当新的主要功能添加到项目生成的软件时，测试通常会在实践中被添加到自动化测试套件中。
-
建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。
[tests_documented_added]
- 详细信息:
-
- 但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。
警告标志
-
该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。
{N/A allowed}
[warnings]
- 详细信息:
-
- 编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。
-
该项目必须处理警告。
{N/A allowed}
[warnings_fixed]
- 详细信息:
-
- 告警是通过执行warnings条款确定的。该项目应该修复告警或在源代码中将其标记为误报。理想情况下，不会有告警，但项目可能会接受一些告警（通常每100行小于1个告警，或整体少于10个告警）。
-
建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。
{N/A allowed}
[warnings_strict]
- 详细信息:
-
- 某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。
安全
安全开发知识
-
该项目必须至少有一个主要开发人员知道如何设计安全软件。
[know_secure_design]
- 详细信息:
-
- 这需要了解以下设计原则，包括 Saltzer和Schroeder 中的8项原则：
- 机制经济（保持设计简单实用，例如采用彻底简化）
- 故障安全默认（默认情况下，访问决策应拒绝），项目安装应默认安全）
- 完全仲裁（必须检查每个可能被限制的访问权限，并且不可绕过）
- 开放式设计（安全机制不应该依赖于攻击者对其设计的无知，而应该更容易地保护和更改信息，例如密钥和密码）
- 特权分离（理想情况下，对重要对象的访问应该取决于多个条件，从而破坏一个保护系统将无法实现完全访问。如，多因子身份验证，要求密码和硬件令牌，比单因子认证安全性更高）
- 最小权限（进程应该以最少的权限运行）
- 最少的公共机制（设计应该最大限度地减少所有用户所依赖的，涉及到多个用户的共同机制，如，临时文件的目录）
- 心理可接受性（人机接口必须设计为易于使用 —— 设计为“最不惊讶”）
- 有限的攻击面（攻击面 —— 一组不同的入口，其中攻击者可以尝试输入或提取数据 —— 应该受到限制）
- 输入验证与白名单（输入通常应该在被接受之前检查以确定是否有效；此验证应使用白名单（仅接受已知的有效值），而不是黑名单（尝试列出已知的非法值））。
项目中的“主要开发人员”的定义是熟悉项目代码的任何人，很乐意对其进行更改，并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码，文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员，如果他们启动项目（并且还没有离开项目满三年），可以选择在私人漏洞报告渠道（如果有的话）上接收信息，可以代表项目接受提交，或执行项目软件的最终版本发布。如果只有一个开发者，那个人是主要开发人员。
-
该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。
[know_common_errors]
- 详细信息:
-
- 示例（取决于软件的类型）包括SQL注入，操作系统注入，经典缓冲区溢出，跨站点脚本（XSS），缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞或 OWASP十大漏洞类型项目。
使用基础的良好加密实践
-
项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。
{N/A allowed}
[crypto_published]
- 详细信息:
-
- 这些加密条款并不总是适用，因为某些软件不需要直接使用加密功能。
-
如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。
{N/A allowed}
[crypto_call]
-
项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。
{N/A allowed}
[crypto_floss]
- 详细信息:
-
- 请参阅OSI （开放源代码促进会）发布的软件开放标准需求。
-
项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。
{N/A allowed}
[crypto_keylength]
- 详细信息:
-
- 这些最小位长度是：对称密钥112，因式分解模数2048，离散对数密钥224，离散对数组2048，椭圆曲线224和散列224（密码散列不涉及该位长度），关于密码散列的更多信息可以在 crypto_password_storage 条款）。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中，软件可能允许较小的密钥长度（理想情况下不会，因为这允许降级攻击，但是互操作性有时需要较短的密钥长度）。
-
项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。
{N/A allowed}
[crypto_working]
- 详细信息:
-
- 在许多情况下，最好选择设计用于组合保密和认证的块密码算法模式，例如Galois / Counter Mode（GCM）和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制，但是需要用户知道他们正在这么做。
-
由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。
{N/A allowed}
[crypto_weaknesses]
- 详细信息:
-
- 在 CERT：SSH CBC漏洞中讨论了SSH中CBC模式的问题。
-
项目产生的软件中的安全机制应该对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。
{N/A allowed}
[crypto_pfs]
-
如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。
{N/A allowed}
[crypto_password_storage]
- 详细信息:
-
- 此条款仅适用于软件强制使用密码验证用户身份的情况（如服务器端Web应用程序）。在软件存储用于认证到其他系统的密码（例如，该软件实现某个其他系统的客户端）的情况下，这是不适用的，因为该软件的至少某个部分必须经常访问未散列加密的密码。
-
由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。
{N/A allowed}
[crypto_random]
- 详细信息:
-
- 密码安全的随机数生成器可以是硬件随机数生成器，或者它可以是使用诸如Hash_DRBG，HMAC_DRBG，CTR_DRBG，Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器（CSPRNG）。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的Math.random。
安全交付防御中间人（MITM）的攻击
-
该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。
[delivery_mitm]
- 详细信息:
-
- 一个更强大的机制是使用数字签名的软件包发布软件，因为这样可以减轻对分发系统的攻击，但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。
-
不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。
[delivery_unsigned]
- 详细信息:
-
- 这些散列可以在传输过程中修改。
修正公开的漏洞
其他安全问题
-
公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。
[no_leaked_credentials]
- 详细信息:
-
- 项目可以泄漏测试和不重要数据库的“样本”凭据，只要它们不旨在限制公共访问。
分析
静态代码分析
动态代码分析