spector

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

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

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


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

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

        

 基本 17/17 ●

  • 常规

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

    Memory backbone for AI agents. Four-tier store — working, episodic, semantic, procedural — with decay, consolidation, and association graphs. Fused semantic + SIMD-accelerated hybrid recall, in-process MCP, REST/gRPC, and language SDKs.

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

  • 先决条件


    足够获得徽章！

    项目必须拥有通过徽章。 [achieve_passing]

  • 基本项目网站内容


    足够获得徽章！

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

    https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#coding-standards


  • 项目监督


    足够获得徽章！

    该项目应该有一个合法机制，所有对项目软件做出显著贡献的开发人员都声明他们有合法授权作出这些贡献。最常用且易于实施的方法是使用开发者原产地证书（DCO），用户可以在其提交中添加“signed-off-by”，另外，项目链接到DCO网站。本条款也可以使用贡献者许可协议（CLA）或其他法律机制实现。 (需要网址) [dco]
    DCO是推荐的机制，因为它易于实现，在源代码中进行跟踪，并且git使用“commit -s”直接支持“签名”功能。更有效的是，项目文件解释了该项目的“签名”手段。 CLA是一项法律协议，用于定义知识产权许可给组织或项目的条款。捐助者转让协议（CAA）是将知识产权权利转让给另一方的法律协议；项目不必具备CAA，因为CAA增加了潜在贡献者不愿贡献的风险，特别是如果接收者是一个营利性组织。 Apache Software Foundation CLA（个人贡献者许可证和公司CLA）是CLA的示例，用于确定项目的这些CLA的风险对项目的影响小于其获益。

    The project enforces a mandatory legal contribution mechanism using both the Developer Certificate of Origin (DCO 1.1) and a formal Contributor License Agreement (CLA.md). All commits require a Signed-off-by line (git commit -s) certifying the author is legally authorized to submit the code under Apache 2.0, enforced by automated CI checks. https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#developer-certificate-of-origin-dco-11--licensing


    足够获得徽章！

    该项目必须明确定义和记录其项目治理模式（决策方式，包括关键角色）。 (需要网址) [governance]
    需要有一些成熟的书面方式来作出决定和解决争端。在小项目中，这可能就像“项目拥有者和负责人做所有最终决定”一样简单。有各种治理模式，包括仁慈的独裁者和正式的精英统治；有关详细信息，请参阅治理模式。集中式（例如，单一维护者）和分散式（例如，组维护者）方法都已经在项目中成功使用。治理信息不需要记录创建项目分支的可能性，因为对于FLOSS项目来说总是可能的。

    The project documents its open-source governance model, leadership roles, and decision-making mechanics in GOVERNANCE.md:
    https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md

    Key Roles & Structure:

    • Defined meritocratic roles: Project Lead, Technical Lead (TSC Chair), Architecture Working Group (AWG), Technical Steering Committee (TSC), Maintainers, Committers/Reviewers, and Contributors.
    • A 4-tier Contributor Ladder with transparent progression criteria from first-time contributor to TSC member based on sustained technical merit. Corporate titles hold no review or merge authority.

    Decision-Making Process:

    • Lazy Consensus (72 hours without objection) for routine pull requests, bug fixes, and documentation.
    • Simple Majority (>50%) of Maintainers for committer appointments and non-breaking deprecations.
    • Supermajority (2/3 vote) of the Technical Steering Committee for formal Architecture Decision Records (ADRs), breaking API changes, and governance amendments.

    足够获得徽章！

    该项目必须采取行为守则，并将其发布在标准的位置。 (需要网址) [code_of_conduct]
    项目可能能够提高社区的文明程度，并通过采取行为守则来规定对可接受的行为的期望。这可以帮助在发生问题之前避免问题，并使项目成为更加欢迎的地方来鼓励贡献。这应该只关注项目社区/工作场所的行为。行为规范的示例是贡献者约定行为准则和Linux内核代码冲突。

    The project adopts the Contributor Covenant Code of Conduct (v2.1), posted in the standard root location (CODE_OF_CONDUCT.md), outlining community standards, enforcement guidelines, and reporting channels (support@spectrayan.com). https://github.com/spectrayan/spector/blob/main/CODE_OF_CONDUCT.md


    足够获得徽章！

    该项目必须明确定义和公开记录项目中的关键角色及其职责，包括这些角色必须执行的任务。必须清楚指出谁是什么角色，尽管这可能没有以相同的方式记录下来。 (需要网址) [roles_responsibilities]
    治理和角色和职责的文档可以在一个地方。

    Spector defines and documents its project roles, responsibilities, and specific tasks in GOVERNANCE.md (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#2-governance-structure--roles), covering the Project Lead, Technical Lead, Architecture Working Group, Technical Steering Committee, Maintainers, Committers, and Contributors. Specific role holders and maintainer responsibilities are publicly assigned in .github/CODEOWNERS (https://github.com/spectrayan/spector/blob/main/.github/CODEOWNERS) and GOVERNANCE.md (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#immediate-eligibility-for-committer--reviewer-status)


    足够获得徽章！

    如果任何一个开发者丧失工作能力或丧生，该项目必须能够继续保持最小的中断。特别是，在确认个人无行为能力或死亡的一周内，项目必须能够创建和关闭问题，接受提议的更改和发布软件版本。这可以通过确保其他人有任何必要的密钥，密码和合法权利来继续该项目。运行FLOSS项目的个人可以通过在锁箱中提供密钥，并提供任何所需的合法权利（例如DNS名称）来实现。 (需要网址) [access_continuity]

    Project continuity and credential redundancy are documented in GOVERNANCE.md under Project Continuity & Redundancy (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#32-project-continuity--redundancy). Organization ownership, domain management, and GitHub repository administration are distributed across multiple administrative contacts with backup credentials. Review and merge rights on main are assigned to team aliases in .github/CODEOWNERS (https://github.com/spectrayan/spector/blob/main/.github/CODEOWNERS), and release credentials (GHCR, PyPI, npm, Maven) are managed via organization-level GitHub Actions secrets, ensuring that issue triage, PR merges, and software releases can continue within one week if any individual contributor becomes unavailable.


    足够获得徽章！

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]
    “公交车系数”（又名“卡车因子”）是指最少数量的项目成员，如果突然离开项目（“被公交车撞了”），项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息，请参阅Cosentino等人的评估Git存储库的卡车因子。

    The project maintains a bus factor of 2 or more across its core codebase and governance hierarchy, as documented in ACKNOWLEDGMENTS.md (https://github.com/spectrayan/spector/blob/main/ACKNOWLEDGMENTS.md#open-source-contributors) and GOVERNANCE.md (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#3-the-4-tier-contributor-ladder). Technical knowledge, code review authority, and codebase maintenance are shared between Project Lead Bharat Joshi (@sbharatjoshi) and active committer Timothy Kim (@timothytkim), who has authored merged contributions across kernel documentation, provider architecture, index diagnostics, and observability, alongside functional team aliases in .github/CODEOWNERS (https://github.com/spectrayan/spector/blob/main/.github/CODEOWNERS).


  • 文档


    足够获得徽章！

    该项目必须有一个文档化的路线图，描述项目打算做什么，至少在下一年做什么。 (需要网址) [documentation_roadmap]
    项目可能没有实现路线图，没关系。路线图的目的是帮助潜在的用户和贡献者了解项目的预期方向。它不需要特别详细。

    The project maintains a public 12-month architectural roadmap in ROADMAP.md (https://github.com/spectrayan/spector/blob/main/ROADMAP.md) and docs/roadmap.md (https://github.com/spectrayan/spector/blob/main/docs/roadmap.md). It outlines planned milestones from Q4 2026 through Q3 2027 and JDK 29 LTS (including native Goose extensions, streamable HTTP MCP transport, A2A federated memory sharing, Valhalla value classes, and edge SIMD optimizations). It explicitly details project boundaries and non-goals (what the project will NOT do: it will not become an agent orchestrator framework, will not become a general-purpose SQL database, will not introduce external framework dependencies into the core engine kernel, and will not gate features behind proprietary cloud services).


    足够获得徽章！

    该项目必须包括项目生成的软件的架构（也称为高级别设计）的文档。如果项目不产生软件，请选择“不适用”（N/A）。 (需要网址) [documentation_architecture]
    软件架构解释了程序的基本结构，即程序的主要组件，它们之间的关系以及这些组件和关系的关键属性。

    The project documents its system architecture and high-level design in the Architecture Overview documentation (https://github.com/spectrayan/spector/blob/main/docs/architecture/overview.md) and the public documentation portal (https://spectrayan.github.io/spector/architecture/overview/). The documentation details the complete multi-tier system architecture, including client SDKs, the Synapse transport layer (MCP and Armeria REST/gRPC), the 4-tier cognitive memory engine (Working, Episodic, Semantic, Procedural), Panama FFM off-heap memory-mapped slab layouts, SIMD vector acceleration kernels, and dataflow/threading models. Additional subsystem architecture deep-dives are maintained under docs/architecture/ and in the Architecture Decision Record catalog (https://github.com/spectrayan/spector/blob/main/docs/adr/catalog.md).


    足够获得徽章！

    该项目必须书面记录用户从项目生成的软件的安全性上可以获得和不能指望的内容（其“安全需求”）。 (需要网址) [documentation_security]
    这些是软件意图满足的安全需求。

    The project documents its security requirements and threat model in SECURITY.md under Security Guarantees & Non-Guarantees (https://github.com/spectrayan/spector/blob/main/SECURITY.md#security-guarantees--non-guarantees-security-requirements) and in docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md). Users can expect physical on-disk tenant isolation with zero cross-tenant leakage, AES-256-GCM at-rest encryption for text payloads and WAL, memory safety via Panama FFM bounded arenas, timing-attack-resistant authentication, and continuous vulnerability scanning. Users cannot expect application-layer vector decryption (vector slabs are zero-copy memory mapped for SIMD search and require operator-managed volume/disk encryption), implicit perimeter protection (operators must configure TLS/mTLS or reverse proxies for public exposure), or defense against a compromised host OS/root user.


    足够获得徽章！

    该项目必须为新用户提供“快速启动”指南，以帮助他们快速使用该软件。 (需要网址) [documentation_quick_start]
    这个想法是向用户展示如何入门，使软件完全可以做事情。这对于潜在用户是至关重要的。

    The project provides a dedicated quick start guide titled 'Quick Start — 30 Seconds to First Memory' in docs/getting-started/quickstart.md (https://github.com/spectrayan/spector/blob/main/docs/getting-started/quickstart.md) and on the public documentation portal (https://spectrayan.github.io/spector/getting-started/quickstart/). The guide enables new users to store and recall their first memory within seconds via multiple paths: a zero-install MCP launcher (npx -y @spectrayan/spector mcp), the Python SDK (pip install spector-client), the TypeScript SDK (npm install @spectrayan/spector-client), and a one-command Docker Compose setup. It is also linked directly from the root README (https://github.com/spectrayan/spector/blob/main/README.md#quick-start).


    足够获得徽章！

    项目必须努力使文档与当前版本的项目结果（包括项目生成的软件）保持一致。任何已知的文档缺陷使其不一致必须修正。如果文档基本是最新的，但是错误地包括一些不再是真实的旧信息，那么将其视为缺陷，然后像往常一样进行跟踪和修复。 [documentation_current]
    该文档可以包括有关软件版本之间的差异或更改的信息，与/或链接到旧版本的文档。这个条款的意图在于努力保持文档的一致性，而不是文档必须完美。

    The project actively maintains documentation consistency with the current codebase through automated CI gates and disciplined documentation review. The automated documentation deployment pipeline in .github/workflows/docs.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/docs.yml) and CI suite enforce strict validation (mkdocs build --strict), causing the build to fail if broken links, missing references, or documentation warnings are introduced. In addition, the PR checklist in CONTRIBUTING.md (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#pr-checklist) requires doc updates for any altered interfaces, and documentation defects are tracked and resolved in GitHub Issues (demonstrated in major synchronization overhauls like PR #960 aligning docs with runtime kernel implementations).


    足够获得徽章！

    项目存储代码库首页和/或网站必须在获得成就的48小时内标识并超链接任何成就，包括此最佳实践徽章。 (需要网址) [documentation_achievements]
    一个成就是项目致力于满足的任何外部条款，包括徽章。该信息不需要在项目网站首页上。使用GitHub的项目可以通过将其添加到README文件中，将成果放在存储代码库首页。

    The project prominently displays and hyperlinks all project achievements and badges on the repository front page in README.md (https://github.com/spectrayan/spector/blob/main/README.md#L14-L23), including the OpenSSF Best Practices badge (hyperlinked to https://www.bestpractices.dev/projects/14829), CI build status, PyPI package releases, npm package releases, Docker GHCR images, documentation status, and contributor recognition. Maintainers update and display recognized badges immediately upon attainment.


  • 无障碍和国际化


    足够获得徽章！

    该项目（项目网站和项目成果）都应遵循无障碍最佳做法，使残疾人仍然可以参与项目，并在合理的情况下使用项目成果。 [accessibility_best_practices]
    对于Web应用程序，请参阅 Web 内容无障碍指导 (WCAG 2.0，英文) 以及其支持文档 理解 WCAG 2.0（英文）；或者 W3C 无障碍信息（英文）. 图形界面（GUI）应用考虑使用环境特定的无障碍指导（例如 Gnome, KDE, XFCE, Android, iOS, Mac, 以及 Windows). 一些TUI应用 (例如，`ncurses` 程序) 可以做一些特定的工作，增强可访问性（例如，`alpine` 的 `force-arrow-cursor` 设置）。多数命令行应用没有特别的无障碍设置。本条款经常是不涉及（N/A），例如，对于组件库。以下是一些要采取的行动或需要考虑的问题的例子：
    • 提供非文字内容的文字替代，以便于转换为其他需要的格式，如大字体、盲文、语音、符号或者简单文字（ WCAG 2.0 指导 1.1 （英文）)
    • 颜色不被用作传达信息，指示动作，提示响应或区分视觉元素的唯一视觉方式。 ( WCAG 2.0 指导 1.4.1（英文）)
    • 文本和文字图像的视觉呈现对比度至少为4.5：1，除了大文本，次要文本和标识符之外。 ( WCAG 2.0 指导 1.4.3（英文）)
    • 使用键盘可访问所有功能 (WCAG 指导 2.1)
    • 图形界面应用（GUI）或者Web应用在目标平台上，应该至少使用一种屏幕阅读器测试（例如，NVDA；Jaws；Windows上的WindowEyes；Mac & iOS上的VoiceOver；Linux/BSD上的Orca；Android上的TalkBack）。TUI程序可以减少过度渲染以防止屏幕阅读器的冗余读取。

    The project follows accessibility best practices across its documentation and interfaces. The public documentation portal (https://spectrayan.github.io/spector/) is built using Material for MkDocs, configured in mkdocs.yml (https://github.com/spectrayan/spector/blob/main/mkdocs.yml#L8-L31) to adhere to WCAG 2.1 Level AA accessibility standards. It features semantic HTML5 navigation, accessible keyboard controls, high-contrast dark and light mode color palette toggles, screen-reader-friendly layout hierarchies, and descriptive alt text on all imagery. Furthermore, CLI and server components support plain-text and structured JSON outputs to remain fully accessible to terminal screen readers.


    足够获得徽章！

    该项目产生的软件应该被国际化，以便为目标受众的文化，地区或语言进行简单的本地化。如果国际化（i18n）不适用（例如，该软件不会生成针对最终用户的文本，并且不排序可读文本），请选择“不适用”（N/A）。 [internationalization]
    本地化“是指适应产品，应用或文档内容以满足特定目标市场（语言环境）的语言，文化和其他要求。国际化是“设计和开发产品，应用或文档内容，使不同文化，地区或语言的目标受众更容易本地化”。 （请参阅 W3C的“本地化与国际化”）。软件只需通过国际化即可达到此标准。不需要另一种特定语言的本地化，因为一旦软件已被国际化，其他人就可以从事本地化。

    Internationalization does not apply to the core software produced by the project. Spector is a backend cognitive memory engine, native off-heap storage kernel, and Model Context Protocol (MCP) server for autonomous AI agents, as described in docs/architecture/overview.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/overview.md). It processes vector embeddings, association graphs, and structured JSON machine-to-machine payloads, and does not generate human-facing user interface text or locale-dependent strings. All text ingestion and payload handling natively support full Unicode/UTF-8 character encodings.


  • 其他


    足够获得徽章！

    如果项目站点（网站，存储库和下载URL）存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法将密码存储为具有每用户盐值的迭代散列（例如，PBKDF2，Bcrypt或Scrypt）。如果项目站点不存储密码，请选择“不适用”（N/A）。 [sites_password_security]
    请注意，使用 GitHub 符合此条款。此条款仅适用于用于外部用户认证到项目站点的密码。如果项目站点必须登录到其他站点，则可能需要为此目的存储密码（因为使用像Bcrypt这样的算法会使这些密码无效）。本条款将 crypto_password_storage 条款应用于项目站点，类似于sites_https条款。

    The project sites do not store passwords for the authentication of external users. The project repository and download artifacts are hosted on GitHub (https://github.com/spectrayan/spector), and the project documentation website is statically hosted via GitHub Pages (https://spectrayan.github.io/spector/). The project sites maintain no independent user authentication database or credential storage, relying entirely on the host platform's infrastructure.


 变更控制 1/1 ●

  • 之前的版本


    足够获得徽章！

    该项目必须维护最常用的旧版本的产品或提供较新版本的升级路径。如果升级路径很困难，项目必须记录如何执行升级（例如，给出更改的接口描述和详细的建议步骤以帮助升级）。 [maintenance_or_update]

    The project maintains active versions and provides transparent upgrade and migration paths documented in CHANGELOG.md (https://github.com/spectrayan/spector/blob/main/CHANGELOG.md) adhering to Semantic Versioning (SemVer 2.0.0) and Keep a Changelog standards. Each release notes interface changes, configuration deprecations, and backward-compatible migration chains. Supported active release streams are explicitly defined in SECURITY.md under Supported Versions (https://github.com/spectrayan/spector/blob/main/SECURITY.md#supported-versions). In addition, storage bundle headers enforce binary schema format version validation to guarantee on-disk data integrity across version upgrades.


 报告 3/3 ●

  • 错误报告流程


    足够获得徽章！

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

    The project uses GitHub Issues to track all bug reports, feature requests, and architectural tasks, with dedicated templates for bug reports, feature requests, and performance investigations. https://github.com/spectrayan/spector/issues


  • 漏洞报告流程


    足够获得徽章！

    除了要求匿名的报告者外，该项目必须对过去12个月内解决的所有漏洞报告的报告者表示感谢。如果过去12个月没有修复漏洞，请选择“不适用”（N/A）。 (需要网址) [vulnerability_report_credit]

    No vulnerability reports were received or resolved in the last 12 months. The project's documented policy in SECURITY.md under Coordinated Disclosure Process (https://github.com/spectrayan/spector/blob/main/SECURITY.md#coordinated-disclosure-process) explicitly mandates that reporters are publicly credited in published GitHub Security Advisories (GHSAs) and release notes unless they explicitly request anonymity, alongside permanent recognition in ACKNOWLEDGMENTS.md (https://github.com/spectrayan/spector/blob/main/ACKNOWLEDGMENTS.md).


    足够获得徽章！

    该项目必须有一个书面的流程来响应漏洞报告。 (需要网址) [vulnerability_response_process]
    这与security_report_process有很强的相关性，它需要有一个书面的流程来报告漏洞。它还涉及到spam_report_response，它需要在一定时间内响应漏洞报告。

    The project maintains a formal, step-by-step vulnerability response process documented in SECURITY.md under Coordinated Disclosure Process and Response Timeline & Severity SLAs (https://github.com/spectrayan/spector/blob/main/SECURITY.md#coordinated-disclosure-process). The policy outlines the complete workflow: initial receipt acknowledgment within 24 to 48 hours, private reproduction and triage in a secure fork with CVE assignment, collaborative patch preparation, and coordinated release publication alongside a GitHub Security Advisory (GHSA). Target fix windows are codified by CVSS v3.1 severity tiers (7 days for Critical, 14 days for High, 30 days for Medium).


 质量 19/19 ●

  • 编码标准


    足够获得徽章！

    该项目必须确定其使用的主要语言的具体编码风格指南，并要求贡献一般情况下符合此要求。 (需要网址) [coding_standards]
    在大多数情况下，这是通过参考一些现有的风格指南来完成的，可能列出差异。这些风格指南可以包括提高可读性的方法和减少缺陷可能性（包括漏洞）的方法。许多编程语言有一个或多个广泛使用的风格指南。样式指南的示例包括 Google风格指南（英文）和 SEI CERT编码标准（英文）。

    The project defines and enforces language-specific coding standards in CONTRIBUTING.md under Coding Standards (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#coding-standards). For Java (the primary engine language), it mandates Java 25 modern idioms (records, sealed classes, pattern matching), Project Panama FFM bounded arena lifecycles, Vector API conventions (FloatVector.SPECIES_PREFERRED), zero-allocation hot paths, and comprehensive Javadoc on all public interfaces. For TypeScript and Python client SDKs, it requires strict typing, sanitization standards, and standard package layouts. Compliance is required for all contributions and enforced via the PR checklist in .github/pull_request_template.md (https://github.com/spectrayan/spector/blob/main/.github/pull_request_template.md) and automated CI build gates.


    足够获得徽章！

    如果至少有一个FLOSS工具可以应用于所选择的语言，项目必须自动执行其选定的编码风格。 [coding_standards_enforced]
    这可以使用静态分析工具和/或通过代码重新格式化强制代码实现。在许多情况下，工具配置包含在项目的存储库中（因为不同的项目可能会选择不同的配置）。项目可以允许风格例外（通常会）；在发生例外的情况下（应该很少），它们必须在其位置的代码中记录在案，以便可以对这些例外进行检视，并使工具能够在将来自动处理它们。这些工具的例子包括ESLint（JavaScript）和Rubocop（Ruby）。

    The project automatically enforces coding style and source standards in its CI pipeline and build lifecycle using automated FLOSS tooling. License headers and file formatting are automatically verified during the build via the license-maven-plugin, failing compilation and CI runs if any source file violates the style template, as documented in CONTRIBUTING.md (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#license-headers). Architectural and structural code styles are automatically enforced via ArchUnit (com.tngtech.archunit) during test runs, and static code quality/idiom rules are enforced across Java, TypeScript, and Python via automated GitHub CodeQL analysis on every pull request (.github/workflows/codeql.yml: https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml).


  • 可工作的构建系统


    足够获得徽章！

    本地二进制文件的构建系统必须遵守传递给它们的相关编译器和链接器（环境）变量（例如CC，CFLAGS，CXX，CXXFLAGS和LDFLAGS），并将它们传递给编译器和链接器。构建系统可以使用附加标志来扩展它们，但不能简单地用自己的替换提供的值。如果没有生成本地二进制文件，请选择“不适用”（N/A）。 [build_standard_variables]
    应该很容易启用特殊的构建功能，如地址消毒剂（Address Sanitizer，ASAN），或符合发布加固最佳实践（例如，通过轻松打开编译器标志来实现）。

    The project does not build or compile native binaries (such as C/C++ ELF executables or shared libraries). The build system is Apache Maven (pom.xml: https://github.com/spectrayan/spector/blob/main/pom.xml), producing pure JVM bytecode and JAR artifacts for OpenJDK 25, alongside npm and pip packages for TypeScript and Python SDKs. Native memory and SIMD hardware acceleration are accessed directly within the JVM using Java 25 Project Panama Foreign Function & Memory (FFM) and the Vector API without invoking native C/C++ compilers or linkers.


    足够获得徽章！

    构建和安装系统在在相关标志中要求时，应该保留调试信息（例如，“install -s”未被使用）。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 [build_preserve_debug]
    例如，如果使用这些语言，则应该设置CFLAGS（C）或CXXFLAGS（C ++）创建相关的调试信息，并且在安装过程中不应该剥离它们。支持和分析时，需要调试信息，也可用于测量编译二进制文件中加固特性的存在。

    The build and packaging system preserves full debugging information across all compiled artifacts. The Apache Maven compiler configuration in pom.xml (https://github.com/spectrayan/spector/blob/main/pom.xml#L731-L746) preserves all javac debugging symbols (line number tables, source file attributes, and local variable tables) in generated class files and shaded JARs. No symbol-stripping tools or unstripped binary flags are applied during compilation or installation, allowing complete stack traces, line-number mapping, and interactive debugging in production and developer environments.


    足够获得徽章！

    如果子目录中存在交叉依赖关系，则由项目生成的软件的构建系统必须不能递归地构建子目录。如果没有构建或安装系统（例如典型的JavaScript库），请选择“不适用”（N/A）。 [build_non_recursive]
    项目构建系统的内部依赖关系信息需要准确，否则，对项目的更改可能无法正确构建。不正确的构建可能会导致缺陷（包括漏洞）。大型构建系统中的常见错误是使用“递归构建”或“递归生成”，即包含源文件的子目录的层次结构，其中每个子目录都是独立构建的。除非每个子目录完全独立，否则这是一个错误，因为依赖关系信息不正确。

    The project uses Apache Maven's multi-module reactor architecture defined in the root pom.xml (https://github.com/spectrayan/spector/blob/main/pom.xml#L54-L100) rather than recursive make or isolated subdirectory build scripts. Maven analyzes all inter-module dependencies globally to construct a single topological Directed Acyclic Graph (DAG) before compilation starts. Modules are compiled in strict dependency order, circular dependencies are automatically detected and forbidden, and cross-module artifacts are resolved deterministically across the reactor.


    足够获得徽章！

    该项目必须能够重复从源代码文件生成的过程，并获得完全相同的比特位结果。如果没有发生构建（例如，直接使用源代码而不是编译使用的脚本语言），请选择“不适用”（N/A）。 [build_repeatable]
    GCC和clang用户可能会发现-frandom-seed选项有用；在某些情况下，这可以通过强制某种排序来解决。更多建议可以在可重复构建（英文）站点找到。

    The project achieves bit-for-bit reproducible builds using Apache Maven's standardized Reproducible Builds mechanism configured in pom.xml (https://github.com/spectrayan/spector/blob/main/pom.xml#L190). By defining a fixed <project.build.outputTimestamp> (2024-01-01T00:00:00Z), Maven plugins (maven-jar-plugin, maven-shade-plugin, flatten-maven-plugin) normalize zip entry timestamps, file ordering, and manifest metadata, ensuring identical cryptographic byte output from repeated builds on OpenJDK 25.


  • 安装系统


    足够获得徽章！

    该项目必须提供一种使用常用惯例轻松安装和卸载由项目生成的软件的方法。 [installation_common]
    示例包括使用软件包管理器（在系统或语言级别），“make install/uninstall”（支持DESTDIR），标准格式的容器或标准格式的虚拟机映像。安装和卸载过程（例如，打包）可以由第三方FLOSS软件实现。

    The project provides standard, conventional installation and uninstallation methods across platforms, documented in docs/getting-started/installation.md (https://github.com/spectrayan/spector/blob/main/docs/getting-started/installation.md) and the root README (https://github.com/spectrayan/spector/blob/main/README.md#quick-start). Package managers support standard life-cycle commands: Python SDK via pip install / pip uninstall spector-client, TypeScript SDK via npm install / npm uninstall @spectrayan/spector-client, Homebrew via brew install / brew uninstall spector, Scoop for Windows via scoop install / scoop uninstall spector, Docker Compose via docker compose up -d / docker compose down -v, and standalone binary removal via rm -rf ~/.spector.


    足够获得徽章！

    最终用户的安装系统必须遵守用于在安装时选择构建工件写入位置的标准约定。例如，如果在POSIX系统上安装文件，它必须遵守DESTDIR环境变量。如果没有安装系统或没有标准惯例，请选择“不适用”（N/A）。 [installation_standard_variables]

    The installation system for end-users honors standard directory selection conventions across platforms, documented in scripts/install.sh (https://github.com/spectrayan/spector/blob/main/scripts/install.sh#L16-L45) and docs/getting-started/installation.md (https://github.com/spectrayan/spector/blob/main/docs/getting-started/installation.md). On POSIX systems, the standalone installer honors the standard DESTDIR and SPECTOR_HOME environment variables as well as the --install-dir <path> CLI flag to redirect all binary and JAR writes. Similarly, client package installations honor standard package-manager destination conventions: pip honors --target and --prefix, and npm honors --prefix.


    足够获得徽章！

    该项目必须为潜在开发人员提供一种快速安装所有项目成果和支持环境所必需的环境，包括测试套件和测试环境。必须通过常规惯例执行。 [installation_development_quick]
    可以使用生成的容器和/或安装脚本来实现。外部依赖关系一般通过调用系统和/或语言包管理器（根据 external_dependencies 条款）进行安装。

    The project provides standard, rapid developer environment setup instructions in CONTRIBUTING.md under Development Setup (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#development-setup) and AGENTS.md (https://github.com/spectrayan/spector/blob/main/AGENTS.md#prerequisites). Potential developers can clone the repository and automatically download all reactor dependencies, build artifacts, test libraries (JUnit 5, AssertJ, jqwik), and execution environments using standard Apache Maven conventions via mvn clean compile and mvn test. No non-standard tooling, proprietary compilers, or external database services are required to develop or run tests locally.


  • 外部维护的组件


    足够获得徽章！

    项目必须以计算机可处理的方式列出外部依赖关系。 (需要网址) [external_dependencies]
    通常这是使用包管理器和/或构建系统的约定完成的。请注意，这有助于实施 installation_development_quick 。

    The project declares all external dependencies in standardized, computer-processable formats across all modules. Java dependencies are centrally managed via Apache Maven's machine-readable XML format in root pom.xml under dependencyManagement (https://github.com/spectrayan/spector/blob/main/pom.xml#L200-L725) and spectrayan-bom, complemented by the cyclonedx-maven-plugin (https://github.com/spectrayan/spector/blob/main/pom.xml#L1016-L1032) which generates standardized machine-readable CycloneDX 1.6 Software Bill of Materials (SBOMs) in XML and JSON. Client packages declare dependencies in standard package manifests (package.json for TypeScript and pyproject.toml for Python), and dependencies are automatically parsed and monitored by GitHub Dependabot (.github/dependabot.yml).


    足够获得徽章！

    项目必须监视或定期检查其外部依赖（包括便利副本）以检测已知的漏洞，并修复可利用的漏洞或将其验证为不可利用的漏洞。 [dependency_monitoring]
    这可以使用源分析器/依赖项检查工具/软件组成分析工具（例如OWASP的Dependency-Check ， Sonatype的Nexus Auditor ， Synopsys的Black Duck软件组成分析和Bundler-audit（针对Ruby））来完成。一些程序包管理器包括执行此操作的机制。如果无法利用组件的漏洞，这是可以接受的，但是这种分析是困难的，有时简单地更新或修复零件就更容易。

    The project continuously monitors and updates external dependencies for known security vulnerabilities using automated tooling configured in .github/dependabot.yml (https://github.com/spectrayan/spector/blob/main/.github/dependabot.yml) and container vulnerability scanning in .github/workflows/container-security.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/container-security.yml). Automated scans run weekly across all package ecosystems (Maven, npm, Docker base images, and GitHub Actions). Flagged vulnerabilities are actively remediated (demonstrated in issue #880 resolving all open dependency alerts and recent container base image digest pinning), resulting in 0 open Dependabot alerts across the repository.


    足够获得徽章！

    该项目必须满足下述情况之一：
    1. 可以轻松识别和更新重用的外部维护组件; 或
    2. 使用系统或编程语言提供的标准组件。
    这样，如果在重用的组件中发现了一个漏洞，将容易更新该组件。 [updateable_reused_components]
    符合这一条款的典型方法是使用系统和编程语言的包管理系统。许多FLOSS程序与“便利库”一起分发，这些库是标准库的本地副本（可能是分支）。一般没问题。但是，如果程序*必须*使用这些本地（分支）副本，则“标准”库的安全更新将使这些附加副本仍然易受攻击。这对于基于云的系统尤其是一个问题；如果云提供商更新他们的“标准”库，但程序不会使用它们，那么这些更新实际上不会有帮助。参见，例如，“Chromium：为什么它不在Fedora中作为适当的包”（Tom Callaway）。

    The project satisfies both criteria. First, as documented in AGENTS.md under Architecture Conventions (https://github.com/spectrayan/spector/blob/main/AGENTS.md#architecture-conventions-for-ai-agents), the core engine kernel (spector-core, spector-cpu, spector-kernel, spector-memory, and spector-index) has an invariant of zero third-party dependencies, relying purely on standard OpenJDK 25 platform APIs (java.lang.foreign, jdk.incubator.vector, java.lang.ScopedValue). Second, all external dependencies used in gateway and transport layers are centrally managed in root pom.xml under properties and dependencyManagement (https://github.com/spectrayan/spector/blob/main/pom.xml#L110-L185), enabling single-variable version bumps across the entire multi-module reactor, and automated via GitHub Dependabot (.github/dependabot.yml).


    足够获得徽章！

    该项目应避免使用已弃用或过时的功能和API，如果FLOSS替代品在其使用的技术集合（“技术堆栈”）中以及项目支持的大多数用户中可用（以便用户可以随时访问该替代品）。 [interfaces_current]

    The project actively avoids deprecated and obsolete APIs by targeting modern toolchains (Java 25, Angular 22, Python 3.11+). As documented in CONTRIBUTING.md under Coding Standards (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#coding-standards), the Java codebase strictly utilizes modern replacement standards: Project Panama FFM (java.lang.foreign) replacing obsolete sun.misc.Unsafe and JNI, Virtual Threads and ScopedValues replacing legacy ThreadLocal concurrency patterns, and modern records/sealed classes replacing verbose legacy POJOs. Compiler warnings and CodeQL static analysis workflows in .github/workflows/codeql.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml) continuously monitor for and eliminate deprecated API invocations.


  • 自动测试套件


    足够获得徽章！

    必须将自动测试套件应用于至少一个分支的共享代码库的每次签入。该测试套件必须生成关于测试成功或失败的报告。 [automated_integration_testing]
    这个要求可以被视为test_continuous_integration的一个子集，但是仅仅是测试，而不需要持续集成。

    Automated test suites are executed on every check-in and pull request targeting the main branch via GitHub Actions in .github/workflows/ci.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/ci.yml#L110-L135). The workflow runs unit, property, and benchmark test suites across multiple hardware architectures (x86_64 and aarch64), generates Surefire XML test reports archived as build artifacts (actions/upload-artifact under **/target/surefire-reports/*.xml), aggregates JaCoCo code coverage reports, and outputs clear pass/fail check statuses visible directly on GitHub Actions (https://github.com/spectrayan/spector/actions).


    足够获得徽章！

    该项目必须为过去六个月内修复的至少50％的错误，在自动化测试套件中添加回归测试。 [regression_tests_added50]

    The project strictly requires and adds automated regression tests for bug fixes, far exceeding the 50% threshold. The project policy documented in CONTRIBUTING.md under Testing Expectations (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#testing-expectations) mandates unit tests for all bug fixes. Recent bug fixes demonstrate 100% regression test coverage: PR #984 (https://github.com/spectrayan/spector/pull/984) fixing silent Hebbian edge drops added dedicated regression tests (ForgetAndVacuumHonestyTest.java, HebbianGraphMaxDegreeMismatchTest.java), PR #982 (https://github.com/spectrayan/spector/pull/982) fixing batch bundle fabrication added SpectorBatchUnimplementedStepsTest.java, and PR #991 added distance precision regression suites. All regression tests run automatically in CI on every push.


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％语句覆盖率。 [test_statement_coverage80]
    许多FLOSS工具可用于度量测试覆盖范围，包括gcov / lcov，Blanket.js，Istanbul和JCov。请注意，满足这个条款并不能保证测试套件是完备的，而不满足该条款则意味着测试套件很差。

    The project measures and enforces statement and branch coverage using the open-source JaCoCo tool (jacoco-maven-plugin), configured in the root pom.xml (https://github.com/spectrayan/spector/blob/main/pom.xml#L1046-L1048) with an 80% coverage target baseline. The automated CI pipeline in .github/workflows/ci.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/ci.yml#L134-L142) runs jacoco:report-aggregate on every check-in to measure statement execution across unit, property, and integration tests, ensuring that core memory layouts, decay algorithms, and scoring kernels maintain 80%+ statement coverage.


  • 新功能测试


    足够获得徽章！

    该项目必须具有正式的书面策略，一旦添加了主要的新功能，新功能的测试必须被添加到自动测试套件中。 [test_policy_mandated]

    The project maintains a formal written testing policy documented in CONTRIBUTING.md under Testing Expectations (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#testing-expectations). The policy explicitly mandates automated tests for all new functionality across defined categories: unit tests are required for all new classes and bug fixes, jqwik property tests are required for new indexing algorithms and binary codecs, and integration tests are required for all end-to-end pathways and gateways. This formal requirement is enforced on every change proposal via mandatory checklist items in the pull request template (https://github.com/spectrayan/spector/blob/main/.github/pull_request_template.md).


    足够获得徽章！

    该项目必须在其关于变更建议的书面指导中包括要为主要新功能添加测试的策略。 [tests_documented_added]
    但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。

    The policy on adding tests is explicitly documented in the instructions for change proposals in CONTRIBUTING.md under 'Pull Request Process' and 'PR Checklist', requiring contributors to verify that 'Tests added/updated covering changed behavior and edge cases (mvn test)'. This is also enforced in the GitHub Pull Request submission template (.github/pull_request_template.md). https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#pr-checklist


  • 警告标志


    足够获得徽章！

    在实际允许时，项目必须最大限度地严格修复项目生成的软件中的警告。 [warnings_strict]
    某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。

    The project applies strict quality gates: CodeQL runs with the 'security-extended' query suite, documentation builds enforce 'mkdocs build --strict' (failing CI on any warning or broken link), and Maven license checks strictly fail the build on any compliance warning. https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml


 安全 13/13 ●

  • 安全开发知识


    足够获得徽章！

    该项目必须实施安全设计原则（来自“know_secure_design”）（如适用）。如果项目不生产软件，请选择“不适用”（N/A）。 [implement_secure_design]
    例如，项目结果应该具有故障安全默认值（默认情况下，访问决策应该拒绝，默认情况下项目的安装应该是安全的），也应该有完全的仲裁（每一个可能被限制的访问权限必须被检查，不可绕过）。请注意，在某些情况下，原则会发生冲突，在这种情况下必须做出选择（例如，许多机制使事情更复杂，违反“机制经济”/“保持最简化”的原则）。

    The project systematically implements core secure design principles across its architecture, documented in SECURITY.md under Security Guarantees & Non-Guarantees (https://github.com/spectrayan/spector/blob/main/SECURITY.md#security-guarantees--non-guarantees-security-requirements) and in docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md). Principles implemented include: (1) Defense in Depth: combining physical on-disk filesystem isolation, AES-256-GCM at-rest encryption, 128-bit Bloom tag gating, and recall visit budgets; (2) Least Privilege: scoped API keys and tenant namespaces that restrict agent access strictly to authorized engrams; (3) Fail-Closed Defaults: implemented in SecurityConfig.java via FailClosedAuthenticationEntryPoint and strict binary bundle magic/CRC32C validation that halts corrupt reads; (4) Complete Mediation: all REST and MCP memory access passes through authentication and authorization filters; and (5) Memory Safety by Design: using Java 25 Panama FFM bounded arenas to eliminate buffer overflows and use-after-free corruption.


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

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

    足够获得徽章！

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

    The default security mechanisms avoid algorithms or modes with known weaknesses. Hashing exclusively uses SHA-256 (HMAC-SHA256) rather than SHA-1, and symmetric encryption strictly uses AES-256 in GCM (AEAD) mode rather than CBC or unauthenticated modes.


    足够获得徽章！

    该项目应该支持多种加密算法，如果一个被破解，用户可以快速切换。普通的对称密钥算法包括AES，Twofish和Serpent。通用密码散列算法的选择包括SHA-2（包括SHA-224，SHA-256，SHA-384和SHA-512）和SHA-3。 [crypto_algorithm_agility]

    The project achieves cryptographic agility by delegating cryptographic operations to the standard OpenJDK Java Cryptography Architecture (JCA) and TLS provider abstractions, as documented in docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md). By leveraging JCA SPIs (javax.crypto.Cipher, javax.crypto.Mac, and java.security.MessageDigest), the system supports multiple standardized cryptographic algorithms: for hashing and blind indexing, it accommodates alternatives across the SHA-2 family (SHA-256, SHA-384, SHA-512) and SHA-3; for transport security, it negotiates multiple modern AEAD ciphers (AES-256-GCM, AES-128-GCM, and ChaCha20-Poly1305); and symmetric encryption can be configured to alternative approved ciphers without rewriting storage engine code.


    足够获得徽章！

    该项目必须支持在与其他信息（如配置文件，数据库和日志）分离的文件中存储身份验证凭据（如密码和动态令牌）以及私有加密密钥，并允许用户更新和替换它们，而无需重新编译代码。如果项目从不处理身份验证凭据和私有加密密钥，请选择“不适用”（N/A）。 [crypto_credential_agility]

    The project supports storing authentication credentials, tokens, and cryptographic keys in isolated external secret files separate from application code, database stores, and configuration files, documented in deploy/docker/entrypoint.sh (https://github.com/spectrayan/spector/blob/main/deploy/docker/entrypoint.sh#L12-L36) and docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md). In Docker and Kubernetes environments, API keys, JWT secrets, and TLS private key certificates are mounted from external secret files (e.g., /run/secrets/ or Kubernetes Secret volumes) or injected via environment variables at runtime. Operators can rotate, update, or replace credentials and keys dynamically without recompiling any code or modifying application images.


    足够获得徽章！

    该项目产生的软件应该支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本和SSHv1等不安全协议将被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。 [crypto_used_network]

    The software supports secure network communication protocols across all network endpoints, using TLS 1.2 and TLS 1.3 for HTTPS REST APIs, gRPC services, and inter-node cluster replication, documented in docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md) and synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java). Insecure and legacy protocols (such as FTP, Telnet, SSLv2, SSLv3, and TLS 1.0/1.1) are unsupported and disabled by default by the OpenJDK 25 security provider and Netty transport layer. For remote cluster and gateway deployments, mutual TLS (mTLS) and HTTPS are enforced, while local agent communications default to secure, memory-isolated stdio process pipes.


    足够获得徽章！

    项目生成的软件（如果支持或使用TLS）应该至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_tls12]

    The software natively supports TLS 1.2 and modern TLS 1.3 for all encrypted network communications, documented in ReplicationTlsFactory.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java#L46-L50) and docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md). Cluster node replication explicitly enforces TLS 1.3 contexts (public static final String TLS_V1_3 = "TLSv1.3"), and gateway REST/gRPC endpoints support both TLS 1.2 and TLS 1.3 through the OpenJDK 25 and Netty SSL engines. All legacy protocols prior to TLS 1.2 (SSLv2, SSLv3, TLS 1.0, TLS 1.1) are permanently disabled at the runtime platform level.


    足够获得徽章！

    由项目生成的软件必须，如果它支持TLS，则在使用TLS（包括子资源）时默认执行TLS证书验证。如果软件不使用TLS，请选择“不适用”（N / A）。 [crypto_certificate_verification]
    请注意，不正确的TLS证书验证是一个常见的错误。有关详细信息，请参阅“世界上最危险的代码：在非浏览器软件中验证SSL证书“，Martin Georgiev等人和 “你信任这个应用程序吗？”作者Michael Catanzaro

    The software performs strict X.509 TLS certificate verification by default on all TLS connections. For inter-node cluster replication, ReplicationTlsFactory.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java#L101-L125) configures TrustManagerFactory instances backed by verified truststores and mandates mutual certificate authentication (setNeedClientAuth(true)). For outbound HTTP/REST connections (such as provider APIs, remote gateways, and SDK clients), the underlying OpenJDK and Netty network clients enforce standard CA certificate chain validation, expiration checks, and SNI hostname verification by default, rejecting untrusted or invalid certificates unless explicitly overridden in development environments.


    足够获得徽章！

    项目生成的软件（如果支持TLS）必须在发送具有私有信息（如安全Cookie）的HTTP头之前执行证书验证。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_verification_private]

    The software strictly enforces full TLS certificate validation before transmitting any HTTP request lines or sensitive headers (such as X-API-Key or Authorization tokens). In ReplicationTlsFactory.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java#L132-L140), client TLS sockets explicitly enable endpoint identification (sslParams.setEndpointIdentificationAlgorithm("HTTPS")), mandating full certificate chain and hostname verification during the TLS handshake. Standard underlying HTTP clients (Java HttpClient, Netty SSL, Python requests) ensure that if a certificate check fails, the TLS handshake is aborted immediately and no application-layer HTTP headers or payload bytes are ever sent over the network.


  • 安全发布


    足够获得徽章！

    该项目必须加密签名旨在广泛使用的项目结果的发布，并且必须有一个书面流程，向用户解释如何获取公共签名密钥并验证签名。这些签名的私钥不得在项目网站上直接向公众发布。如果发行版本不适用于广泛使用，请选择“不适用”（N/A）。 [signed_releases]
    项目结果包括源代码和适用的任何生成的可交付成果（例如，可执行文件，包和容器）。生成的交付项可以单独签名源代码。可以用签名的git标签实现（使用加密数字签名）。项目可以从git类似的工具分别提供生成的结果，但在这些情况下，单独的结果必须单独签署。

    The project cryptographically signs official release artifacts using GPG via the maven-gpg-plugin in the automated release pipeline in .github/workflows/release-maven.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/release-maven.yml#L54-L75). Private signing keys are stored securely in encrypted CI secrets and are never located on public distribution sites or servers. Cryptographic signatures (.asc) and SHA-256 checksums are published alongside each release on GitHub Releases (https://github.com/spectrayan/spector/releases) and Maven Central, where users can verify artifact integrity and authenticity against the project's public signing key using gpg --verify <artifact>.asc <artifact>.


    足够获得徽章！

    建议在版本控制系统中，每个重要版本标签（作为主要版本的一部分的标签，次要版本或修复公开提到的漏洞）都按照signed_releases中的要求进行加密签名，并可验证。 [version_tags_signed]

    The project cryptographically signs release version tags in the Git repository using GPG (git tag -s), verifiable directly on GitHub Releases and Tags (https://github.com/spectrayan/spector/tags) with GitHub's verified signature badge. Tagger public keys are registered with the GitHub organization, and users and automated CI pipelines can verify the cryptographic integrity of any release tag locally using the standard command git tag -v <tag-name> or git verify-tag <tag-name>.


  • 其他安全问题


    足够获得徽章！

    项目结果必须检查来自潜在不受信任来源的所有输入，以确保它们有效（ *白名单*），如果对数据有限制，则拒绝无效输入。 [input_validation]
    请注意，将输入与“不良格式”（*黑名单*）的列表进行比较通常是不够的，因为攻击者通常可以绕过黑名单。例如，数字被转换成内部格式，然后检查它们是否在最小和最大（包括）之间，并且检查文本字符串以确保它们是有效的文本模式（例如，有效的UTF-8，长度，语法等）。一些数据可能需要是“任何东西”（例如，文件上传器），但这些数据通常是罕见的。

    The software validates all inputs from untrusted sources against strict allowlists and rejects non-compliant requests before processing. All Model Context Protocol (MCP) and REST gateway endpoints enforce declarative JSON schema and DTO type allowlists documented in the OpenAPI specification (https://github.com/spectrayan/spector/blob/main/docs/openapi.yaml), rejecting invalid numeric ranges, unexpected types, and malformed structures. Tenant and namespace names are validated against strict alphanumeric allowlists to eliminate path traversal risks. Furthermore, binary on-disk bundles and data imports enforce format version allowlists and CRC32C checksum integrity gates, rejecting unknown or mutated structures immediately (tested in BundleVersionGateTest and documented in SECURITY.md: https://github.com/spectrayan/spector/blob/main/SECURITY.md#security-guarantees--non-guarantees-security-requirements).


    足够获得徽章！

    加固机制应该用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 [hardening]
    加固机制可能包括HTTP头，如内容安全策略（CSP），用于减轻攻击的编译器标志（如-fstack-protector）或用以消除未定义行为的编译器标志。对于此条款的目的，最小权限不被认为是一种加固机制（最少权限是重要的，但是另有条款）。

    The project applies runtime, memory, and architectural hardening mechanisms to prevent defects from translating into security vulnerabilities, documented in SECURITY.md under Security Guarantees & Non-Guarantees (https://github.com/spectrayan/spector/blob/main/SECURITY.md#security-guarantees--non-guarantees-security-requirements) and docs/architecture/overview.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/overview.md). Off-heap native memory accesses are hardened using OpenJDK 25 Project Panama bounded Arena lifecycles that enforce spatial and temporal boundary checks at the JVM level, preventing memory corruption, use-after-free, and buffer overflows. Authentication endpoints enforce constant-time string comparisons to eliminate timing side-channels, binary headers enforce hardware CRC32C integrity checksums and strict format-version gates, and container images run under restricted non-root users with pinned base image digests.


    足够获得徽章！

    该项目必须提供一个保证案例，证明其满足安全要求。保证案例必须包括：对威胁模型的描述，明确确定信任边界，确定设计原则得到适用，以及常见安全弱点已经被消减。 (需要网址) [assurance_case]
    一个保证案例是“一个文献记录的证据体系，提供了一个有说服力和有效的论据，指出一组关于系统属性的关键权利要求在给定环境中给定应用程序是充分合理的”（使用结构化保证案例模型的软件保证，Thomas Rhodes等人，NIST机构间报告7608）。信任边界是数据或执行改变其信任级别的边界，例如，典型Web应用程序中的服务器边界。常见做法是列出安全设计原则（例如Saltzer和Schroeer）和常见的实施安全漏洞（例如OWASP前10名或CWE / SANS前25名），并显示每个方案如何抵御。 BadgeApp保证案例可能是一个有用的例子。本条款与documentation_security，documentation_architecture和implement_secure_design等条款有关。

    The project publishes a formal Security Assurance Case and Threat Model in docs/architecture/security-assurance.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/security-assurance.md), linked from SECURITY.md (https://github.com/spectrayan/spector/blob/main/SECURITY.md). The assurance case explicitly details: (1) a comprehensive threat model defining five adversary profiles (multi-tenant cross-talk, network MitM, cold-disk data exfiltration, query DoS, and binary payload tampering); (2) five clearly delineated trust boundaries (network-to-gateway, agent-to-MCP, tenant-to-tenant, JVM-to-native off-heap, and host storage); (3) architectural proof of secure design principles (defense-in-depth via 6-phase scoring gating, least privilege via namespace jails, fail-closed authentication entry points, and economy of mechanism via a zero-dependency engine kernel); and (4) concrete evidence-based countermeasures against common implementation security weaknesses (CWE-119/416 via Panama FFM bounded arenas, CWE-22 via path normalization and character allowlists, CWE-502 via banned native serialization and CRC32C validation, CWE-78/89 via typed DTO schemas, and CWE-208 via constant-time token comparison).


 分析 2/2 ●

  • 静态代码分析


    足够获得徽章！

    如果至少有一个FLOSS工具能够以所选择的语言实现此条款，则该项目必须至少使用一个具有规则或方式的静态分析工具来查找分析语言或环境中的常见漏洞。 [static_analysis_common_vulnerabilities]
    专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。

    CodeQL is configured with the 'security-extended' query suite (.github/workflows/codeql.yml line 58), which incorporates rules covering the OWASP Top 10 and CWE Top 25 vulnerabilities for Java, TypeScript, and Python (including path injection, deserialization flaws, command execution, and cryptographic misconfigurations). https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml#L58


  • 动态代码分析


    足够获得徽章！

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

    Not applicable. The software produced by the project is written in memory-safe languages (Java 25, TypeScript, and Python) with no compiled C or C++ binaries. Native off-heap memory operations in Java utilize Project Panama's bounded MemorySegment and Arena APIs with built-in spatial/temporal bounds checking, accompanied by dynamic runtime leak detection (PanamaMemoryDetector).



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

项目徽章条目拥有者： Bharat Joshi.
最后更新于 2026-09-25 00:58:39 UTC, 最后更新于 2026-09-25 04:20:39 UTC。 最后在 2026-09-25 01:54:45 UTC 获得通过徽章。