KofTwentyTwo Standards

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

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

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


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

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

        

 基本 13/13 ●

  • 常规

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

    Engineering policies and standards with reusable configuration, templates, GitHub Actions workflows, workstation setup scripts, and PowerShell enforcement tooling for building, securing, and releasing software.

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

    Assessment covers the published standards, configuration, templates, workflows, and executable enforcement/setup tooling. MIT applies to tooling/configs/templates; CC BY 4.0 to prose; Apache-2.0 to attributed Kingsrook material (NOTICE). Evidence reviewed on 2026-10-10 at main commit 11fe60b14697bda05e17f0dec532e55e8149d50d. Personal knowledge and private-response criteria rely on maintainer confirmation on 2026-10-10. https://github.com/KofTwentyTwo/standards/blob/main/README.md https://github.com/KofTwentyTwo/standards/blob/main/docs/security/best-practices.md

  • 基本项目网站内容


    足够获得徽章！

    项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 [description_good]
    必须采用潜在用户可以理解的语言（例如，它使用最少的术语/行话）。

    README describes the standards, their purpose, and the enforcement tooling. https://github.com/KofTwentyTwo/standards/blob/main/README.md


    足够获得徽章！

    项目网站必须提供有关如何获取和提供反馈（错误报告或增强功能）以及如何贡献的信息。 [interact]

    README explains obtaining/adopting the standards and links contribution and feedback channels. CONTRIBUTING uses public issues and pull requests. https://github.com/KofTwentyTwo/standards/blob/main/README.md https://github.com/KofTwentyTwo/standards/blob/main/CONTRIBUTING.md


    足够获得徽章！

    关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） (需要网址) [contribution]
    除非另有说明，否则我们假定 GitHub上的项目使用问题列表（Issues）和拉（Pull）请求。这些信息可以简短，例如，说明项目使用拉请求，问题跟踪器或邮寄到邮件列表中的哪一个。

    CONTRIBUTING explains forks, topic branches, signed/DCO commits, and pull requests to main. https://github.com/KofTwentyTwo/standards/blob/main/CONTRIBUTING.md


    足够获得徽章！

    关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [contribution_requirements]

    Contribution guidance specifies requirement IDs, levels, framework crosswalks, professional wording, and workflow/conformance gates; it links the SDLC policy. https://github.com/KofTwentyTwo/standards/blob/main/CONTRIBUTING.md


  • FLOSS许可证


    足够获得徽章！

    项目生产的软件必须作为FLOSS发布。 [floss_license]
    FLOSS是以符合开源定义或免费软件定义。此类许可证的示例包括 CC0 ， MIT ， BSD 2条款， BSD 3条款修订版， Apache 2.0 ， Lesser GNU通用公共许可证（LGPL），以及 GNU通用公共许可证（GPL）。为了我们的目的，这意味着许可证必须是：该软件也可以用其他许可证（例如，“GPLv2或专有”是可以接受的）。

    Scripts, workflows, configs and templates use MIT; attributed Kingsrook material uses Apache-2.0. Prose is separately licensed CC BY 4.0. https://github.com/KofTwentyTwo/standards/blob/main/LICENSE https://github.com/KofTwentyTwo/standards/blob/main/README.md https://github.com/KofTwentyTwo/standards/blob/main/NOTICE


    足够获得徽章！

    建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 [floss_license_osi]
    OSI （开放源代码促进会）使用严格的审批流程来确定哪些许可证是开源软件（OSS）。

    Software licenses are OSI-approved MIT and Apache-2.0. CC BY 4.0 covers documentation, not the software. https://github.com/KofTwentyTwo/standards/blob/main/LICENSE https://github.com/KofTwentyTwo/standards/blob/main/NOTICE https://github.com/KofTwentyTwo/standards/blob/main/README.md


    足够获得徽章！

    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]
    一种约定是将许可证发布为名为LICENSE或COPYING的顶级文件，其后可以带有扩展名，例如“ .txt”或“ .md”。另一种约定是使用一个名为LICENSES的目录，其中包含许可证文件。这些文件通常被命名为其SPDX许可证标识符，后跟适当的文件扩展名，如REUSE Specification中所述。请注意，此标准只是源存储库上的要求。从源代码生成某些内容（例如可执行文件，程序包或容器）时，无需包括许可证文件。例如，在为综合R存档网络（CRAN）生成R软件包时，请遵循标准CRAN惯例：如果许可证是标准许可证，请使用标准简短许可证规范（以避免安装另一文本副本）并列出排除文件（例如.Rbuildignore）中的LICENSE文件。同样，在创建Debian软件包时，您可以在版权文件中放置一个指向/ usr / share / common-licenses中的许可证文本的链接，并从创建的软件包中排除许可证文件（例如，通过在调用dh_auto_install之后删除文件） ）。我们鼓励在可行的情况下以生成的格式包含机器可读的许可证信息。

    Root LICENSE, LICENSE-docs, and NOTICE record the licenses and attribution. https://github.com/KofTwentyTwo/standards/blob/main/LICENSE https://github.com/KofTwentyTwo/standards/blob/main/LICENSE-docs https://github.com/KofTwentyTwo/standards/blob/main/NOTICE


  • 文档


    足够获得徽章！

    项目必须为项目生成的软件提供基本文档。 [documentation_basics]
    该文档必须在某些媒体（例如文本或视频）中，包括：如何安装它，如何启动它，如何使用它（可能使用教程使用示例）以及如何安全地使用它（例如，做什么和不做什么），如果这是软件的一个适当的话题。安全文档不需要太长篇幅。项目可以使用非项目内容的超文本链接作为文档。如果项目不生产软件，请选择“不适用”（N/A）。

    README documents installation, IDE configuration, adoption, workflow usage, checker invocation, and secure SHA pinning. https://github.com/KofTwentyTwo/standards/blob/main/README.md


    足够获得徽章！

    项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 [documentation_interface]
    外部接口的文档向最终用户或开发人员解释如何使用它。这将包括其应用程序接口（API），如果软件有。如果它是一个库，记录可以调用的主要类/类型和方法/函数。如果是Web应用程序，定义其URL接口（通常是其REST接口）。如果是命令行界面，请记录其支持的参数和选项。在许多情况下，最好是自动生成大部分文档，以便本文档随着软件的更改而保持同步，但这并不是必需的。项目可以使用非项目材料的超文本链接作为文档。文档可以自动生成（实际上这通常是最好的方法）。可以使用Swagger / OpenAPI生成REST接口的文档。代码界面文档可以使用 JSDoc （JavaScript）， ESDoc （JavaScript），pydoc（Python）和Doxygen（很多）。仅在实现代码中添加注释不足以满足本条款；在没有阅读所有源代码的情况下，需要一个简单的方法来查看信息。如果项目不生产软件，请选择“不适用”（N/A）。

    README describes checker parameters, output statuses and exit behavior, reusable workflow inputs, and workstation options. PowerShell comment-based help documents tool parameters; Get-Help exposes it without reading implementations. Release docs explain builder inputs and archive/manifest/checksum outputs. https://github.com/KofTwentyTwo/standards/blob/main/README.md https://github.com/KofTwentyTwo/standards/blob/main/tools/Test-RepoConformance.ps1 https://github.com/KofTwentyTwo/standards/blob/main/tools/Build-StandardsPackage.ps1 https://github.com/KofTwentyTwo/standards/blob/main/docs/releases.md


  • 其他


    足够获得徽章！

    项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 [sites_https]
    您可以从Let's Encrypt获取免费证书。项目可以使用（例如） GitHub页面实现此条款， GitLab页面，或 SourceForge项目页面。如果您使用具有自定义域的GitHub页面，则可以使用内容传送网络（CDN）作为代理来支持HTTPS，例如博客文章“使用CloudFlare安全加速GitHub页面”，以满足此条款。如果您支持HTTP，我们敦促您将HTTP流量重定向到HTTPS。

    Repository, documentation, and release downloads use GitHub HTTPS URLs. https://github.com/KofTwentyTwo/standards https://github.com/KofTwentyTwo/standards/releases


    足够获得徽章！

    该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 [discussion]
    可接受机制的示例包括归档邮件列表，GitHub问题和拉请求讨论，Bugzilla，Mantis和Trac。如果满足这些标准，异步讨论机制（如IRC）是可以接受的；确保有一个URL可访问归档机制。允许专有JavaScript，但不鼓励。

    Public GitHub issues and pull requests provide searchable, URL-addressable discussion through a browser and accept contributions. https://github.com/KofTwentyTwo/standards/issues https://github.com/KofTwentyTwo/standards/pulls https://github.com/KofTwentyTwo/standards/blob/main/CONTRIBUTING.md


    足够获得徽章！

    项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 [english]
    英语是计算机技术的通用语言；支持英语增加了全球不同潜在开发者和检视者的数量。即使核心开发人员的主要语言不是英文，项目也可以达到这个标准。

    README, contribution guidance, policies, and issue discussions are in English. https://github.com/KofTwentyTwo/standards/blob/main/README.md https://github.com/KofTwentyTwo/standards/blob/main/CONTRIBUTING.md


    足够获得徽章！

    必须维护该项目。 [maintained]
    至少，项目应尝试响应重大问题和漏洞报告。可能正在维护一个积极追求徽章的项目。所有项目和人员的资源都有限，典型项目必须拒绝某些提议的更改，因此有限的资源和提议拒绝本身并不表示未维护的项目。

    当项目知道将不再维护该项目时，应将此标准设置为“未满足”，并使用适当的机制向其他人指示该项目将不会得到维护。例如，使用“ DEPRECATED”作为其自述文件的第一个标题，在其主页开头附近添加“ DEPRECATED”，在其代码存储库项目说明的开头添加“ DEPRECATED”，在其中添加无需维护的标志其自述文件和/或主页，在任何软件包存储库中将其标记为已弃用（例如npm deprecate ），和/或使用代码存储库的标记系统对其进行归档（例如GitHub的“ archive”设置，GitLab的“ archived”标记， Gerrit的“只读”状态，或SourceForge的“已放弃”项目状态）。可以在这里找到更多讨论。

    Recent merged changes and successful CI demonstrate active maintenance; published v0.1.2 and current issues are available. The project is new, so no long maintenance history is claimed. https://github.com/KofTwentyTwo/standards/pull/24 https://github.com/KofTwentyTwo/standards/actions/runs/38074899308 https://github.com/KofTwentyTwo/standards/releases/tag/v0.1.2


 变更控制 9/9 ●

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


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]
    该URL可以与项目URL相同。该项目可能在特定情况下使用私人（非公开）分支，而更改不会公开发布（例如，在向公众披露漏洞之前修复漏洞）。

    Public GitHub repository exposes the source and Git history. https://github.com/KofTwentyTwo/standards


    足够获得徽章！

    项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。 [repo_track]

    Git commit history records changes, authors, and timestamps. https://github.com/KofTwentyTwo/standards/commits/main/


    足够获得徽章！

    为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 [repo_interim]
    项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。

    Main and reviewed pull requests contain interim development changes between published releases. https://github.com/KofTwentyTwo/standards/pulls https://github.com/KofTwentyTwo/standards/commits/main/


    足够获得徽章！

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

    The project uses Git, a common distributed version control system. https://github.com/KofTwentyTwo/standards


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]
    本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。

    The published release is uniquely identified by v0.1.2 and its source commit. Failed unpublished v0.1.0/v0.1.1 tags remain reserved and are not reused. https://github.com/KofTwentyTwo/standards/releases/tag/v0.1.2 https://github.com/KofTwentyTwo/standards/blob/main/docs/releases.md


    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]
    其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。

    Published releases use vMAJOR.MINOR.PATCH; docs define semantic release rules and breaking-change MAJOR bumps. https://github.com/KofTwentyTwo/standards/blob/main/docs/releases.md https://github.com/KofTwentyTwo/standards/releases/tag/v0.1.2


    足够获得徽章！

    建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。 [version_tags]

    Published v0.1.2 has a Git release tag; release policy requires versioned tags. https://github.com/KofTwentyTwo/standards/releases/tag/v0.1.2 https://github.com/KofTwentyTwo/standards/blob/main/standards/releases.md


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]
    发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。

    v0.1.2 notes summarize the first standards bundle and release fix, link reviewed changes, and explain earlier unpublished versions. https://github.com/KofTwentyTwo/standards/releases/tag/v0.1.2 https://github.com/KofTwentyTwo/standards/blob/main/CHANGELOG.md


    足够获得徽章！

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]
    如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。

    The sole published release records no publicly known project run-time vulnerability with a CVE or similar identifier. The criterion explicitly permits N/A when there have been no publicly known vulnerabilities; future security fixes must reference advisories in release notes. https://github.com/KofTwentyTwo/standards/releases/tag/v0.1.2 https://github.com/KofTwentyTwo/standards/blob/main/standards/releases.md


 报告 8/8 ●

  • 错误报告流程


    足够获得徽章！

    项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。 (需要网址) [report_process]

    Users submit ordinary bugs and proposals through public GitHub issues; contribution instructions explain that process. Security reports use a separate private channel. https://github.com/KofTwentyTwo/standards/issues https://github.com/KofTwentyTwo/standards/blob/main/CONTRIBUTING.md


    足够获得徽章！

    项目必须使用问题跟踪器来跟踪每个问题。 [report_tracker]

    GitHub Issues tracks individual bugs, enhancements, and release checklists. https://github.com/KofTwentyTwo/standards/issues


    足够获得徽章！

    该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。 [report_responses]

    Repository was created 2026-10-09, and all eight current issues date from 2026-10-10. There are no bug reports in the required 2–12-month window, so none are unacknowledged in that period. No mature response history is claimed. https://github.com/KofTwentyTwo/standards/issues?q=is%3Aissue


    足够获得徽章！

    该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 [enhancement_responses]
    答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。

    No enhancement requests exist in the required 2–12-month window: this repository was created 2026-10-09. Current proposals were handled through linked PRs, but no long response history is asserted. https://github.com/KofTwentyTwo/standards/issues/18 https://github.com/KofTwentyTwo/standards/issues/7


    足够获得徽章！

    该项目必须有一个公开的报告和回复的档案供后续搜索。 (需要网址) [report_archive]

    Public GitHub Issues retains open and closed reports and responses for URL-addressable searching. https://github.com/KofTwentyTwo/standards/issues?q=is%3Aissue


  • 漏洞报告流程


    足够获得徽章！

    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [vulnerability_report_process]
    例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。

    SECURITY defines vulnerabilities, reporting steps, disclosure policy, and supported versions. https://github.com/KofTwentyTwo/standards/blob/main/SECURITY.md


    足够获得徽章！

    如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]
    示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。

    SECURITY directs reporters to GitHub private vulnerability reporting over HTTPS rather than a public issue. https://github.com/KofTwentyTwo/standards/blob/main/SECURITY.md https://github.com/KofTwentyTwo/standards/security/advisories/new


    足够获得徽章！

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [vulnerability_report_response]
    如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。

    On 2026-10-10 the maintainer confirmed the criterion that initial responses to any private vulnerability reports in the last six months were within 14 days. Private report details are not published here. SECURITY specifies a seven-day acknowledgment target; this answer relies on maintainer confirmation of actual compliance, not the target alone. https://github.com/KofTwentyTwo/standards/blob/main/SECURITY.md


 质量 13/13 ●

 安全 16/16 ●

 分析 8/8 ●


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

项目徽章条目拥有者： James Maes.
最后更新于 2026-10-10 18:39:21 UTC, 最后更新于 2026-10-10 19:49:21 UTC。 最后在 2026-10-10 19:49:21 UTC 获得通过徽章。