release-lab

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

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

如果这是您的项目,请在项目页面上显示您的基准徽章状态!基准徽章状态如下所示: 项目14067的基准徽章等级为baseline-2 以下是如何嵌入基准徽章:
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/14067/baseline)](https://www.bestpractices.dev/projects/14067)
或者将其嵌入到HTML中:
<a href="https://www.bestpractices.dev/projects/14067"><img src="https://www.bestpractices.dev/projects/14067/baseline"></a>


这些是基准等级2的标准。 这些是标准版本 v2026.02.19。

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

        

 基本

  • 常规

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

    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)是用于信息技术系统,软件和软件包的结构化命名方案。在报告漏洞时,它可用于多个系统和数据库。

 控制 19/19

  • 控制


    当执行CI/CD任务且未指定权限时,CI/CD系统必须将任务的权限默认为管道中授予的最低权限。 [OSPS-AC-04.01]
    配置项目的设置,默认情况下为新管道分配最低可用权限,仅在特定任务需要时才授予额外权限。

    Least privilege is the default and the explicit setting: the repository baseline sets the workflow token to read-only permissions, and every workflow declares its own minimal permissions: block on top of that. A job that specifies nothing therefore gets read, not write. https://github.com/monumental-archive/.github/tree/main/settings



    当创建正式发布时,该发布必须分配一个唯一的版本标识符。 [OSPS-BR-02.01]
    为项目生成的每个发布分配一个唯一的版本标识符,遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交id。

    Every release is a unique semantic version, derived from conventional commits by git-cliff and tagged v<major>.<minor>.<patch> by the release App; the tag ruleset makes tags immutable, so a version identifier is never reused.



    当创建正式发布时,该发布必须包含功能和安全修改的描述性日志。 [OSPS-BR-04.01]
    确保所有发布都包含描述性的变更日志。建议确保变更日志是人类可读的,并且包含超出提交消息的详细信息,例如安全影响的描述或与不同用例的相关性。为确保机器可读性,请将内容放在markdown标题下,例如"## Changelog"。

    CHANGELOG.md is generated by git-cliff from conventional commits and the same descriptive log is attached to each GitHub release, so every functional and security modification is recorded per version. https://github.com/monumental-archive/release-lab/blob/main/CHANGELOG.md



    当构建和发布管道摄取依赖项时,它必须使用标准化工具(如果可用)。 [OSPS-BR-05.01]
    为您的生态系统使用通用工具,例如包管理器或依赖项管理工具,以在构建时摄取依赖项。这可能包括使用依赖项文件、锁文件或清单来指定所需的依赖项,然后由构建系统拉入。

    Dependency ingestion is standardised and locked: cargo with a committed Cargo.lock for crates, mise with a lockfile carrying per-platform checksums for tools, base images by digest, and cargo-deny restricting sources to a single registry with unknown-registry and unknown-git denied.



    当创建正式发布时,该发布必须进行签名或在包含每个资产加密哈希值的签名清单中进行说明。 [OSPS-BR-06.01]
    在构建时使用加密签名或证明(例如GPG或PGP签名、Sigstore签名、SLSA来源或SLSA VSA)对所有发布的软件资产进行签名。在签名清单或元数据文件中包含每个资产的加密哈希值。

    Each release carries Sigstore evidence bundles and GitHub artifact attestations covering every published asset by cryptographic digest — nine bundles on v0.24.4 — and the governance repository's runbook documents how a consumer verifies them. https://github.com/monumental-archive/.github/blob/main/docs/runbook.md#verifying-as-a-consumer-would



    当项目发布版本后,项目文档必须包含项目如何选择、获取和跟踪其依赖项的描述。 [OSPS-DO-06.01]
    建议在可公开查看的资源(如源代码存储库、项目网站或其他渠道)上与项目的技术和设计文档一起发布此信息。

    Documented in two places and deliberately so: docs/tooling-verdicts.md records how a dependency is selected — the priors a tool must meet to enter the belt, and the verdicts on tools considered and declined — and docs/dependency-track.md records how dependencies are obtained, pinned, monitored and triaged. https://github.com/monumental-archive/.github/blob/main/docs/tooling-verdicts.md



    项目文档必须包含如何构建软件的说明,包括所需的库、框架、SDK 和依赖项。 [OSPS-DO-07.01]
    建议将此信息与项目的贡献者文档一起发布,例如在 CONTRIBUTING.md 或其他开发者任务文档中。也可以使用 Makefile 目标或其他自动化脚本来记录此信息。

    README.md gives the whole sequence: mise trust && mise install brings every required tool at its pinned version from the lockfile, and mise run ci then runs exactly what CI runs. https://github.com/monumental-archive/release-lab/blob/main/README.md



    在活动期间,项目文档必须包含有权访问敏感资源的项目成员列表。 [OSPS-GV-01.01]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。这可以简单到在维护者列表中包含姓名或账户句柄,或者根据项目的治理更复杂。

    docs/continuity.md carries an asset table naming who holds each sensitive resource — organisation ownership, the tag-mint App key, registry accounts, the one standing token — and what happens to each if that person is unavailable. https://github.com/monumental-archive/.github/blob/main/docs/continuity.md



    在活动期间,项目文档必须包含项目成员的角色和责任的描述。 [OSPS-GV-01.02]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。

    GOVERNANCE.md carries a 'Roles and responsibilities' table naming three roles - maintainer/owner, contributor, automation - and the responsibilities of each, and it is served from the organisation's .github repository as a default community health file so it applies to every repository that does not carry its own. Who holds the maintainer role is explicit: the @monumental-archive/owners team, which CODEOWNERS routes every review to. https://github.com/monumental-archive/.github/blob/main/GOVERNANCE.md#roles-and-responsibilities



    在活动期间,项目文档必须包含代码贡献者指南,其中包括可接受贡献的要求。 [OSPS-GV-03.02]
    扩展项目文档中的CONTRIBUTING.md或CONTRIBUTING/的内容,以概述可接受的贡献要求,包括编码标准、测试要求和代码贡献者的提交指南。建议将该指南作为贡献者和批准者的真实来源。

    CONTRIBUTING.md includes a 'Requirements for acceptable contributions' section: pull request only, a green mise run ci, Conventional Commits with imperative lowercase subjects under 72 columns, DCO sign-off, squash merge. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md



    处于活跃状态时,版本控制系统必须要求所有代码贡献者在每次提交时断言他们有合法授权提交相关的贡献。 [OSPS-LE-01.01]
    在项目的代码库中包含一个DCO,要求代码贡献者在每次提交时断言他们有合法授权提交相关贡献。使用状态检查以确保完成此断言。CLA也满足此要求。某些版本控制系统(例如GitHub)可能会在平台服务条款中包含此项。

    Every commit must carry a Developer Certificate of Origin 1.1 sign-off asserting legal authorisation. The commit-msg hook catches a missing trailer locally and lint:dco fails the gate, with no exemption list — automation signs off too.



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

    gate.yml is a required status check on main under an organisation ruleset: direct pushes are blocked entirely and a pull request cannot merge red, so no commit reaches the default branch without the full gate — the lint belt, cargo test --workspace --locked and the coverage ratchet — having passed. https://github.com/monumental-archive/release-lab/blob/main/.github/workflows/gate.yml



    在接受提交之前,项目的CI/CD管道必须运行至少一个自动化测试套件,以确保更改符合预期。 [OSPS-QA-06.01]
    应在每次合并到主分支之前运行自动化测试。测试套件应在CI/CD管道中运行,结果应对所有贡献者可见。测试套件应在一致的环境中运行,并应以允许贡献者在本地运行测试的方式运行。测试套件的示例包括单元测试、集成测试和端到端测试。

    gate.yml runs the full automated suite — the shared lint belt, cargo test --workspace --locked and the coverage ratchet — on every pull request before it can be accepted. https://github.com/monumental-archive/release-lab/blob/main/.github/workflows/gate.yml



    当项目发布版本时,项目文档必须包括设计文档,展示系统中的所有操作和参与者。 [OSPS-SA-01.01]
    在项目文档中包括说明操作和参与者的设计。参与者包括可以影响系统中另一段的任何子系统或实体。确保为新功能或重大更改更新此文档。

    The pipeline this repository runs is specified actor by actor and action by action in the governance repository's docs/release.md, and this repository's README maps each of its own caller stubs — gate, release, publish, continuous, exercise-sign, source-attest, audit, audit-repro, scorecard — to what that stub proves. https://github.com/monumental-archive/release-lab/blob/main/README.md



    当项目发布版本时,项目文档必须包括对已发布软件资产的所有外部软件接口的描述。 [OSPS-SA-02.01]
    记录已发布软件资产的所有软件接口(API),解释用户如何与软件交互以及期望或产生什么数据。确保为新功能或重大更改更新此文档。

    The external interfaces are the caller stubs' inputs and the published packages. Each stub and its inputs are documented in README.md here and specified in the governance repository's docs/runbook.md; the published artefacts are the crate, the npm package, the images and the per-major extension packages, each named and described per release. https://github.com/monumental-archive/release-lab/blob/main/README.md



    当项目发布版本时,项目必须执行安全评估,以了解软件中可能发生的最可能和最具影响力的潜在安全问题。 [OSPS-SA-03.01]
    执行安全评估可以告知项目成员和下游消费者,项目了解软件中可能出现的问题。了解可能实现的威胁有助于项目管理和应对风险。此信息对下游消费者很有用,可以证明项目的安全敏锐度和实践。确保为新功能或重大更改更新此文档。

    docs/build-assessment.md and docs/source-assessment.md are written security assessments of this system: they walk the controls, name the most likely and impactful failure modes (untrusted caller code reaching a privileged signing identity, supply-chain substitution through unpinned dependencies, silent settings drift), and record which are mitigated and which are accepted. https://github.com/monumental-archive/.github/blob/main/docs/build-assessment.md



    处于活跃状态时,项目文档必须包括协调漏洞披露(CVD)的政策,并有明确的响应时间框架。 [OSPS-VM-01.01]
    在目录根目录创建一个SECURITY.md文件,概述项目的协调漏洞披露政策。包括报告漏洞的方法。设定项目将如何响应和处理报告问题的期望。

    SECURITY.md is the coordinated disclosure policy and it states the timeframe: private reporting through the repository's Security tab, acknowledgement within 14 days, and what the reporter can expect afterwards. https://github.com/monumental-archive/.github/blob/main/SECURITY.md



    处于活跃状态时,项目文档必须提供一种方法,用于直接向项目内的安全联系人私下报告漏洞。 [OSPS-VM-03.01]
    为安全研究人员提供一种方式,以私下向项目报告漏洞。这可能是专用电子邮件地址、Web表单、VCS专用工具、安全联系人的电子邮件地址或其他方法。

    GitHub private vulnerability reporting is enabled and is the documented channel in SECURITY.md, delivering the report directly to the security contact without public exposure. https://github.com/monumental-archive/.github/blob/main/SECURITY.md



    处于活跃状态时,项目文档必须公开发布有关已发现漏洞的数据。 [OSPS-VM-04.01]
    在可预测的公共渠道(例如CVE条目、博客文章或其他媒体)中提供有关已知漏洞的信息。在可能的情况下,此信息应包括受影响的版本、消费者如何确定他们是否容易受到攻击以及缓解或修复的说明。

    Vulnerability data for this repository is published rather than held privately: a resolved report would be published as a GitHub Security Advisory here, and dependency findings already ship publicly with every release as an OpenVEX document (release-lab-0.24.4.vex.openvex.json) recording each decision against the release's SBOM. https://github.com/monumental-archive/release-lab/releases/tag/v0.24.4



该数据可在社区数据许可协议 – 许可性,版本 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 获得通过徽章。