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

白银

基本

先决条件

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

基本项目网站内容

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

项目监督

• 该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。 {满足URL} ^[dco]

  详细信息:

  DCO是推荐的机制，因为它易于实现，在源代码中进行跟踪，并且git使用“commit -s”直接支持“签名”功能。更有效的是，项目文件解释了该项目的“签名”手段。 CLA是一项法律协议，用于定义知识产权许可给组织或项目的条款。捐助者转让协议（CAA）是将知识产权权利转让给另一方的法律协议；项目不必具备CAA，因为CAA增加了潜在贡献者不愿贡献的风险，特别是如果接收者是一个营利性组织。 Apache Software Foundation CLA（个人贡献者许可证和公司CLA）是CLA的示例，用于确定项目的这些CLA的风险对项目的影响小于其获益。

• 该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。 {满足URL} ^[governance]

  详细信息:

  需要有一些成熟的书面方式来作出决定和解决争端。在小项目中，这可能就像“项目拥有者和负责人做所有最终决定”一样简单。有各种治理模式，包括仁慈的独裁者和正式的精英统治；有关详细信息，请参阅治理模式。集中式（例如，单一维护者）和分散式（例如，组维护者）方法都已经在项目中成功使用。治理信息不需要记录创建项目分支的可能性，因为对于FLOSS项目来说总是可能的。

• 该项目必须采取行为守则，并将其发布在标准的位置。 {满足URL} ^{[code_of_conduct]}

  详细信息:

  项目可能能够提高社区的文明程度，并通过采取行为守则来规定对可接受的行为的期望。这可以帮助在发生问题之前避免问题，并使项目成为更加欢迎的地方来鼓励贡献。这应该只关注项目社区/工作场所的行为。行为规范的示例是贡献者约定行为准则和Linux内核代码冲突。

• 该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。 {满足URL} ^{[roles_responsibilities]}

  详细信息:

  治理和角色和职责的文档可以在一个地方。

• 如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。 {满足URL} ^{[access_continuity]}
• 项目必须具有2个或更多的“公交车因子”。 {满足URL} ^[bus_factor]

  详细信息:

  “公交车系数”（又名“卡车因子”）是指最少数量的项目成员，如果突然离开项目（“被公交车撞了”），项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息，请参阅Cosentino等人的评估Git存储库的卡车因子。

文档

• 该项目必须有一个文档化的路线图，描述项目打算做什么，至少在下一年做什么。 {满足URL} ^{[documentation_roadmap]}

  详细信息:

  项目可能没有实现路线图，没关系。路线图的目的是帮助潜在的用户和贡献者了解项目的预期方向。它不需要特别详细。

• 该项目必须包括项目生成的软件的架构（也称为高级别设计）的文档。如果项目不产生软件，请选择“不适用”（N/A）。 {N/A理由} {满足URL} ^{[documentation_architecture]}

  详细信息:

  软件架构解释了程序的基本结构，即程序的主要组件，它们之间的关系以及这些组件和关系的关键属性。

• 该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容（其“安全需求”）。 {允许N/A} {满足URL} ^{[documentation_security]}

  详细信息:

  这些是软件意图满足的安全需求。

• 该项目必须为新用户提供“快速启动”指南，以帮助他们快速使用该软件。 {N/A理由} {满足URL} ^{[documentation_quick_start]}

  详细信息:

  这个想法是向用户展示如何入门，使软件完全可以做事情。这对于潜在用户是至关重要的。

• 项目必须努力使文档与当前版本的项目结果（包括项目生成的软件）保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的，但是错误地包括一些不再是真实的旧信息，那么将其视为缺陷，然后像往常一样进行跟踪和修复。 {N/A理由} {满足理由} ^{[documentation_current]}

  详细信息:

  该文档可以包括有关软件版本之间的差异或更改的信息，与/或链接到旧版本的文档。这个条款的意图在于努力保持文档的一致性，而不是文档必须完美。

• 项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就，包括此最佳实践徽章。 {满足URL} ^{[documentation_achievements]}

  详细信息:

  一个成就是项目致力于满足的任何外部条款，包括徽章。该信息不需要在项目网站首页上。使用GitHub的项目可以通过将其添加到README文件中，将成果放在存储代码库首页。

无障碍和国际化

• 该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。 {N/A理由} {满足理由} ^{[accessibility_best_practices]}

  详细信息:

  对于Web应用程序，请参阅 Web 内容无障碍指导 (WCAG 2.0，英文) 以及其支持文档 理解 WCAG 2.0（英文）；或者 W3C 无障碍信息（英文）. 图形界面（GUI）应用考虑使用环境特定的无障碍指导（例如 Gnome, KDE, XFCE, Android, iOS, Mac, 以及 Windows). 一些TUI应用 (例如，`ncurses` 程序) 可以做一些特定的工作，增强可访问性（例如，`alpine` 的 `force-arrow-cursor` 设置）。多数命令行应用没有特别的无障碍设置。本条款经常是不涉及（N/A），例如，对于组件库。以下是一些要采取的行动或需要考虑的问题的例子：

  • 提供非文字内容的文字替代，以便于转换为其他需要的格式，如大字体、盲文、语音、符号或者简单文字（ WCAG 2.0 指导 1.1 （英文）)
  • 颜色不被用作传达信息，指示动作，提示响应或区分视觉元素的唯一视觉方式。 ( WCAG 2.0 指导 1.4.1（英文）)
  • 文本和文字图像的视觉呈现对比度至少为4.5：1，除了大文本，次要文本和标识符之外。 ( WCAG 2.0 指导 1.4.3（英文）)
  • 使用键盘可访问所有功能 (WCAG 指导 2.1)
  • 图形界面应用（GUI）或者Web应用在目标平台上，应该至少使用一种屏幕阅读器测试（例如，NVDA；Jaws；Windows上的WindowEyes；Mac & iOS上的VoiceOver；Linux/BSD上的Orca；Android上的TalkBack）。TUI程序可以减少过度渲染以防止屏幕阅读器的冗余读取。

• 该项目产生的软件应该被国际化，以便为目标受众的文化，地区或语言进行简单的本地化。如果国际化（i18n）不适用（例如，该软件不会生成针对最终用户的文本，并且不排序可读文本），请选择“不适用”（N/A）。 {N/A理由} {满足理由} ^{[internationalization]}

  详细信息:

  本地化“是指适应产品，应用或文档内容以满足特定目标市场（语言环境）的语言，文化和其他要求。国际化是“设计和开发产品，应用或文档内容，使不同文化，地区或语言的目标受众更容易本地化”。 （请参阅 W3C的“本地化与国际化”）。软件只需通过国际化即可达到此标准。不需要另一种特定语言的本地化，因为一旦软件已被国际化，其他人就可以从事本地化。

其他

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

  详细信息:

  请注意，使用 GitHub 符合此条款。此条款仅适用于用于外部用户认证到项目站点的密码。如果项目站点必须登录到其他站点，则可能需要为此目的存储密码（因为使用像Bcrypt这样的算法会使这些密码无效）。本条款将 crypto_password_storage 条款应用于项目站点，类似于sites_https条款。

变更控制

之前的版本

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

报告

错误报告流程

• 项目必须使用问题跟踪器来跟踪每个问题。 {N/A理由} {满足理由} ^{[report_tracker]}

漏洞报告流程

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

  详细信息:

  这与security_report_process有很强的相关性，它需要有一个书面的流程来报告漏洞。它还涉及到spam_report_response，它需要在一定时间内响应漏洞报告。

质量

编码标准

• 该项目必须确定其使用的主要语言的具体编码风格指南，并要求贡献一般情况下符合此要求。 {N/A理由} {满足URL} ^{[coding_standards]}

  详细信息:

  在大多数情况下，这是通过参考一些现有的风格指南来完成的，可能列出差异。这些风格指南可以包括提高可读性的方法和减少缺陷可能性（包括漏洞）的方法。许多编程语言有一个或多个广泛使用的风格指南。样式指南的示例包括 Google风格指南（英文）和 SEI CERT编码标准（英文）。

• 如果至少有一个FLOSS工具可以应用于所选择的语言，项目必须自动执行其选定的编码风格。 {N/A理由} {满足理由} ^{[coding_standards_enforced]}

  详细信息:

  这可以使用静态分析工具和/或通过代码重新格式化强制代码实现。在许多情况下，工具配置包含在项目的存储库中（因为不同的项目可能会选择不同的配置）。项目可以允许风格例外（通常会）；在发生例外的情况下（应该很少），它们必须在其位置的代码中记录在案，以便可以对这些例外进行检视，并使工具能够在将来自动处理它们。这些工具的例子包括ESLint（JavaScript）和Rubocop（Ruby）。

可工作的构建系统

• 本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器（环境）变量（例如CC，CFLAGS，CXX，CXXFLAGS和LDFLAGS），并将它们传递给编译器和链接器。构建系统可以使用附加标志来扩展它们，但不能简单地用自己的替换提供的值。如果没有生成本地二进制文件，请选择“不适用”（N/A）。 {N/A理由} {满足理由} ^{[build_standard_variables]}

  详细信息:

  应该很容易启用特殊的构建功能，如地址消毒剂（Address Sanitizer，ASAN），或符合发布加固最佳实践（例如，通过轻松打开编译器标志来实现）。

• 构建和安装系统在在相关标志中要求时，应该保留调试信息（例如，“install -s”未被使用）。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 {N/A理由} {满足理由} ^{[build_preserve_debug]}

  详细信息:

  例如，如果使用这些语言，则应该设置CFLAGS（C）或CXXFLAGS（C ++）创建相关的调试信息，并且在安装过程中不应该剥离它们。支持和分析时，需要调试信息，也可用于测量编译二进制文件中加固特性的存在。

• 如果子目录中存在交叉依赖关系，则由项目生成的软件的构建系统必须不能递归地构建子目录。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 {N/A理由} {满足理由} ^{[build_non_recursive]}

  详细信息:

  项目构建系统的内部依赖关系信息需要准确，否则，对项目的更改可能无法正确构建。不正确的构建可能会导致缺陷（包括漏洞）。大型构建系统中的常见错误是使用“递归构建”或“递归生成”，即包含源文件的子目录的层次结构，其中每个子目录都是独立构建的。除非每个子目录完全独立，否则这是一个错误，因为依赖关系信息不正确。

• 该项目必须能够重复从源代码文件生成的过程，并获得完全相同的比特位结果。如果没有发生构建（例如，直接使用源代码而不是编译使用的脚本语言），请选择“不适用”（N/A）。 {N/A理由} {满足理由} ^{[build_repeatable]}

  详细信息:

  GCC和clang用户可能会发现-frandom-seed选项有用；在某些情况下，这可以通过强制某种排序来解决。更多建议可以在可重复构建（英文）站点找到。

安装系统

• 该项目必须提供一种使用常用惯例轻松安装和卸载由项目生成的软件的方法。 {N/A理由} {满足理由} ^{[installation_common]}

  详细信息:

  示例包括使用软件包管理器（在系统或语言级别），“make install/uninstall”（支持DESTDIR），标准格式的容器或标准格式的虚拟机映像。安装和卸载过程（例如，打包）可以由第三方FLOSS软件实现。

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

  详细信息:

  可以使用生成的容器和/或安装脚本来实现。外部依赖关系一般通过调用系统和/或语言包管理器（根据 external_dependencies 条款）进行安装。

外部维护的组件

• 项目必须以计算机可处理的方式列出外部依赖关系。 {N/A理由} {满足URL} ^{[external_dependencies]}

  详细信息:

  通常这是使用包管理器和/或构建系统的约定完成的。请注意，这有助于实施 installation_development_quick 。

• 项目必须监视或定期检查其外部依赖（包括便利副本）以检测已知的漏洞，并修复可利用的漏洞或将其验证为不可利用的漏洞。 {N/A理由} {满足理由} ^{[dependency_monitoring]}

  详细信息:

  这可以使用源分析器/依赖项检查工具/软件组成分析工具（例如OWASP的Dependency-Check ， Sonatype的Nexus Auditor ， Synopsys的Black Duck软件组成分析和Bundler-audit（针对Ruby））来完成。一些程序包管理器包括执行此操作的机制。如果无法利用组件的漏洞，这是可以接受的，但是这种分析是困难的，有时简单地更新或修复零件就更容易。

• 该项目必须满足下述情况之一：
  1. 可以轻松识别和更新重用的外部维护组件; 或
  2. 使用系统或编程语言提供的标准组件。
  这样，如果在重用的组件中发现了一个漏洞，将容易更新该组件。 {N/A理由} {满足理由} ^{[updateable_reused_components]}

  详细信息:

  符合这一条款的典型方法是使用系统和编程语言的包管理系统。许多FLOSS程序与“便利库”一起分发，这些库是标准库的本地副本（可能是分支）。一般没问题。但是，如果程序*必须*使用这些本地（分支）副本，则“标准”库的安全更新将使这些附加副本仍然易受攻击。这对于基于云的系统尤其是一个问题；如果云提供商更新他们的“标准”库，但程序不会使用它们，那么这些更新实际上不会有帮助。参见，例如，“Chromium：为什么它不在Fedora中作为适当的包”（Tom Callaway）。

• 该项目应避免使用已弃用或过时的功能和API，如果FLOSS替代品在其使用的技术集合（“技术堆栈”）中以及项目支持的大多数用户中可用（以便用户可以随时访问该替代品）。 {N/A理由} {满足理由} ^{[interfaces_current]}

自动测试套件

• 必须将自动测试套件应用于至少一个分支的共享代码库的每次签入。该测试套件必须生成关于测试成功或失败的报告。 {满足理由} ^{[automated_integration_testing]}

  详细信息:

  这个要求可以被视为test_continuous_integration的一个子集，但是仅仅是测试，而不需要持续集成。

• 该项目必须为过去六个月内修复的至少50％的错误，在自动化测试套件中添加回归测试。 {N/A理由} {满足理由} ^{[regression_tests_added50]}
• 如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％语句覆盖率。 {N/A理由} {满足理由} ^{[test_statement_coverage80]}

  详细信息:

  许多FLOSS工具可用于度量测试覆盖范围，包括gcov / lcov，Blanket.js，Istanbul和JCov。请注意，满足这个条款并不能保证测试套件是完备的，而不满足该条款则意味着测试套件很差。

新功能测试

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

警告标志

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

安全

安全开发知识

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

  详细信息:

  例如，项目结果应该具有故障安全默认值（默认情况下，访问决策应该拒绝，默认情况下项目的安装应该是安全的），也应该有完全的仲裁（每一个可能被限制的访问权限必须被检查，不可绕过）。请注意，在某些情况下，原则会发生冲突，在这种情况下必须做出选择（例如，许多机制使事情更复杂，违反“机制经济”/“保持最简化”的原则）。

使用基础的良好加密实践

• 由项目产生的软件中的默认安全机制不得取决于具有已知严重弱点（例如，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证书验证是一个常见的错误。有关详细信息，请参阅“世界上最危险的代码：在非浏览器软件中验证SSL证书“，Martin Georgiev等人和 “你信任这个应用程序吗？”作者Michael Catanzaro

• 项目生成的软件（如果支持TLS）必须在发送具有私有信息（如安全Cookie）的HTTP头之前执行证书验证。如果软件不使用TLS，请选择“不适用”（N/A）。 {允许N/A} {满足理由} ^{[crypto_verification_private]}

安全发布

• 该项目必须加密签名旨在广泛使用的项目结果的发布，并且必须有一个书面流程，向用户解释如何获取公共签名密钥并验证签名。这些签名的私钥不得在项目网站上直接向公众发布。如果发行版本不适用于广泛使用，请选择“不适用”（N/A）。 {N/A理由} {满足理由} ^{[signed_releases]}

  详细信息:

  项目结果包括源代码和适用的任何生成的可交付成果（例如，可执行文件，包和容器）。生成的交付项可以单独签名源代码。可以用签名的git标签实现（使用加密数字签名）。项目可以从git类似的工具分别提供生成的结果，但在这些情况下，单独的结果必须单独签署。

• 建议在版本控制系统中，每个重要版本标签（作为主要版本的一部分的标签，次要版本或修复公开提到的漏洞）都按照signed_releases中的要求进行加密签名，并可验证。 {满足理由} ^{[version_tags_signed]}

其他安全问题

• 项目结果必须检查来自潜在不受信任来源的所有输入，以确保它们有效（ *白名单*），如果对数据有限制，则拒绝无效输入。 {N/A理由} {满足理由} ^{[input_validation]}

  详细信息:

  请注意，将输入与“不良格式”（*黑名单*）的列表进行比较通常是不够的，因为攻击者通常可以绕过黑名单。例如，数字被转换成内部格式，然后检查它们是否在最小和最大（包括）之间，并且检查文本字符串以确保它们是有效的文本模式（例如，有效的UTF-8，长度，语法等）。一些数据可能需要是“任何东西”（例如，文件上传器），但这些数据通常是罕见的。

• 加固机制应该用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 {N/A理由} {满足理由} ^[hardening]

  详细信息:

  加固机制可能包括HTTP头，如内容安全策略（CSP），用于减轻攻击的编译器标志（如-fstack-protector）或用以消除未定义行为的编译器标志。对于此条款的目的，最小权限不被认为是一种加固机制（最少权限是重要的，但是另有条款）。

• 该项目必须提供一个保证案例，证明其满足安全要求。保证案例必须包括：对威胁模型的描述，明确确定信任边界，确定设计原则得到适用，以及常见安全弱点已经被消减。 {满足URL} ^{[assurance_case]}

  详细信息:

  一个保证案例是“一个文献记录的证据体系，提供了一个有说服力和有效的论据，指出一组关于系统属性的关键权利要求在给定环境中给定应用程序是充分合理的”（使用结构化保证案例模型的软件保证，Thomas Rhodes等人，NIST机构间报告7608）。信任边界是数据或执行改变其信任级别的边界，例如，典型Web应用程序中的服务器边界。常见做法是列出安全设计原则（例如Saltzer和Schroeer）和常见的实施安全漏洞（例如OWASP前10名或CWE / SANS前25名），并显示每个方案如何抵御。 BadgeApp保证案例可能是一个有用的例子。本条款与documentation_security，documentation_architecture和implement_secure_design等条款有关。

分析

静态代码分析

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

动态代码分析

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

黄金

基本

先决条件

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

项目监督

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

  详细信息:

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

其他

• 该项目必须在每个源文件中包含一个版权声明，确定至少一个相关年份和版权所有者。 {满足理由} ^{[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]。 {满足理由} ^{[license_per_file]}

  详细信息:

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

变更控制

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

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

  详细信息:

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

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

  详细信息:

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

质量

编码标准

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

  详细信息:

  另请参阅 two_person_review 和contribution_requirements 条款。

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

可工作的构建系统

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

  详细信息:

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

自动测试套件

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

  详细信息:

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

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

安全

使用基础的良好加密实践

• 项目生成的软件必须支持所有网络通信的安全协议，如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]}

  详细信息:

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

其他安全问题

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

  详细信息:

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

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

分析

动态代码分析

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

基准等级1

通用

控制

• 当用户尝试读取或修改项目权威存储库中的敏感资源时，系统必须要求用户完成多因素认证过程。 {N/A理由} {满足URL} ^{[osps_ac_01_01]}

  详细信息:

  为项目的版本控制系统强制执行多因素认证，要求协作者在访问敏感数据或修改存储库设置时提供第二种形式的认证。通行密钥对于此控制是可接受的。

• 当添加新的协作者时，版本控制系统必须要求手动分配权限，或默认将协作者权限限制为可用的最低权限。 {N/A理由} {满足URL} ^{[osps_ac_02_01]}

  详细信息:

  大多数公共版本控制系统都是这样配置的。确保项目的版本控制系统在添加协作者时始终默认分配最低可用权限,仅在必要时授予额外权限。

• 当尝试直接提交到项目的主分支时,强制机制必须阻止该更改的应用。 {N/A理由} {满足URL} ^{[osps_ac_03_01]}

  详细信息:

  如果VCS是集中式的,请在项目的VCS中对主分支设置分支保护。或者,使用去中心化方法,如Linux内核的方法,即先在另一个仓库中提出更改,将更改合并到主仓库需要特定的单独操作。

• 当尝试删除项目的主分支时,版本控制系统必须将此视为敏感活动,并要求明确确认意图。 {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]}

  详细信息:

  配置项目的网站和版本控制系统使用SSH或HTTPS等加密渠道进行数据传输。确保项目文档中引用的所有工具和域名只能通过加密渠道访问。

• 当项目将URI列为官方分发渠道时,该URI必须仅通过加密渠道交付。 {N/A理由} {满足URL} ^{[osps_br_03_02]}

  详细信息:

  配置项目的发布管道,仅从使用SSH或HTTPS等加密渠道进行数据传输的网站、API响应和其他服务获取数据。

• 项目必须防止在版本控制系统中意外存储未加密的敏感数据,例如机密和凭据。 {N/A理由} {满足URL} ^{[osps_br_07_01]}

  详细信息:

  配置.gitignore或等效文件以排除可能包含敏感信息的文件。使用预提交钩子和自动扫描工具来检测和防止在提交中包含敏感数据。

• 当项目发布版本后,项目文档必须包含所有基本功能的用户指南。 {N/A理由} {满足URL} ^{[osps_do_01_01]}

  详细信息:

  为项目的所有基本功能创建用户指南或文档,说明如何安装、配置和使用项目的功能。如果存在任何已知的危险或破坏性操作,请包含高度可见的警告。

• 当项目发布版本后,项目文档必须包含缺陷报告指南。 {N/A理由} {满足URL} ^{[osps_do_02_01]}

  详细信息:

  建议项目使用其VCS默认问题跟踪器。如果使用外部来源,请确保项目文档和贡献指南清晰且明显地解释如何使用报告系统。建议项目文档还设定缺陷将如何分类和解决的期望。

• 在活跃期间,项目必须有一个或多个机制用于公开讨论提议的更改和使用障碍。 {N/A理由} {满足URL} ^{[osps_gv_02_01]}

  详细信息:

  在项目中建立一个或多个公开讨论机制,例如邮件列表、即时消息或问题跟踪器,以促进开放的沟通和反馈。

• 在活跃期间,项目文档必须包含贡献流程的说明。 {N/A理由} {满足URL} ^{[osps_gv_03_01]}

  详细信息:

  创建一个CONTRIBUTING.md或CONTRIBUTING/目录来概述贡献流程，包括提交更改的步骤以及与项目维护者互动的方式。

• 活跃期间，源代码的许可证必须符合OSI开源定义或FSF自由软件定义。 {N/A理由} {满足URL} ^{[osps_le_02_01]}

  详细信息:

  向项目的代码仓库添加一个LICENSE文件，其中包含开放源代码促进会（OSI）批准的许可证，或自由软件基金会（FSF）批准的自由许可证。此类许可证的示例包括MIT、BSD 2-Clause、BSD 3-Clause修订版、Apache 2.0、较宽松GNU通用公共许可证（LGPL）和GNU通用公共许可证（GPL）。如果没有其他限制（如专利），发布到公共领域可以满足此控制要求。

• 活跃期间，已发布软件资产的许可证必须符合OSI开源定义或FSF自由软件定义。 {N/A理由} {满足URL} ^{[osps_le_02_02]}

  详细信息:

  如果已发布软件资产包含不同的许可证，请确保它是开放源代码促进会（OSI）批准的许可证，或自由软件基金会（FSF）批准的自由许可证。此类许可证的示例包括MIT、BSD 2-Clause、BSD 3-Clause修订版、Apache 2.0、较宽松GNU通用公共许可证（LGPL）和GNU通用公共许可证（GPL）。请注意，已发布软件资产的许可证可能与源代码的许可证不同。

• 活跃期间，源代码的许可证必须保存在相应仓库的LICENSE文件、COPYING文件或LICENSE/目录中。 {N/A理由} {满足URL} ^{[osps_le_03_01]}

  详细信息:

  将项目的源代码许可证包含在项目的LICENSE文件、COPYING文件或LICENSE/目录中，以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库，请确保每个仓库都包含许可证文件。

• 活跃期间，已发布软件资产的许可证必须包含在已发布的源代码中，或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中。 {N/A理由} {满足URL} ^{[osps_le_03_02]}

  详细信息:

  将项目的已发布软件资产许可证包含在已发布的源代码中，或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中，以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库，请确保每个仓库都包含许可证文件。

• 活跃期间，项目的源代码仓库必须在静态URL上可公开读取。 {N/A理由} {满足URL} ^{[osps_qa_01_01]}

  详细信息:

  使用常见的版本控制系统（VCS），如GitHub、GitLab或Bitbucket。确保仓库可公开读取。避免重复或镜像仓库，除非有高度可见的文档说明主要来源。避免频繁更改会影响仓库URL的仓库。确保仓库是公开的。

• 版本控制系统必须包含所有更改的可公开读取的记录，包括谁进行了更改以及更改的时间。 {N/A理由} {满足URL} ^{[osps_qa_01_02]}

  详细信息:

  使用常见的版本控制系统（VCS），如GitHub、GitLab或Bitbucket来维护可公开读取的提交历史记录。避免压缩或重写提交，以免掩盖任何提交的作者。

• 当包管理系统支持时，源代码仓库必须包含一个依赖项列表，该列表涵盖直接的语言依赖项。 {N/A理由} {满足URL} ^{[osps_qa_02_01]}

  详细信息:

  这可以采用包管理器或语言依赖文件的形式，列举所有直接依赖项，如package.json、Gemfile或go.mod。

• 活跃期间，项目文档必须包含被视为子项目的任何代码库的列表。 {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]}

  详细信息:

  创建一个security.md（或类似名称）文件，其中包含项目的安全联系人。

基准等级2

通用

控制

• 当执行CI/CD任务且未指定权限时，CI/CD系统必须将任务的权限默认为管道中授予的最低权限。 {N/A理由} {满足URL} ^{[osps_ac_04_01]}

  详细信息:

  配置项目的设置，默认情况下为新管道分配最低可用权限，仅在特定任务需要时才授予额外权限。

• 当创建正式发布时，该发布必须分配一个唯一的版本标识符。 {N/A理由} {满足URL} ^{[osps_br_02_01]}

  详细信息:

  为项目生成的每个发布分配一个唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交id。

• 当创建正式发布时，该发布必须包含功能和安全修改的描述性日志。 {N/A理由} {满足URL} ^{[osps_br_04_01]}

  详细信息:

  确保所有发布都包含描述性的变更日志。建议确保变更日志是人类可读的，并且包含超出提交消息的详细信息，例如安全影响的描述或与不同用例的相关性。为确保机器可读性，请将内容放在markdown标题下，例如"## Changelog"。

• 当构建和发布管道摄取依赖项时，它必须使用标准化工具（如果可用）。 {N/A理由} {满足URL} ^{[osps_br_05_01]}

  详细信息:

  为您的生态系统使用通用工具，例如包管理器或依赖项管理工具，以在构建时摄取依赖项。这可能包括使用依赖项文件、锁文件或清单来指定所需的依赖项，然后由构建系统拉入。

• 当创建正式发布时，该发布必须进行签名或在包含每个资产加密哈希值的签名清单中进行说明。 {N/A理由} {满足URL} ^{[osps_br_06_01]}

  详细信息:

  在构建时使用加密签名或证明（例如GPG或PGP签名、Sigstore签名、SLSA来源或SLSA VSA）对所有发布的软件资产进行签名。在签名清单或元数据文件中包含每个资产的加密哈希值。

• 当项目发布版本后，项目文档必须包含项目如何选择、获取和跟踪其依赖项的描述。 {N/A理由} {满足URL} ^{[osps_do_06_01]}

  详细信息:

  建议在可公开查看的资源（如源代码存储库、项目网站或其他渠道）上与项目的技术和设计文档一起发布此信息。

• 在活动期间，项目文档必须包含有权访问敏感资源的项目成员列表。 {N/A理由} {满足URL} ^{[osps_gv_01_01]}

  详细信息:

  通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。这可以简单到在维护者列表中包含姓名或账户句柄，或者根据项目的治理更复杂。

• 在活动期间，项目文档必须包含项目成员的角色和责任的描述。 {N/A理由} {满足URL} ^{[osps_gv_01_02]}

  详细信息:

  通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。

• 在活动期间，项目文档必须包含代码贡献者指南，其中包括可接受贡献的要求。 {N/A理由} {满足URL} ^{[osps_gv_03_02]}

  详细信息:

  扩展项目文档中的CONTRIBUTING.md或CONTRIBUTING/的内容，以概述可接受的贡献要求，包括编码标准、测试要求和代码贡献者的提交指南。建议将该指南作为贡献者和批准者的真实来源。

• 处于活跃状态时，版本控制系统必须要求所有代码贡献者在每次提交时断言他们有合法授权提交相关的贡献。 {N/A理由} {满足URL} ^{[osps_le_01_01]}

  详细信息:

  在项目的代码库中包含一个DCO，要求代码贡献者在每次提交时断言他们有合法授权提交相关贡献。使用状态检查以确保完成此断言。CLA也满足此要求。某些版本控制系统（例如GitHub）可能会在平台服务条款中包含此项。

• 当向主分支提交时，必须通过或手动绕过提交的任何自动化状态检查。 {N/A理由} {满足URL} ^{[osps_qa_03_01]}

  详细信息:

  配置项目的版本控制系统，要求所有自动化状态检查通过或在提交合并到主分支之前需要手动确认。建议不要将任何可选状态检查配置为批准者可能会绕过的通过或失败要求。

• 在接受提交之前，项目的CI/CD管道必须运行至少一个自动化测试套件，以确保更改符合预期。 {N/A理由} {满足URL} ^{[osps_qa_06_01]}

  详细信息:

  应在每次合并到主分支之前运行自动化测试。测试套件应在CI/CD管道中运行，结果应对所有贡献者可见。测试套件应在一致的环境中运行，并应以允许贡献者在本地运行测试的方式运行。测试套件的示例包括单元测试、集成测试和端到端测试。

• 当项目发布版本时，项目文档必须包括设计文档，展示系统中的所有操作和参与者。 {N/A理由} {满足URL} ^{[osps_sa_01_01]}

  详细信息:

  在项目文档中包括说明操作和参与者的设计。参与者包括可以影响系统中另一段的任何子系统或实体。确保为新功能或重大更改更新此文档。

• 当项目发布版本时，项目文档必须包括对已发布软件资产的所有外部软件接口的描述。 {N/A理由} {满足URL} ^{[osps_sa_02_01]}

  详细信息:

  记录已发布软件资产的所有软件接口（API），解释用户如何与软件交互以及期望或产生什么数据。确保为新功能或重大更改更新此文档。

• 当项目发布版本时，项目必须执行安全评估，以了解软件中可能发生的最可能和最具影响力的潜在安全问题。 {N/A理由} {满足URL} ^{[osps_sa_03_01]}

  详细信息:

  执行安全评估可以告知项目成员和下游消费者，项目了解软件中可能出现的问题。了解可能实现的威胁有助于项目管理和应对风险。此信息对下游消费者很有用，可以证明项目的安全敏锐度和实践。确保为新功能或重大更改更新此文档。

• 处于活跃状态时，项目文档必须包括协调漏洞披露（CVD）的政策，并有明确的响应时间框架。 {N/A理由} {满足URL} ^{[osps_vm_01_01]}

  详细信息:

  在目录根目录创建一个SECURITY.md文件，概述项目的协调漏洞披露政策。包括报告漏洞的方法。设定项目将如何响应和处理报告问题的期望。

• 处于活跃状态时，项目文档必须提供一种方法，用于直接向项目内的安全联系人私下报告漏洞。 {N/A理由} {满足URL} ^{[osps_vm_03_01]}

  详细信息:

  为安全研究人员提供一种方式，以私下向项目报告漏洞。这可能是专用电子邮件地址、Web表单、VCS专用工具、安全联系人的电子邮件地址或其他方法。

• 处于活跃状态时，项目文档必须公开发布有关已发现漏洞的数据。 {N/A理由} {满足URL} ^{[osps_vm_04_01]}

  详细信息:

  在可预测的公共渠道（例如CVE条目、博客文章或其他媒体）中提供有关已知漏洞的信息。在可能的情况下，此信息应包括受影响的版本、消费者如何确定他们是否容易受到攻击以及缓解或修复的说明。

基准等级3

通用

控制

• 当在CI/CD管道中为作业分配权限时，源代码或配置必须仅分配相应活动所需的最低权限。 {N/A理由} {满足URL} ^{[osps_ac_04_02]}

  详细信息:

  配置项目的CI/CD流水线，默认为用户和服务分配最低可用权限，仅在特定任务需要时才提升权限。在某些版本控制系统中，这可以在组织或代码仓库级别实现。如果不行，请在流水线的顶层设置权限。

• 当创建正式发布版本时，该发布版本中的所有资产必须明确关联到发布标识符或资产的其他唯一标识符。 {N/A理由} {满足URL} ^{[osps_br_02_02]}

  详细信息:

  为项目生成的每个软件资产分配唯一的版本标识符，遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交ID。

• 项目必须定义管理项目使用的秘密和凭证的策略。该策略应包括存储、访问和轮换秘密和凭证的指南。 {N/A理由} {满足URL} ^{[osps_br_07_02]}

  详细信息:

  记录项目内如何管理和使用秘密和凭证。这应包括如何存储秘密（例如，使用秘密管理工具）、如何控制访问以及如何轮换或更新秘密的详细信息。确保敏感信息不会硬编码在源代码中或存储在版本控制系统中。

• 当项目已发布版本时，项目文档必须包含验证发布资产完整性和真实性的说明。 {N/A理由} {满足URL} ^{[osps_do_03_01]}

  详细信息:

  项目中的说明应包含所使用技术、要运行的命令以及预期输出的信息。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

• 当项目已发布版本时，项目文档必须包含验证软件发布作者的预期身份的说明。 {N/A理由} {满足URL} ^{[osps_do_03_02]}

  详细信息:

  预期身份可能采用用于签名的密钥ID、来自sigstore证书的颁发者和身份或其他类似形式。如果可能，避免将此文档存储在构建和发布流水线的相同位置，以避免单一漏洞同时危及软件和验证软件完整性的文档。

• 当项目已发布版本时，项目文档必须包含关于每个发布版本支持范围和持续时间的描述性声明。 {N/A理由} {满足URL} ^{[osps_do_04_01]}

  详细信息:

  为了传达项目发布的软件资产的支持范围和持续时间，项目应有SUPPORT.md文件、SECURITY.md中的"支持"部分或其他文档，说明支持生命周期，包括每个发布版本的预期支持持续时间、提供的支持类型（例如，错误修复、安全更新）以及获取支持的任何相关策略或程序。

• 当项目已发布版本时，项目文档必须提供描述性声明说明何时发布版本或版本将不再接收安全更新。 {N/A理由} {满足URL} ^{[osps_do_05_01]}

  详细信息:

  为了传达安全修复的支持范围和持续时间，项目应有SUPPORT.md或其他文档，说明项目的安全更新策略。

• 在活跃期间，项目文档必须有一个策略，要求在授予对敏感资源的提升权限之前审查代码协作者。 {N/A理由} {满足URL} ^{[osps_gv_04_01]}

  详细信息:

  在项目文档中发布可执行的策略，要求在授予对敏感资源（例如合并批准或访问秘密）的提升权限之前审查和批准代码协作者。建议审查包括建立可证明的身份血统，例如确认贡献者与已知可信组织的关联。

• 当项目已发布版本时，所有编译的已发布软件资产必须附带软件物料清单。 {N/A理由} {满足URL} ^{[osps_qa_02_02]}

  详细信息:

  建议在构建时使用经过准确性审查的工具自动生成SBOM。这使用户能够以标准化的方式将此数据与其环境中的其他项目一起提取。

• 当项目已发布包含多个源代码仓库的版本时，所有子项目必须执行与主代码库一样严格或更严格的安全要求。 {N/A理由} {满足URL} ^{[osps_qa_04_02]}

  详细信息:

  项目生成并编译到发布版本中的任何其他子项目代码仓库必须根据相应代码库的状态和意图执行安全要求。除了遵循相应的OSPS基线要求外，这还可能包括要求进行安全审查、确保其没有漏洞以及确保其没有已知的安全问题。

• 在活跃期间，项目文档必须清楚地记录测试何时以及如何运行。 {N/A理由} {满足URL} ^{[osps_qa_06_02]}

  详细信息:

  在贡献文档中添加一个章节，说明如何在本地运行测试以及如何在CI/CD管道中运行测试。文档应说明测试的测试内容以及如何解释测试结果。

• 在活跃期间，项目的文档必须包含一项政策，即对项目生成的软件的所有重大更改都应该在自动化测试套件中添加或更新功能测试。 {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]}

  详细信息:

  建立VEX供给源，传达已知漏洞的可利用性状态，包括评估细节或任何阻止易受攻击代码执行的缓解措施。

• 在活跃期间，项目文档必须包含一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。 {N/A理由} {满足URL} ^{[osps_vm_05_01]}

  详细信息:

  在项目中记录一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

• 在活跃期间，项目文档必须包含一项政策，在任何发布之前解决SCA违规问题。 {N/A理由} {满足URL} ^{[osps_vm_05_02]}

  详细信息:

  在项目中记录一项政策，在任何发布之前解决适用的软件组成分析结果，并添加状态检查以验证在发布之前符合该政策。

• 在活跃期间，对项目代码库的所有更改必须根据记录的恶意依赖项和依赖项中已知漏洞的政策自动评估，然后在违规的情况下阻止，除非声明并抑制为不可利用。 {N/A理由} {满足URL} ^{[osps_vm_05_03]}

  详细信息:

  在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行软件组成分析工具。要求状态检查在更改可以合并之前必须通过。

• 在活跃期间，项目文档必须包含一项政策，定义SAST发现的修复阈值。 {N/A理由} {满足URL} ^{[osps_vm_06_01]}

  详细信息:

  在项目中记录一项政策，定义静态应用程序安全测试（SAST）发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

• 在活跃期间，对项目代码库的所有更改必须根据记录的安全弱点政策自动评估，并在违规的情况下阻止，除非声明并抑制为不可利用。 {N/A理由} {满足URL} ^{[osps_vm_06_02]}

  详细信息:

  在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行静态应用程序安全测试（SAST）工具。要求状态检查在更改可以合并之前必须通过。