release-lab

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目14067的徽章级别为passing 这里是如何嵌入它：
您可以通过将其嵌入在您的Markdown文件中：
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14067/badge)](https://www.bestpractices.dev/projects/14067)
或将其嵌入到HTML中来显示您的徽章状态：
<a href="https://www.bestpractices.dev/projects/14067"><img src="https://www.bestpractices.dev/projects/14067/badge"></a>


这些是黄金级别条款。您还可以查看通过或白银级别条款。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本 2/5 ●

  • 常规

    请注意，其他项目可能使用相同的名称。

    The org's release lab: risky release machinery proven here — real GitHub APIs, real credentials, real rulesets, real registries — before any production repository runs it. Fixture crates, no crates.io uploads.

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

  • 先决条件


    不足以获得徽章。

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

  • 项目监督


    不足以获得徽章。

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

    The bus factor is 1 — a single maintainer. Recorded plainly in docs/slsa-reference.md as headcount-blocked, with docs/continuity.md carrying the succession and break-glass paths that exist precisely because of it. https://github.com/monumental-archive/.github/blob/main/docs/continuity.md


    不足以获得徽章。

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

    There is one significant contributor, so there cannot be two unassociated ones. Headcount, not policy: contributions are welcomed under CONTRIBUTING.md. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md


  • 其他


    足够获得徽章！

    项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现： SPDX-License-Identifier: [SPDX license expression for project]。 [license_per_file]
    这可以通过在自然语言中包含许可证标识来完成。该项目还可以包括完整许可证文本，或者指向许可证文本的稳定URL。请注意，license_location条款要求项目许可证在标准位置。有关SPDX许可证表达式的更多信息，请参阅SPDX教程。请注意与 copyright_per_file 的关系，其内容通常在许可证信息之前。

    Every file carries an SPDX licence statement (0BSD) through REUSE.toml, with the full text in LICENSES/0BSD.txt. reuse lint reports 180 of 180 files with licence information. https://github.com/monumental-archive/release-lab/blob/main/REUSE.toml


 变更控制 3/4 ●

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


    足够获得徽章！

    必须使用通用的分布式版本控制软件（例如，git，mercurial）作为项目的源代码存储库。 [repo_distributed]
    Git不是必须，项目在合适场景可以使用集中版本控制软件（如subversion）。

    Repository on GitHub, which uses git. git is distributed.


    不足以获得徽章。

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

    The organisation's labels exist ('good first issue', 'help wanted') but no issue in this repository currently carries either, so small tasks are not identified for a newcomer.


    足够获得徽章！

    项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。 [require_2FA]

    Two-factor authentication is required organisation-wide — GitHub reports two_factor_requirement_enabled for the monumental-archive organisation — so it covers pushing to the repository and access to private vulnerability reports alike.


    足够获得徽章！

    项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 [secure_2FA]
    满足此条款的2FA机制将是一种基于时间的一次性密码（TOTP）应用程序，可自动生成在一段时间后更改的验证码。请注意， GitHub支持TOTP 。

    The 2FA in use is cryptographic rather than SMS-based: GitHub's supported second factors here are TOTP and WebAuthn, and the organisation's requirement is satisfied without SMS.


 质量 4/7 ●

  • 编码标准


    足够获得徽章！

    该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 (需要网址) [code_review_standards]
    另请参阅 two_person_review 和contribution_requirements 条款。

    GOVERNANCE.md's 'Code review' section states how review is conducted, what a reviewer checks (that the change does what it says, that its claim is one its checks enforce, that it weakens no documented control, that documentation moved with behaviour), what makes a change acceptable, and that the mechanical floor is the gate's job rather than the reviewer's. It also records plainly that with one maintainer there is no second human reviewer. https://github.com/monumental-archive/.github/blob/main/GOVERNANCE.md


    不足以获得徽章。

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

    With a single maintainer, no proposed modification is reviewed by a person other than its author. This is the Source L4 and Gold boundary for this project and is recorded as headcount-blocked in docs/slsa-reference.md; it is watched as an issue rather than papered over. https://github.com/monumental-archive/.github/blob/main/docs/slsa-reference.md


  • 可工作的构建系统


    足够获得徽章！

    该项目必须具有可重复构建。如果没有发生构建（例如，直接使用源代码而不是编译的脚本语言），请选择“不适用”（N/A）。 (需要网址) [build_reproducible]
    可重复的构建意味着多方可以独立地重做从源文件生成信息的过程，并获得每比特完全相同的结果。在某些情况下，这可以通过强制某种排序来解决。 JavaScript开发人员可能会考虑使用npm shrinkwrap和webpack的OccurenceOrderPlugin。 GCC和clang用户可能会发现-frandom-seed选项有用。通常可以通过指定可用于重新构建的特定容器或虚拟机的加密散列来为外部方定义构建环境（包括工具集）。 可重复构建项目具有文档指导如何执行此操作。

    Reproducible and independently re-verified: beyond the per-release repro gate, audit-repro.yml rebuilds the latest published release from cold on a weekly schedule and compares the result against the published digests. This repository is where that check first caught real image nondeterminism. https://github.com/monumental-archive/release-lab/blob/main/.github/workflows/audit-repro.yml


  • 自动测试套件


    足够获得徽章！

    测试套件必须以该语言的标准方式进行调用。 (需要网址) [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

    mise run ci — one command, identical locally and in CI. https://github.com/monumental-archive/release-lab/blob/main/README.md


    足够获得徽章！

    该项目必须实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 (需要网址) [test_continuous_integration]
    在大多数情况下，这意味着每个在项目上全职工作的开发人员至少每天都会整合。

    gate.yml runs the full gate on every push and pull request to main, calling the organisation's shared reusable workflow across a repository boundary. https://github.com/monumental-archive/release-lab/blob/main/.github/workflows/gate.yml


    不足以获得徽章。

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少90％语句覆盖率。 [test_statement_coverage90]

    Statement coverage is measured (cargo-llvm-cov, ratcheted against the committed floor) and stands at 87.10% lines over the crates tested on the gate runner — short of 90, and honestly so.


    不足以获得徽章。

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％分支覆盖率。 [test_branch_coverage80]

    Branch coverage is not measured: cargo-llvm-cov reports region coverage (86.57%) rather than branch coverage on the pinned stable toolchain, and a region is not a branch. Claiming the criterion from a proxy would be a guess dressed as a number.


 安全 5/5 ●

  • 使用基础的良好加密实践

    请注意，某些软件不需要使用加密机制。

    足够获得徽章！

    项目生成的软件必须支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本以及SSHv1等不安全协议必须被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。 [crypto_used_network]

    All network communication is HTTPS — GitHub APIs, tool downloads, registry publishing, transparency-log submission. No insecure protocol appears anywhere in the tree, and certificate verification is never disabled.


    足够获得徽章！

    由项目生成的软件必须，如果支持或使用TLS，至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_tls12]

    The software does not implement or configure TLS; it invokes tools (cargo, git, gh, curl) whose TLS versions are theirs.


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


    足够获得徽章！

    项目网站，存储库（如果可通过网络访问）和下载站点（如果单独）必须包括具有非允许值的密钥加固头。 (需要网址) [hardened_site]
    请注意，GitHub是已知满足的。 https://securityheaders.io/ 等网站可以快速查看。主要头加固包含：内容安全策略（CSP），HTTP严格传输安全性（HSTS），X-Content-Type-Options（“nosniff”），X-Frame-Options和X-XSS-Protection。

    The project site is this GitHub repository, served with the hardening headers GitHub sets: strict-transport-security with a one-year max-age and includeSubdomains, content-security-policy, x-frame-options: deny and x-content-type-options: nosniff. There is no separate project website; the published packages are served by npm and GHCR over the same guarantees. https://github.com/monumental-archive/release-lab


  • 其他安全问题


    足够获得徽章！

    该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。 [security_review]
    这可以由项目成员完成和/或独立评估。此评估可能由静态和动态分析工具支持，但还必须进行人工审查，以确定工具无法检测到的问题（特别是设计问题）。

    The governance repository's docs/build-assessment.md and docs/source-assessment.md are security reviews of exactly the machinery this repository runs, control by control, and they are current rather than historical — the scheduled audit re-checks them. This repository is the place those controls are exercised before any production repository. https://github.com/monumental-archive/.github/blob/main/docs/build-assessment.md


    足够获得徽章！

    加固机制必须用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 (需要网址) [hardening]
    加固机制可能包括HTTP头，如内容安全策略（CSP），用于减轻攻击的编译器标志（如-fstack-protector）或用以消除未定义行为的编译器标志。对于此条款的目的，最小权限不被认为是一种加固机制（最少权限是重要的，但是另有条款）。

    Least-privilege permissions on every workflow; every uses: pinned to a full commit SHA; the toolchain pinned with per-platform checksums in mise.lock and Cargo dependencies locked; keyless publishing with no standing credentials; secret scanning with push protection enforced organisation-wide; releases immutable once published. Each mechanism is written up control by control, against the threat it answers, in docs/build-assessment.md. https://github.com/monumental-archive/.github/blob/main/docs/build-assessment.md


 分析 2/2 ●

  • 动态代码分析


    足够获得徽章！

    必须在发布之前，至少将一个动态分析工具应用于软件任何候选发布的主要生产版本。 [dynamic_analysis]
    动态分析工具通过执行特定输入来检查软件。例如，项目可以使用模糊工具（例如， American Fuzzy Lop ）或Web应用扫描程序（例如， ZAP 或 w3af ）。在某些情况下， OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款，动态分析工具需要以某种方式改变输入，以寻找各种问题，或者将其作为一个具有至少80％分支覆盖率的自动测试套件。 动态分析维基百科页面和 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞，但这不是必需的。

    Fuzzing runs, and it satisfies this criterion's own definition of a tool that varies its inputs: cargo-fuzz drives libFuzzer against the parse_marker target with a committed in-tree corpus. The deterministic half (lint:fuzz-build) is in the gate on every pull request so a target that stops compiling fails the build; the time-bound half (audit:fuzz) runs the targets on the scheduled audit and fails with a reproducer path on any crash or panic. https://github.com/monumental-archive/release-lab/tree/main/fuzz


    足够获得徽章！

    项目应该在其生成的软件中包含许多运行时断言，并在动态分析期间检查这些断言。 [dynamic_analysis_enable_assertions]
    这个标准并不建议使生产过程中的断言;这完全取决于项目及其用户的决定。该标准的重点是在部署之前的动态分析过程中改善故障检测。在生产使用中启用断言与在动态分析（例如测试）期间启用断言完全不同。在某些情况下，在生产中使用断言是极其不明智的（尤其是在高完整性组件中）。存在许多反对在生产环境中启用断言的论点，例如，库不应使调用程序崩溃，它们的存在可能会导致应用商店拒绝，和/或在生产环境中激活断言可能会暴露诸如私钥之类的私有数据。请注意，在许多Linux发行版中都未定义NDEBUG ，因此C / C ++缺省情况下，assert（）将在这些环境中启用生产。对于那些环境中的生产，使用不同的断言机制或定义NDEBUG可能很重要。

    The fuzz and test builds are debug builds: debug_assertions and integer overflow checks are on, so assertion failures and overflows abort rather than pass silently.



该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Carl Allen和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Carl Allen.
最后更新于 2026-08-13 18:20:14 UTC, 最后更新于 2026-08-13 19:50:32 UTC。 最后在 2026-08-13 18:28:09 UTC 获得通过徽章。