t3x-rte_ckeditor_image

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

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

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


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

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

        

 基本 13/13 ●

 变更控制 9/9 ●

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


    足够获得徽章！

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

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is 97c1108809d56f921048767f95e0ddf1e6b15119. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image https://github.com/netresearch/t3x-rte_ckeditor_image/commits/main


    足够获得徽章！

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

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is 97c1108809d56f921048767f95e0ddf1e6b15119. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image https://github.com/netresearch/t3x-rte_ckeditor_image/commits/main


    足够获得徽章！

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

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is 97c1108809d56f921048767f95e0ddf1e6b15119. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image https://github.com/netresearch/t3x-rte_ckeditor_image/commits/main


    足够获得徽章！

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

    The public Git repository records intermediate commits, authors, timestamps, and changes. Current inspected revision is 97c1108809d56f921048767f95e0ddf1e6b15119. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image https://github.com/netresearch/t3x-rte_ckeditor_image/commits/main


  • 唯一版本编号


    足够获得徽章！

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

    Published release/tag identifiers uniquely identify source snapshots; assets are associated with the corresponding GitHub release. Recent identifiers: v13.10.2, v13.10.1, v13.10.0, v13.9.1, v13.9.0. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/tags https://github.com/netresearch/t3x-rte_ckeditor_image/releases


    足够获得徽章！

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

    Recent published tags use semantic-version numbering: v13.10.2, v13.10.1, v13.10.0, v13.9.1, v13.9.0. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/tags


    足够获得徽章！

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

    Published release/tag identifiers uniquely identify source snapshots; assets are associated with the corresponding GitHub release. Recent identifiers: v13.10.2, v13.10.1, v13.10.0, v13.9.1, v13.9.0. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/tags https://github.com/netresearch/t3x-rte_ckeditor_image/releases


  • 发行说明


    足够获得徽章！

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

    Versioned human-readable changelog entries describe functional/security changes and include the latest release v13.10.2. This uses the maintained changelog rather than a raw merge-commit list. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/CHANGELOG.md https://github.com/netresearch/t3x-rte_ckeditor_image/releases/tag/v13.10.2


    足够获得徽章！

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

    Retained the maintainer statement that security fixes are identified in release/change notes, corroborated by the documented XSS/SVG or authentication security changes. No omitted already-assigned public project CVE was found in the reviewed notes/advisory channel. Evidence: https://www.bestpractices.dev/en/projects/11718 https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/CHANGELOG.md https://github.com/netresearch/t3x-rte_ckeditor_image/security/advisories


 报告 7/8 ●

  • 错误报告流程


    足够获得徽章！

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

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/issues https://github.com/netresearch/t3x-rte_ckeditor_image/pulls


    足够获得徽章！

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

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/issues https://github.com/netresearch/t3x-rte_ckeditor_image/pulls


    足够获得徽章！

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

    Reviewed the public issue window 2026-07-29 through 2026-09-29. The majority of qualifying reports/requests have responses or were resolved; automated dependency dashboards and spam are excluded. Where no qualifying request was filed in this window, there is no unanswered request to count. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/issues?q=is%3Aissue+created%3A%3E%3D2026-07-29


    足够获得徽章！

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

    Reviewed the public issue window 2026-07-29 through 2026-09-29. The majority of qualifying reports/requests have responses or were resolved; automated dependency dashboards and spam are excluded. Where no qualifying request was filed in this window, there is no unanswered request to count. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/issues?q=is%3Aissue+created%3A%3E%3D2026-07-29


    足够获得徽章！

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

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/issues https://github.com/netresearch/t3x-rte_ckeditor_image/pulls


  • 漏洞报告流程


    足够获得徽章！

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

    The published security policy gives concrete vulnerability-reporting contact instructions. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/SECURITY.md


    足够获得徽章！

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

    The policy provides a private reporting channel; GitHub private vulnerability reporting is enabled. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/SECURITY.md https://github.com/netresearch/t3x-rte_ckeditor_image/security/advisories


    未知的所需信息，不足以用于徽章。

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

    The published reporting policy does not establish actual initial-response times for all private reports in the last six months. Confirm the report history, including whether there were no reports. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


 质量 13/13 ●

 安全 9/16 ●

  • 安全开发知识


    足够获得徽章！

    该项目必须至少有一个主要开发人员知道如何设计安全软件。 [know_secure_design]
    这需要了解以下设计原则，包括 Saltzer和Schroeder 中的8项原则：
    • 机制经济（保持设计简单实用，例如采用彻底简化）
    • 故障安全默认（默认情况下，访问决策应拒绝），项目安装应默认安全）
    • 完全仲裁（必须检查每个可能被限制的访问权限，并且不可绕过）
    • 开放式设计（安全机制不应该依赖于攻击者对其设计的无知，而应该更容易地保护和更改信息，例如密钥和密码）
    • 特权分离（理想情况下，对重要对象的访问应该取决于多个条件，从而破坏一个保护系统将无法实现完全访问。如，多因子身份验证，要求密码和硬件令牌，比单因子认证安全性更高）
    • 最小权限（进程应该以最少的权限运行）
    • 最少的公共机制（设计应该最大限度地减少所有用户所依赖的，涉及到多个用户的共同机制，如，临时文件的目录）
    • 心理可接受性（人机接口必须设计为易于使用 —— 设计为“最不惊讶”）
    • 有限的攻击面（攻击面 —— 一组不同的入口，其​​中攻击者可以尝试输入或提取数据 —— 应该受到限制）
    • 输入验证与白名单（输入通常应该在被接受之前检查以确定是否有效；此验证应使用白名单（仅接受已知的有效值），而不是黑名单（尝试列出已知的非法值））。
    项目中的“主要开发人员”的定义是熟悉项目代码的任何人，很乐意对其进行更改，并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码，文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员，如果他们启动项目（并且还没有离开项目满三年），可以选择在私人漏洞报告渠道（如果有的话）上接收信息，可以代表项目接受提交，或执行项目软件的最终版本发布。如果只有一个开发者，那个人是主要开发人员。

    Retained the existing maintainer self-attestation after reviewing current source/policy; no conflicting evidence was found. SECURITY.md documents implemented security measures: XSS prevention (htmlspecialchars), SSRF protection (DNS rebinding/private IP blocking), file visibility validation, dangerous protocol blocking. ADR-003 documents security responsibility boundaries. Evidence: https://www.bestpractices.dev/en/projects/11718 https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/.bestpractices.json


    足够获得徽章！

    该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 [know_common_errors]
    示例（取决于软件的类型）包括SQL注入，操作系统注入，经典缓冲区溢出，跨站点脚本（XSS），缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞或 OWASP十大漏洞类型项目。

    Retained the existing maintainer self-attestation after reviewing current source/policy; no conflicting evidence was found. Developers demonstrate knowledge of common vulnerability types: XSS (caption sanitization), SSRF (external image fetching protection), CSS injection (style attribute exclusion), URL scheme attacks (protocol blocking), as documented in SECURITY.md. Evidence: https://www.bestpractices.dev/en/projects/11718 https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/.bestpractices.json


  • 使用基础的良好加密实践

    请注意，某些软件不需要使用加密机制。

    足够获得徽章！

    项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 [crypto_published]
    这些加密条款并不总是适用，因为某些软件不需要直接使用加密功能。

    Cryptographic operations use documented PHP/TYPO3 primitives and FLOSS dependencies: standard TLS through PHP/Guzzle and, where used, nr-vault/libsodium for stored secrets. No custom cryptographic primitive is implemented. Provider service licensing does not make the local crypto implementation proprietary. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/composer.json https://github.com/netresearch/t3x-rte_ckeditor_image/tree/97c1108809d56f921048767f95e0ddf1e6b15119/Classes/


    足够获得徽章！

    如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。 [crypto_call]

    Cryptographic operations use documented PHP/TYPO3 primitives and FLOSS dependencies: standard TLS through PHP/Guzzle and, where used, nr-vault/libsodium for stored secrets. No custom cryptographic primitive is implemented. Provider service licensing does not make the local crypto implementation proprietary. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/composer.json https://github.com/netresearch/t3x-rte_ckeditor_image/tree/97c1108809d56f921048767f95e0ddf1e6b15119/Classes/


    足够获得徽章！

    项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 [crypto_floss]
    请参阅OSI （开放源代码促进会）发布的软件开放标准需求。

    Cryptographic operations use documented PHP/TYPO3 primitives and FLOSS dependencies: standard TLS through PHP/Guzzle and, where used, nr-vault/libsodium for stored secrets. No custom cryptographic primitive is implemented. Provider service licensing does not make the local crypto implementation proprietary. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/composer.json https://github.com/netresearch/t3x-rte_ckeditor_image/tree/97c1108809d56f921048767f95e0ddf1e6b15119/Classes/


    未知的所需信息，不足以用于徽章。

    项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 [crypto_keylength]
    这些最小位长度是：对称密钥112，因式分解模数2048，离散对数密钥224，离散对数组2048，椭圆曲线224和散列224（密码散列不涉及该位长度），关于密码散列的更多信息可以在 crypto_password_storage 条款）。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中，软件可能允许较小的密钥长度（理想情况下不会，因为这允许降级攻击，但是互操作性有时需要较短的密钥长度）。

    No verified inventory of every default key length and the ability to disable weaker configurations was obtained. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


    未知的所需信息，不足以用于徽章。

    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 [crypto_working]
    在许多情况下，最好选择设计用于组合保密和认证的块密码算法模式，例如Galois / Counter Mode（GCM）和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制，但是需要用户知道他们正在这么做。

    The public evidence does not establish that every default cryptographic mechanism avoids broken algorithms and context-inappropriate modes. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


    未知的所需信息，不足以用于徽章。

    由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。 [crypto_weaknesses]
    在 CERT：SSH CBC漏洞中讨论了SSH中CBC模式的问题。

    The public evidence does not establish that every default security mechanism avoids algorithms and modes with known serious weaknesses. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


    未知的所需信息，不足以用于徽章。

    项目产生的软件中的安全机制应该​​对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。 [crypto_pfs]

    Forward secrecy depends on the actual key-agreement protocols and deployment configuration; supporting HTTPS alone is insufficient. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


    足够获得徽章！

    如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。 [crypto_password_storage]
    此条款仅适用于软件强制使用密码验证用户身份的情况（如服务器端Web应用程序）。在软件存储用于认证到其他系统的密码（例如，该软件实现某个其他系统的客户端）的情况下，这是不适用的，因为该软件的至少某个部分必须经常访问未散列加密的密码。

    The extension does not implement an external-user password-authentication database. Authentication belongs to TYPO3; outbound API credentials and encrypted vault secrets are not user-authentication password storage under this criterion. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/tree/97c1108809d56f921048767f95e0ddf1e6b15119/Classes/ https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/composer.json


    未知的所需信息，不足以用于徽章。

    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 [crypto_random]
    密码安全的随机数生成器可以是硬件随机数生成器，或者它可以是使用诸如Hash_DRBG，HMAC_DRBG，CTR_DRBG，Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器（CSPRNG）。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的Math.random。

    The complete set of key and nonce generation sites was not verified against CSPRNG requirements. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


  • 安全交付防御中间人（MITM）的攻击


    足够获得徽章！

    该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [delivery_mitm]
    一个更强大的机制是使用数字签名的软件包发布软件，因为这样可以减轻对分发系统的攻击，但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。

    The canonical repository and GitHub release/download endpoints use authenticated HTTPS. No release process in the reviewed configuration trusts an unsigned digest obtained over HTTP. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image https://github.com/netresearch/t3x-rte_ckeditor_image/releases


    足够获得徽章！

    不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 [delivery_unsigned]
    这些散列可以在传输过程中修改。

    The canonical repository and GitHub release/download endpoints use authenticated HTTPS. No release process in the reviewed configuration trusts an unsigned digest obtained over HTTP. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image https://github.com/netresearch/t3x-rte_ckeditor_image/releases


  • 修正公开的漏洞


    未知的所需信息，不足以用于徽章。

    被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 [vulnerabilities_fixed_60_days]
    该漏洞必须由项目本身修补和发布（修补程序可能在其他地方开发）。一旦漏洞具有公开发布的非付费信息的CVE（例如，在国家漏洞数据库）或项目已被通知，且信息已经发布给公众（可能是项目自己发布），则视为漏洞已经公众所知。如果其 CVSS 2.0 基本分数为4或更高，则漏洞是中等到高的严重性。 注意：这意味着全世界的所有攻击者可能会对用户造成长达60天的伤害。这个标准通常比Google在重新启动负责任的披露中所推荐的容易得多。因为Google建议，如果报告不是公开的，那么当项目得到通知，甚至报告尚未公开时，60天的时间段就会开始。

    A policy or dependency-audit workflow does not prove that no project or dependency vulnerability of medium or higher severity has remained unpatched for more than sixty days. A dated complete vulnerability inventory is needed. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


    未知的所需信息，不足以用于徽章。

    项目在得到报告后应该迅速修复所有致命漏洞。 [vulnerabilities_critical_fixed]

    A remediation target does not prove actual prompt handling of every critical vulnerability; historical security incident evidence is needed. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image


  • 其他安全问题


    足够获得徽章！

    公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 [no_leaked_credentials]
    项目可以泄漏测试和不重要数据库的“样本”凭据，只要它们不旨在限制公共访问。

    The current secret-scanning CI job completed successfully and no valid private credential was identified in the reviewed project evidence. This is current assessment evidence, not a claim that no secret was ever present historically. Evidence: https://github.com/netresearch/t3x-rte_ckeditor_image/actions/runs/36386528655/job/108812952231 https://github.com/netresearch/t3x-rte_ckeditor_image/blob/97c1108809d56f921048767f95e0ddf1e6b15119/.github/workflows/checks.yml


 分析 6/8 ●


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

项目徽章条目拥有者： Sebastian Mendel.
最后更新于 2026-01-09 06:04:47 UTC, 最后更新于 2026-09-29 15:19:00 UTC。 最后在2026-09-29 15:19:00 UTC丢失通过徽章。 最后在 2026-02-18 18:16:24 UTC 获得通过徽章。