arrapi

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

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

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


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

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

        

 基本

  • 常规

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

    Typed, resilient Go clients for the Sonarr and Radarr v3 APIs (retry, backoff, read coalescing, size-bounded).

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

 控制 24/24 ●

  • 控制


    足够获得徽章！

    当用户尝试读取或修改项目权威存储库中的敏感资源时，系统必须要求用户完成多因素认证过程。 [OSPS-AC-01.01]
    为项目的版本控制系统强制执行多因素认证，要求协作者在访问敏感数据或修改存储库设置时提供第二种形式的认证。通行密钥对于此控制是可接受的。

    The GitHub account enforces multi-factor authentication for access to the repositories.


    足够获得徽章！

    当添加新的协作者时，版本控制系统必须要求手动分配权限，或默认将协作者权限限制为可用的最低权限。 [OSPS-AC-02.01]
    大多数公共版本控制系统都是这样配置的。确保项目的版本控制系统在添加协作者时始终默认分配最低可用权限,仅在必要时授予额外权限。

    GitHub requires explicit per-collaborator invitation with an assigned role; there is no default write access.


    足够获得徽章！

    当尝试直接提交到项目的主分支时,强制机制必须阻止该更改的应用。 [OSPS-AC-03.01]
    如果VCS是集中式的,请在项目的VCS中对主分支设置分支保护。或者,使用去中心化方法,如Linux内核的方法,即先在另一个仓库中提出更改,将更改合并到主仓库需要特定的单独操作。

    Branch protection on main with required ci / validate status check blocks direct commits by collaborators (the sole maintainer/admin is documented as exempt).


    足够获得徽章！

    当尝试删除项目的主分支时,版本控制系统必须将此视为敏感活动,并要求明确确认意图。 [OSPS-AC-03.02]
    在项目的版本控制系统中对主分支设置分支保护以防止删除。

    Branch protection blocks deletion of the primary branch (allow_deletions=false).


    足够获得徽章！

    当CI/CD管道接受输入参数时,该参数必须在管道中使用之前进行清理和验证。 [OSPS-BR-01.01]
    CI/CD 流水线应对所有来自不可信来源的元数据输入进行清理（引用、转义或在期望值时退出）。这包括分支名称、提交消息、标签、拉取请求标题和作者信息等数据。

    OpenSSF Scorecard Dangerous-Workflow check passes (10/10); workflows pass inputs via env vars and pin all actions by SHA.


    足够获得徽章！

    当 CI/CD 流水线对不可信代码快照进行操作时，它必须阻止访问特权 CI/CD 凭据和资产。 [OSPS-BR-01.03]
    CI/CD 流水线应将不可信代码快照与特权凭据和资产隔离。特别是，项目应谨慎确保在协作者审查之前构建或执行代码的工作流无法访问 CI/CD 凭据。

    Untrusted code runs only in least-privileged CI; no pull_request_target with checkout of untrusted code. Scorecard Dangerous-Workflow = 10/10.


    足够获得徽章！

    当项目将URI列为官方项目渠道时,该URI必须仅通过加密渠道交付。 [OSPS-BR-03.01]
    配置项目的网站和版本控制系统使用SSH或HTTPS等加密渠道进行数据传输。确保项目文档中引用的所有工具和域名只能通过加密渠道访问。

    All official project channels (repo, homepage) are served exclusively over HTTPS/SSH.


    足够获得徽章！

    当项目将URI列为官方分发渠道时,该URI必须仅通过加密渠道交付。 [OSPS-BR-03.02]
    配置项目的发布管道,仅从使用SSH或HTTPS等加密渠道进行数据传输的网站、API响应和其他服务获取数据。

    Distribution is via the Go module proxy over TLS, with go.sum content-integrity verification.


    足够获得徽章！

    项目必须防止在版本控制系统中意外存储未加密的敏感数据,例如机密和凭据。 [OSPS-BR-07.01]
    配置.gitignore或等效文件以排除可能包含敏感信息的文件。使用预提交钩子和自动扫描工具来检测和防止在提交中包含敏感数据。

    gitleaks runs in CI with push protection; .gitignore excludes secret/.env.dec files; secrets are age-encrypted at rest.


    足够获得徽章！

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

    The README documents installation, configuration, and basic usage.


    足够获得徽章！

    当项目发布版本后,项目文档必须包含缺陷报告指南。 [OSPS-DO-02.01]
    建议项目使用其VCS默认问题跟踪器。如果使用外部来源,请确保项目文档和贡献指南清晰且明显地解释如何使用报告系统。建议项目文档还设定缺陷将如何分类和解决的期望。

    Defect reporting is via GitHub Issues with provided issue templates.


    足够获得徽章！

    在活跃期间,项目必须有一个或多个机制用于公开讨论提议的更改和使用障碍。 [OSPS-GV-02.01]
    在项目中建立一个或多个公开讨论机制,例如邮件列表、即时消息或问题跟踪器,以促进开放的沟通和反馈。

    Public discussion occurs via GitHub Issues (and Discussions where enabled).


    足够获得徽章！

    在活跃期间,项目文档必须包含贡献流程的说明。 [OSPS-GV-03.01]
    创建一个CONTRIBUTING.md或CONTRIBUTING/目录来概述贡献流程，包括提交更改的步骤以及与项目维护者互动的方式。

    The contribution process is documented in CONTRIBUTING (own or the org-wide cplieger/.github default).


    足够获得徽章！

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

    Licensed GPL-3.0-or-later, an OSI-approved / FSF free-software license.


    足够获得徽章！

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

    Released assets carry the same OSI-approved GPL-3.0-or-later license.


    足够获得徽章！

    活跃期间，源代码的许可证必须保存在相应仓库的LICENSE文件、COPYING文件或LICENSE/目录中。 [OSPS-LE-03.01]
    将项目的源代码许可证包含在项目的LICENSE文件、COPYING文件或LICENSE/目录中，以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库，请确保每个仓库都包含许可证文件。

    The license is in the repository LICENSE file.


    足够获得徽章！

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

    The license ships alongside the released assets / source.


    足够获得徽章！

    活跃期间，项目的源代码仓库必须在静态URL上可公开读取。 [OSPS-QA-01.01]
    使用常见的版本控制系统（VCS），如GitHub、GitLab或Bitbucket。确保仓库可公开读取。避免重复或镜像仓库，除非有高度可见的文档说明主要来源。避免频繁更改会影响仓库URL的仓库。确保仓库是公开的。

    The repository is publicly readable at a stable GitHub URL.


    足够获得徽章！

    版本控制系统必须包含所有更改的可公开读取的记录，包括谁进行了更改以及更改的时间。 [OSPS-QA-01.02]
    使用常见的版本控制系统（VCS），如GitHub、GitLab或Bitbucket来维护可公开读取的提交历史记录。避免压缩或重写提交，以免掩盖任何提交的作者。

    GitHub retains a public, attributable commit history of all changes.


    足够获得徽章！

    当包管理系统支持时，源代码仓库必须包含一个依赖项列表，该列表涵盖直接的语言依赖项。 [OSPS-QA-02.01]
    这可以采用包管理器或语言依赖文件的形式，列举所有直接依赖项，如package.json、Gemfile或go.mod。

    Direct dependencies are enumerated in the language manifest (go.mod / package.json / jsr.json).


    足够获得徽章！

    活跃期间，项目文档必须包含被视为子项目的任何代码库的列表。 [OSPS-QA-04.01]
    记录由项目生成并编译到发布版本中的任何附加子项目代码仓库。此文档应包括相应代码库的状态和意图。

    Single-repository project; there are no additional constituent code repositories to list.


    足够获得徽章！

    活跃期间，版本控制系统中不得包含生成的可执行工件。 [OSPS-QA-05.01]
    删除项目版本控制系统中生成的可执行工件。建议在任何情况下，如果生成的可执行工件对测试等过程至关重要，应该在构建时生成，或单独存储并在特定的、有详细文档记录的管道步骤中获取。

    No generated executable artifacts are committed to version control (source-only repo).


    足够获得徽章！

    活跃期间，版本控制系统中不得包含无法审查的二进制工件。 [OSPS-QA-05.02]
    不要将任何无法审查的二进制工件添加到项目的版本控制系统中。这包括可执行应用程序二进制文件、库文件和类似的工件。这不包括资产，如图形图像、声音或音乐文件以及通常以二进制格式存储的类似内容。

    No unreviewable binary artifacts are committed; fixtures are text/reviewable.


    足够获得徽章！

    在活动期间，项目文档必须包含安全联系人。 [OSPS-VM-02.01]
    创建一个security.md（或类似名称）文件，其中包含项目的安全联系人。

    SECURITY.md documents the security contact / private reporting channel.



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

项目徽章条目拥有者： Christopher Plieger.
最后更新于 2026-07-08 23:16:05 UTC, 最后更新于 2026-07-08 23:18:33 UTC。 最后在 2026-07-08 23:17:16 UTC 获得通过徽章。