clusdr

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

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

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


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

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

        

 基本

  • 常规

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

    Distributed coordination runtime in Go. Apps talk to a local daemon (and language SDKs) for membership, presence, locks, leases, and events—not a database, queue, or Kubernetes. TLS is on by default.

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

 控制 18/19 ●

  • 控制


    足够获得徽章！

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

    GitHub Actions for this repository defaults new workflow permissions to read (lowest privilege); jobs request additional permissions only when needed.
    https://github.com/clusdr/clusdr
    https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository


    足够获得徽章！

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

    Official releases use unique SemVer git tags (vX.Y.Z and vX.Y.Z-rc.N).
    https://github.com/clusdr/clusdr/releases
    https://github.com/clusdr/clusdr/blob/main/CONTRIBUTING.md#releases


    足够获得徽章！

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

    Each release includes a human-readable summary of changes (GitHub Release notes and the project changelog), not raw git log.
    https://clusdr.io/docs/reference/changelog
    https://github.com/clusdr/clusdr/releases


    足够获得徽章！

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

    Build and release ingest Go dependencies through the standard Go modules toolchain (go.mod / go.sum).
    https://github.com/clusdr/clusdr/blob/main/go.mod
    https://github.com/clusdr/clusdr/blob/main/sdk/go.mod


    不足以获得徽章。

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

    Published releases provide checksums.txt over HTTPS, but no cosign/Sigstore/GPG signatures or signed SBOM/provenance artifacts exist on a Release.
    https://github.com/clusdr/clusdr/releases
    https://github.com/clusdr/clusdr/blob/main/.github/workflows/release.yml


    足够获得徽章！

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

    Dependencies are selected and tracked as Go modules from the public module proxy in go.mod/go.sum with no vendor tree; Dependabot opens weekly update PRs. CONTRIBUTING documents dependency management.
    https://github.com/clusdr/clusdr/blob/main/CONTRIBUTING.md
    https://github.com/clusdr/clusdr/blob/main/go.mod
    https://github.com/clusdr/clusdr/blob/main/.github/dependabot.yml


    足够获得徽章！

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

    CONTRIBUTING.md documents how to build from source, including Go/Buf requirements and make targets.
    https://github.com/clusdr/clusdr/blob/main/CONTRIBUTING.md


    足够获得徽章！

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

    .github/CODEOWNERS lists @durguto as the owner with access over the repository tree.
    https://github.com/clusdr/clusdr/blob/main/.github/CODEOWNERS


    足够获得徽章！

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

    GOVERNANCE.md and MAINTAINERS.md document roles and responsibilities for the project lead, maintainers, and contributors.
    https://github.com/clusdr/clusdr/blob/main/GOVERNANCE.md
    https://github.com/clusdr/clusdr/blob/main/MAINTAINERS.md


    足够获得徽章！

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

    CONTRIBUTING.md and the PR template state requirements for acceptable contributions (commits, tests, docs, proto rules).
    https://github.com/clusdr/clusdr/blob/main/CONTRIBUTING.md
    https://github.com/clusdr/clusdr/blob/main/.github/PULL_REQUEST_TEMPLATE.md


    足够获得徽章！

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

    Public contributions on GitHub are covered by GitHub’s Terms of Service grant of rights; the project is Apache-2.0. A separate DCO bot is not required for this control when the VCS ToS applies.
    https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
    https://github.com/clusdr/clusdr/blob/main/LICENSE


    足够获得徽章！

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

    The active main ruleset requires listed status checks to pass before merge (Lint, Test, Coverage, Helm, Buf, Conventional Commits).
    https://github.com/clusdr/clusdr/rules/23659426


    足够获得徽章！

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

    Before merge, CI runs an automated test suite (go test -race via the Test job / make test).
    https://github.com/clusdr/clusdr/actions/workflows/ci.yml
    https://github.com/clusdr/clusdr/blob/main/Makefile


    足够获得徽章！

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

    Architecture docs describe system actors and actions (applications, local daemon, Raft peers, CLI).
    https://github.com/clusdr/clusdr/blob/main/docs/architecture.md
    https://clusdr.io/docs/architecture


    足够获得徽章！

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

    External interfaces (gRPC API and CLI) are documented for released software.
    https://clusdr.io/docs/reference/api/
    https://clusdr.io/docs/reference/cli/


    足够获得徽章！

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

    docs/concepts/security.md publishes a trust-boundary table and threat discussion covering join tokens, impersonation, disk exposure, and TLS disabled.
    https://github.com/clusdr/clusdr/blob/main/docs/concepts/security.md
    https://clusdr.io/docs/concepts/security


    足够获得徽章！

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

    SECURITY.md defines CVD response times: acknowledge within 5 days; within 14 days of a reproducible report provide a fix path, ship a patch on the current release train, or explain why it is not a vulnerability.
    https://github.com/clusdr/clusdr/blob/main/SECURITY.md


    足够获得徽章！

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

    SECURITY.md provides GitHub private vulnerability reporting to project security contacts.
    https://github.com/clusdr/clusdr/blob/main/SECURITY.md
    https://github.com/clusdr/clusdr/security/advisories/new


    足够获得徽章！

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

    Confirmed vulnerabilities are published via GitHub Security Advisories (and CVE when assigned); none have been published to date.
    https://github.com/clusdr/clusdr/security/advisories
    https://github.com/clusdr/clusdr/blob/main/SECURITY.md



您可以使用工具和AI系统通过简单的URL提交变更建议，例如 https://www.bestpractices.dev/zh-CN/projects/14654/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统，了解具体操作方法。 该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Oğuzhan Durgut和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Oğuzhan Durgut.
最后更新于 2026-09-15 12:07:18 UTC, 最后更新于 2026-09-18 16:26:03 UTC。 最后在 2026-09-18 13:24:27 UTC 获得通过徽章。