RentnerProxy

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

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

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


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

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

        

 基本 13/13 ●

  • 常规

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

    Modern, open-source and self-hosted reverse proxy manager built with TypeScript, TanStack Start, Rust and Caddy.

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

  • 基本项目网站内容


    足够获得徽章！

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

    The project description clearly identifies RentnerProxy as an open-source, self-hosted reverse proxy manager and names its main technologies. https://github.com/RentnerKev/RentnerProxy


    足够获得徽章！

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

    The project website explains how to obtain the project and links to the public repository and Discord; GitHub Issues provides the feedback path. https://proxy.rentner.dev/ https://github.com/RentnerKev/RentnerProxy/issues


    足够获得徽章！

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

    Contribution instructions are published in CONTRIBUTING.md, including the development workflow and pull-request process. https://github.com/RentnerKev/RentnerProxy/blob/main/CONTRIBUTING.md


    足够获得徽章！

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

    CONTRIBUTING.md documents prerequisites, testing expectations, commit conventions, and pull-request requirements. https://github.com/RentnerKev/RentnerProxy/blob/main/CONTRIBUTING.md


  • FLOSS许可证


    足够获得徽章！

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

    The repository is licensed under the MIT License. https://github.com/RentnerKev/RentnerProxy/blob/main/LICENSE


    足够获得徽章！

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

    The MIT License is an OSI-approved open-source license. https://github.com/RentnerKev/RentnerProxy/blob/main/LICENSE https://opensource.org/license/mit/


    足够获得徽章！

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

    A complete LICENSE file is present at the repository root. https://github.com/RentnerKev/RentnerProxy/blob/main/LICENSE


  • 文档


    足够获得徽章！

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

    Getting-started documentation covers installation, startup, use, and secure operation for the container and local development. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/getting-started.md https://github.com/RentnerKev/RentnerProxy/blob/main/README.md


    足够获得徽章！

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

    The repository documents the web health/media endpoints and the internal Rust controller interface, including inputs, outputs, authorization, and errors. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/api-reference.md


  • 其他


    足够获得徽章！

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

    The project homepage, repository, documentation, and issue links use HTTPS. https://proxy.rentner.dev/ https://github.com/RentnerKev/RentnerProxy


    足够获得徽章！

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

    Public discussion is available through GitHub Issues and pull requests, with an additional Discord link on the project site. https://github.com/RentnerKev/RentnerProxy/issues https://github.com/RentnerKev/RentnerProxy/pulls https://proxy.rentner.dev/


    足够获得徽章！

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

    The README, contributor guidance, security policy, and technical documentation are written in English, and the project accepts English issues and pull requests. https://github.com/RentnerKev/RentnerProxy/blob/main/README.md https://github.com/RentnerKev/RentnerProxy/blob/main/CONTRIBUTING.md


    足够获得徽章！

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

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

    The public repository is actively maintained with recent commits and automated checks on the main branch. https://github.com/RentnerKev/RentnerProxy/commits/main https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


 变更控制 9/9 ●

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


    足够获得徽章！

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

    The source repository is publicly readable on GitHub. https://github.com/RentnerKev/RentnerProxy


    足够获得徽章！

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

    Git records the changes, authors, and timestamps for the source repository. https://github.com/RentnerKev/RentnerProxy/commits/main


    足够获得徽章！

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

    The public main branch contains ongoing development commits between releases, rather than only final release snapshots. https://github.com/RentnerKev/RentnerProxy/commits/main


    足够获得徽章！

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

    The project uses a public Git repository, which provides distributed version control. https://github.com/RentnerKev/RentnerProxy


  • 唯一版本编号


    足够获得徽章！

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

    Development snapshots are uniquely identifiable by their full Git commit SHA, and the container workflow publishes immutable sha-commit image tags. https://github.com/RentnerKev/RentnerProxy/commits/main https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/container-image.yml


    足够获得徽章！

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

    足够获得徽章！

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

    Release v0.0.1-dev.20260902 is identified by its Git tag and corresponding GitHub pre-release. The tag is available in the public repository and points to the released source snapshot. https://github.com/RentnerKev/RentnerProxy/releases/tag/v0.0.1-dev.20260902 https://github.com/RentnerKev/RentnerProxy/tree/v0.0.1-dev.20260902


  • 发行说明


    足够获得徽章！

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

    CHANGELOG.md provides human-readable change summaries, and the release policy requires release notes for each future release. https://github.com/RentnerKev/RentnerProxy/blob/main/CHANGELOG.md https://github.com/RentnerKev/RentnerProxy/blob/main/docs/releasing.md


    足够获得徽章！

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

    No public release has been published and no publicly known project runtime vulnerability has been assigned; this criterion is not applicable yet. https://github.com/RentnerKev/RentnerProxy/releases https://github.com/RentnerKev/RentnerProxy/blob/main/CHANGELOG.md


 报告 8/8 ●

  • 错误报告流程


    足够获得徽章！

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

    GitHub Issues is the documented public path for bug reports and project feedback. https://github.com/RentnerKev/RentnerProxy/issues https://github.com/RentnerKev/RentnerProxy/blob/main/README.md


    足够获得徽章！

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

    The project uses the GitHub issue tracker for individual reports and discussions. https://github.com/RentnerKev/RentnerProxy/issues


    足够获得徽章！

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

    The public tracker currently contains no unanswered bug reports from the applicable period; the issue tracker and pull requests are actively monitored. https://github.com/RentnerKev/RentnerProxy/issues https://github.com/RentnerKev/RentnerProxy/pulls


    足够获得徽章！

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

    The public tracker currently contains no unanswered enhancement requests from the applicable period; the issue tracker and pull requests are actively monitored. https://github.com/RentnerKev/RentnerProxy/issues https://github.com/RentnerKev/RentnerProxy/pulls


    足够获得徽章！

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

    GitHub Issues provides a public, searchable archive of reports and responses. https://github.com/RentnerKev/RentnerProxy/issues


  • 漏洞报告流程


    足够获得徽章！

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

    SECURITY.md publishes the vulnerability-reporting process and asks users not to disclose vulnerabilities in public issues. https://github.com/RentnerKev/RentnerProxy/blob/main/SECURITY.md


    足够获得徽章！

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

    SECURITY.md documents GitHub private vulnerability reporting and links to the private advisory form. https://github.com/RentnerKev/RentnerProxy/blob/main/SECURITY.md https://github.com/RentnerKev/RentnerProxy/security/advisories/new


    足够获得徽章！

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

    No vulnerability reports were received in the last six months, so the response-time criterion is not applicable. https://github.com/RentnerKev/RentnerProxy/blob/main/SECURITY.md


 质量 13/13 ●

  • 可工作的构建系统


    足够获得徽章！

    如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 [build]
    构建系统确定重建软件（以及以什么顺序）需要执行哪些操作，然后执行这些步骤。例如，它可以调用编译器来编译源代码。如果从源代码创建可执行文件，则必须可以修改项目的源代码，然后通过这些修改生成更新的可执行文件。如果项目生成的软件取决于外部库，则构建系统不必构建那些外部库。如果在修改源代码之后不需要构建任何使用该软件的软件，请选择“不适用”（N/A）。

    The repository provides Bun, Cargo, and container build instructions; CI automatically installs dependencies and builds production artifacts from source. https://github.com/RentnerKev/RentnerProxy/blob/main/package.json https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml https://github.com/RentnerKev/RentnerProxy/blob/main/docs/getting-started.md


    足够获得徽章！

    建议使用通用工具来构建软件。 [build_common_tools]
    例如，Maven，Ant，cmake，自动工具，make，rake（Ruby）或devtools （R）。

    The build uses standard public tools for the languages and deployment format: Bun, Cargo/Rust, Docker, and Compose. https://github.com/RentnerKev/RentnerProxy/blob/main/package.json https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml https://github.com/RentnerKev/RentnerProxy/blob/main/docs/getting-started.md


    足够获得徽章！

    该项目应该仅使用FLOSS工具来构建。 [build_floss_tools]

    The documented build uses publicly available FLOSS toolchains and build tools, including Bun, Rust/Cargo, and Docker/Compose. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/getting-started.md https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


  • 自动测试套件


    足够获得徽章！

    该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 [test]
    该项目可以使用多个自动测试套件（例如，一个是快速运行的测试套件，而另一个更为彻底但需要特殊设备）。

    Public Bun and Cargo test suites are documented and run in CI, including web, controller, integration, fuzz, and property-based tests. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


    足够获得徽章！

    测试套件应该以该语言的标准方式进行调用。 [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

    The test suites use standard commands such as bun run test, bun run test:ts, bun run test:fuzz, and cargo test. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md


    足够获得徽章！

    建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。 [test_most]

    The documented suites cover authentication, sessions, authorization, validation, tokens, encryption, database health, proxy configuration, certificates, ACME, runtime state, TLS, and rollback paths. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md


    足够获得徽章！

    建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 [test_continuous_integration]

    GitHub Actions runs format, lint, type checks, database/integration tests, fuzz tests, Rust tests, and production builds on pushes and pull requests. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


  • 新功能测试


    足够获得徽章！

    该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 [test_policy]
    只要有相应的策略，即使是通过口头传播，也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试，选择“Met”。

    CONTRIBUTING.md requires automated tests for major features, security-sensitive changes, and externally visible behavior, including relevant failure and authorization paths. https://github.com/RentnerKev/RentnerProxy/blob/main/CONTRIBUTING.md


    足够获得徽章！

    该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 [tests_are_added]
    主要功能通常在发行说明中提及。不需要完美，只需证明，当新的主要功能添加到项目生成的软件时，测试通常会在实践中被添加到自动化测试套件中。

    Recent runtime and security changes are accompanied by regression, integration, Rust, and smoke-test coverage; the repository documents the test areas and policy. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md https://github.com/RentnerKev/RentnerProxy/commits/main


    足够获得徽章！

    建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 [tests_documented_added]
    但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。

    https://github.com/RentnerKev/RentnerProxy/blob/main/CONTRIBUTING.md#testing-policy — CONTRIBUTING.md documents the policy and commands for adding tests with major new functionality and security-sensitive changes.


  • 警告标志


    足够获得徽章！

    该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 [warnings]
    编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。

    Oxlint is run for the web code and Cargo Clippy is run for the controller in CI. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


    足够获得徽章！

    该项目必须处理警告。 [warnings_fixed]
    告警是通过执行warnings条款确定的。该项目应该修复告警或在源代码中将其标记为误报。理想情况下，不会有告警，但项目可能会接受一些告警（通常每100行小于1个告警，或整体少于10个告警）。

    CI treats lint and compiler-warning failures as errors, so warnings must be addressed before the check succeeds. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


    足够获得徽章！

    建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 [warnings_strict]
    某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。

    The Rust CI command uses Clippy with -D warnings, alongside the Oxlint check. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


 安全 16/16 ●

 分析 8/8 ●

  • 静态代码分析


    足够获得徽章！

    如果至少有一个FLOSS工具以所选择的语言实现此条款，则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 [static_analysis]
    静态代码分析工具检查软件代码（源代码，中间代码或可执行文件），而不用特定输入执行。本条款中，编译器警告和“安全”语言模式不被视为静态代码分析工具（它们通常避免深入分析，因为速度至关重要）。此类静态代码分析工具的示例包括 cppcheck ， clang静态分析器， FindBugs （包括FindSecurityBugs）， PMD ， Brakeman ， Coverity质量分析器和 HP Fortify静态代码分析器。更多的工具列表可以在诸如维基百科静态代码分析工具列表，关于静态代码分析的OWASP信息， NIST源代码安全分析器列表和 Wheeler的静态分析工具列表。 SWAMP 是使用各种工具评估软件漏洞的免费平台。如果没有可用于所使用的实现语言的FLOSS静态分析工具，请选择“N/A”。

    CodeQL is configured for JavaScript/TypeScript, Rust, and GitHub Actions and runs before release-relevant changes. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/codeql.yml


    足够获得徽章！

    建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 [static_analysis_common_vulnerabilities]
    专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。

    CodeQL analyzes the supported languages and GitHub Actions for common security vulnerabilities. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/codeql.yml


    足够获得徽章！

    使用静态代码分析发现的所有中，高严重性可利用漏洞必须在确认后及时修复。 [static_analysis_fixed]
    如果其 CVSS 2.0 评分为4或更高，则此漏洞是中等到高的严重性。

    CodeQL results are reviewed through the CI/security workflow, and confirmed exploitable findings are handled through the documented security and remediation process. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/codeql.yml https://github.com/RentnerKev/RentnerProxy/blob/main/SECURITY.md


    足够获得徽章！

    建议每次提交或至少每天执行静态源代码分析。 [static_analysis_often]

    CodeQL runs on pushes, pull requests, and a weekly schedule. https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/codeql.yml


  • 动态代码分析


    足够获得徽章！

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

    Fast-check fuzz/property tests vary inputs in CI, and the repository also documents OpenResty/TLS/SNI/ACME/rollback smoke testing. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


    足够获得徽章！

    建议如果项目生成的软件包含使用内存不安全语言编写的软件（例如C或C++），则至少有一个动态工具（例如，fuzzer或web应用扫描程序）与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写，请选择“不适用”（N / A）。 [dynamic_analysis_unsafe]
    检测内存安全问题的机制的示例包括AddressSanitizer（ASAN）（可在GCC和LLVM中使用），“Memory Sanitizer”和 valgrind 。其他可能使用的工具包括ThreadSanitizer和UndefinedBehaviorSanitizer。广泛的断言也将起作用。

    The project produces TypeScript, Rust, and PL/pgSQL, not software written in a memory-unsafe language such as C or C++. https://github.com/RentnerKev/RentnerProxy


    足够获得徽章！

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

    Rust cargo test runs with development assertions enabled, and the dynamic fuzz/property suites run before build/release checks. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md https://github.com/RentnerKev/RentnerProxy/blob/main/.github/workflows/ci.yml


    足够获得徽章！

    通过动态代码分析发现的所有严重性为中，高的可利用漏洞必须在确认后及时修复。 [dynamic_analysis_fixed]
    如果 CVSS 2.0 基本分数为4，那么一个漏洞是中等到高的严重性。如果您没有运行动态代码分析，没有发现任何这样的漏洞，选择“不适用”（N/A）。

    Dynamic fuzz/property and runtime smoke tests run in CI; confirmed exploitable findings are handled under the documented testing and security policies. https://github.com/RentnerKev/RentnerProxy/blob/main/docs/testing.md https://github.com/RentnerKev/RentnerProxy/blob/main/SECURITY.md



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

项目徽章条目拥有者： RentnerKev.
最后更新于 2026-08-29 12:55:29 UTC, 最后更新于 2026-09-14 08:59:53 UTC。 最后在 2026-09-02 22:03:28 UTC 获得通过徽章。