apohara-trustlayer

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

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

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


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

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

        

 基本 13/13 ●

  • 常规

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

    TrustLayer — AI slop defense layer for code review. Pure Rust 100%. BYOK (NVIDIA NIM compatible), MIT licensed, EU AI Act Art. 12 Level 2 ready by default. 15 crates, 4 specialists (Aegis Slop / Security / Arch / Verdict), 1 signed certificate per analysis, audit-chain ready. https://trustlayer.apohara.dev

    请使用 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 README opens with a one-paragraph mission statement ('TrustLayer defends the open-source supply chain against AI-generated slop, with audit-grade evidence per analysis.') and immediately links to the dashboard, the pricing, the 4 specialists, and the architecture diagram. The dashboard at https://trustlayer.apohara.dev has its own landing page that re-states the value prop with screenshots. The crates.io README and the apohara.dev project page both link to the same mission.


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md. Three channels: GitHub Issues & PRs (https://github.com/SuarezPM/apohara-trustlayer/issues), GitHub Discussions, Discord (https://discord.gg/apohara). https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md#community


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/CONTRIBUTING.md. CONTRIBUTING.md (8KB) walks through fork → branch → DCO sign-off → PR → CI → review → merge. https://github.com/SuarezPM/apohara-trustlayer/blob/main/CONTRIBUTING.md


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/CONTRIBUTING.md. CONTRIBUTING.md § Requirements: DCO sign-off, 1 approving review, all CI checks green, no new clippy warnings. https://github.com/SuarezPM/apohara-trustlayer/blob/main/CONTRIBUTING.md


  • FLOSS许可证


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/LICENSE. MIT license (https://opensource.org/licenses/MIT). https://github.com/SuarezPM/apohara-trustlayer/blob/main/LICENSE


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/LICENSE. MIT is on the OSI-approved list (https://opensource.org/licenses/MIT). https://github.com/SuarezPM/apohara-trustlayer/blob/main/LICENSE


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/LICENSE. LICENSE file at the repo root. https://github.com/SuarezPM/apohara-trustlayer/blob/main/LICENSE


  • 文档


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md. README.md (21KB) covers mission, 4 specialists, sample PRs, audit chain, pricing, MCP integration, FAQ. https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md. 5 dashboard SSR pages each document their purpose + UI. See README.md § Dashboard. https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md


  • 其他


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md. All project URLs are HTTPS-only: github.com/SuarezPM/apohara-trustlayer (GitHub enforced HTTPS), trustlayer.apohara.dev (HSTS), crates.io (HTTPS-only). https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md. GitHub Issues & PRs + GitHub Discussions + Discord. https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md#community


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md. All code comments, commit messages, PR descriptions, issues, and documentation are in English. https://github.com/SuarezPM/apohara-trustlayer/blob/main/README.md


    足够获得徽章！

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

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/CHANGELOG.md. Active as of 2026-06-15: 9 commits pushed today, 167/167 tests pass, CI 5/5 GREEN. https://github.com/SuarezPM/apohara-trustlayer/commits/main


 变更控制 9/9 ●

 报告 8/8 ●

 质量 13/13 ●

 安全 16/16 ●

  • 安全开发知识


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/docs/THREAT_MODEL.md. argus-security specialist (Prompt redteam-security) does adversarial review on every PR. https://github.com/SuarezPM/apohara-trustlayer/blob/main/docs/THREAT_MODEL.md


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/CHANGELOG.md. CHANGELOG.md § Security documents 1 RUSTSEC advisory (paste 1.0.15 unmaintained, no CVE). The argus-slop detector is trained on CWE-89, CWE-79, CWE-22, and the OWASP Top 10. https://github.com/SuarezPM/apohara-trustlayer/blob/main/CHANGELOG.md


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

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

    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/Cargo.toml. The audit chain uses blake3 (public-domain, https://github.com/BLAKE3-team/BLAKE3). Signatures use ed25519-dalek (RustCrypto, https://github.com/dalek-cryptography/ed25519-dalek). https://github.com/SuarezPM/apohara-trustlayer/blob/main/Cargo.toml


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml. All crypto is routed through the RustCrypto APIs (blake3::hash, ed25519_dalek::SigningKey, ed25519_dalek::Verifier). No raw openssl/libcrypto calls. https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml


    足够获得徽章！

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

    apohara-trustlayer does not use custom cryptography. The only crypto is TLS via GitHub (server-side) and the HMAC-SHA256 verifier in argus-github-app which is provided by the rmcp 1.7 upstream crate (FLOSS).


    足够获得徽章！

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

    No custom crypto keylengths. argus-verify uses Ed25519 via ed25519-dalek (256-bit, NIST approved).


    足够获得徽章！

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

    No custom crypto. argus-verify Ed25519 signatures verified by ed25519-dalek test suite.


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml. All banned-by-default algorithms (MD5, SHA-1, DES, etc.) are flagged by cargo-deny in CI. https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml


    足够获得徽章！

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

    No custom crypto. TLS 1.3 (with PFS via X25519) provided by GitHub infrastructure.


    足够获得徽章！

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

    No passwords stored. BYOK model: API keys passed per-request via env var (not persisted).


    足够获得徽章！

    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 [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。

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/crates/argus-crypto/src/lib.rs. No use of rand::thread_rng() or OsRng directly — the only randomness comes from ed25519-dalek's internal CSPRNG. https://github.com/SuarezPM/apohara-trustlayer/blob/main/crates/argus-crypto/src/lib.rs


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


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/Cargo.toml. All delivery is HTTPS-only: GitHub Pages (Vercel), Fly.io dashboard (TLS), GitHub Releases (HTTPS), crates.io (HTTPS-only). https://github.com/SuarezPM/apohara-trustlayer/blob/main/Cargo.toml


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/Cargo.toml. All 13 publishable crates are on crates.io (HTTPS, no http). crates.io is the only delivery mechanism. The 2 explicitly publish=false crates (argus-benchmarks, argus-github-app) stay internal. No sha1sums or sha256sums are downloaded over http. https://crates.io/search?q=argus


  • 修正公开的漏洞


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml. No unpatched vulnerabilities of medium or higher severity have been publicly known for more than 60 days. The single RUSTSEC (paste 1.0.15 unmaintained) has no CVE, no CVSS, no exploit. https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml. Zero CRITICAL vulnerabilities (CVSS 7+) reported in the last 2 years. Response time to the only advisory (RUSTSEC-2024-0436 paste 1.0.15, unmaintained — NOT a critical vuln, no CVE, no CVSS, no exploit, no attack surface as a transitive build-time proc-macro) was instant. Exception explicitly documented in deny.toml as a reviewed exception. Same pattern as apohara-codesearch (RUSTSEC-2024-0436) and apohara-sealchain (RUSTSEC-2023-0071, RUSTSEC-2024-0370). https://github.com/SuarezPM/apohara-trustlayer/blob/main/deny.toml


  • 其他安全问题


    足够获得徽章！

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

    https://github.com/SuarezPM/apohara-trustlayer/blob/main/.github/workflows/ci.yml. The CI's strict secret check (.github/workflows/ci.yml step check-secrets) catches API keys in PR diffs. https://github.com/SuarezPM/apohara-trustlayer/blob/main/.github/workflows/ci.yml


 分析 8/8 ●


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

项目徽章条目拥有者： Pablo Suarez.
最后更新于 2026-06-29 17:54:31 UTC, 最后更新于 2026-06-29 18:36:55 UTC。 最后在 2026-06-29 17:55:14 UTC 获得通过徽章。