spector

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 14829 - silver Вот как вставить его:
Вы можете показать свой статус значка, вставив его в файл с разметкой 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>


Это критерии уровня Silver. Вы также можете просмотреть критерии уровня Passing или Gold.

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».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

  • Предварительные требования


    Достаточно для значка!

    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

  • Основная информация на веб-сайте проекта


    Достаточно для значка!

    В информацию о том, как внести вклад, НЕОБХОДИМО включить требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]

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


  • Надзор за проектом


    Достаточно для значка!

    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]
    DCO является рекомендуемым механизмом, потому что его легко реализовать и отслеживать в исходном коде, а git напрямую поддерживает функцию "signed-off" при помощи "commit -s". Для большей эффективности лучше всего, если проектная документация объясняет, что означает "signed-off" для этого проекта. CLA - это юридическое соглашение, которое определяет условия, на которых произведения умственного труда были лицензированы для организации или проекта. Соглашение о назначении участника (contributor assignment agreement, CAA) является юридическим соглашением, которое передает права на произведения умственного труда другой стороне; проекты не обязаны иметь CAA, поскольку CAA увеличивает риск того, что потенциальные участники не будут вносить свой вклад, особенно если получатель является коммерческой организацией. Лицензии CLA от Apache Software Foundation (лицензия отдельного участника и корпоративное соглашение 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


    Достаточно для значка!

    Проект ОБЯЗАН четко определить и задокументировать модель управления проектом (способ принятия решений, включая ключевые роли). (Требуется URL) [governance]
    Требуется устоявшийся задокументированный способ принятия решений и разрешения споров. В небольших проектах это может быть просто вплоть до «владелец и лидер проекта принимает все окончательные решения». Существуют различные модели управления, включая благосклонное диктаторство и формальную меритократию; более подробно см. Governance models. В проектах успешно используются как централизованные подходы (например, с одним ведущим), так и децентрализованные (например, с групповыми ведущими). Не нужно указывать в сведениях об управлении возможность форка проекта, поскольку это всегда возможно для проектов СПО.

    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.

    Достаточно для значка!

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]
    Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

    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


    Достаточно для значка!

    Проект ОБЯЗАН четко определять и публично документировать ключевые роли в проекте и их обязанности, включая любые задачи, которые должны выполнять эти роли. Должно быть ясно, кто имеет какую роль(и), хотя это может быть и не задокументировано соответствующим образом. (Требуется URL) [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)


    Достаточно для значка!

    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [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 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    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).


  • Документация


    Достаточно для значка!

    Проект ОБЯЗАН иметь задокументированный долгосрочный план (roadmap), описывающий, что проект намеревается, а что не намеревается делать, по крайней мере на ближайший год. (Требуется URL) [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), если проект не создает программное обеспечение. (Требуется URL) [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).


    Достаточно для значка!

    Проект ОБЯЗАН документировать то, что пользователь может и чего он не должен ожидать с точки зрения безопасности от ПО, создаваемого проектом (его «требования безопасности»). (Требуется URL) [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.


    Достаточно для значка!

    Проект ОБЯЗАН предоставить руководство для быстрого начала работы для новых пользователей, чтобы помочь им быстро что-то сделать, используя ПО, создаваемое проект. (Требуется URL) [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 часов после открытого признания достижения. (Требуется URL) [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]
    Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:
    • Должны предоставляться текстовые альтернативы для любого нетекстового контента, так чтобы его можно изменить на другие необходимые формы, например крупная печать, шрифт Брайля, озвучка текста, символы или упрощенный язык (Understanding WCAG 2.0 guideline 1.1)
    • Цвет не должен использоваться в качестве единственного визуального средства передачи информации, указания на действие, запрос реакции пользователя или выделения визуальных элементов. (WCAG 2.0 guideline 1.4.1)
    • Визуальное представление текста и изображений текста должно иметь контрастность не менее 4,5:1, за исключением большого текста, случайного текста и логотипов (WCAG 2.0 guideline 1.4.3)
    • Все функциональные возможности должны быть доступны с клавиатуры (WCAG guideline 2.1)
    • GUI или веб-проект ДОЛЖНЫ тестировать, по крайней мере, одно средство чтения экрана на целевой платформе(ах) (например, NVDA, Jaws или WindowEyes в Windows; VoiceOver на Mac и iOS; Orca на Linux/BSD; TalkBack на Android). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    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.


    Достаточно для значка!

    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [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-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]
    Примечание: использование GitHub автоматически выполняет этот критерий. Этот критерий применяется только к паролям, используемым для аутентификации внешних пользователей на сайтах проекта (т.н. входящей аутентификации). Если сайты проекта должны подключаться к другим сайтам (т.н. исходящая аутентификация), им может потребоваться хранить аутентифицирующие данные (пароли, ключи) для этой цели как-то иначе (поскольку хранение контрольной суммы для этой цели бесполезно). В данном случае критерий 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 ●

  • Предыдущие версии


    Достаточно для значка!

    Проект ОБЯЗАН поддерживать наиболее часто используемые старые версии продукта или предоставлять возможность простого перехода на более новые версии (upgrade path). Если переход затруднен, проект ОБЯЗАН задокументировать порядок обновления (например, изменившиеся интерфейсы и подробные предлагаемые шаги для обновления). [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 ●

  • Процесс сообщения об ошибках


    Достаточно для значка!

    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [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 месяцев, за исключением авторов, которые просят об анонимности. Выберите «неприменимо» (N/A), если в течение последних 12 месяцев не было обнаружено никаких уязвимостей. (Требуется URL) [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).


    Достаточно для значка!

    Проект ОБЯЗАН иметь документированный процесс реагирования на отчеты об уязвимостях. (Требуется URL) [vulnerability_response_process]
    Этот критерий тесно связан с критерием vulnerability_report_process, который требует документированного способа для сообщения об уязвимостях. Он также связан с vulnerability_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 ●

  • Стандарты кодирования


    Достаточно для значка!

    Проект ОБЯЗАН задать определенные правила стиля кодирования для основных языков, которые он использует, и требовать его соблюдения от предлагаемого кода. (Требуется URL) [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.


    Достаточно для значка!

    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [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»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [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.


    Достаточно для значка!

    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]
    Информация о внутренних зависимостях системы сборки проекта должна быть точной, в противном случае изменения в проекте могут быть включены в сборку неправильно. Неправильные сборки могут привести к дефектам (включая уязвимости). Общей ошибкой в ​​больших системах сборки является использование «рекурсивной сборки» или «рекурсивного make», то есть иерархии подкаталогов, содержащих исходные файлы, где каждый подкаталог собирается независимо. Если только каждый из подкаталогов не является полностью независимым, это ошибка, потому что информация о зависимостях неверна.

    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; в некоторых случаях это может быть разрешено путем задания определенного порядка сортировки. Дополнительные предложения можно найти на сайте Reproducible builds.

    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), контейнер в стандартном формате или образ виртуальной машины в стандартном формате. Процесс установки и удаления (например, его упаковка) МОЖЕТ быть реализован третьей стороной, при условии что он построен на СПО.

    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.


  • Компоненты, поддерживаемые извне


    Достаточно для значка!

    Проект ОБЯЗАН перечислять внешние зависимости в машинночитаемом виде. (Требуется URL) [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]
    Это можно сделать с помощью средств анализа происхождения/зависимостей, например Dependency-Check от OWASP, Nexus Auditor от Sonatype, Protex от Black Duck , Protecode от Synopsys и Bundler-аудит (для 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]
    Типичным способом выполнить этот критерий является использование предоставляемых операционной системой и языком программирования систем управления пакетами. Многие свободные программы распространяются с «подсобными библиотеками», которые являются локальными копиями стандартных библиотек (возможно, форков библиотек). Само по себе это нормально. Однако, если программа *должна* использовать эти локальные копии/форки, то обновление «стандартных» библиотек через системное обновление безопасности оставит эти дополнительные копии по-прежнему уязвимыми. Это особенно актуально для облачных систем; если провайдер облака обновляет свои «стандартные» библиотеки, но программа их не собирается использовать, обновления фактически не помогут. См., например, "Chromium: Why it isn't in Fedora yet as a proper package" от Тома Каллавея.

    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).


    Достаточно для значка!

    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [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.


    Достаточно для значка!

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]
    Для измерения тестового покрытия существует множество средств на СПО, включая 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 или режим CBC в SSH). [crypto_weaknesses]
    Проблемы, связанные с режимом CBC в SSH, обсуждаются в описании уязвимости CERT: 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, выберите «неприменимо» (N/A). [crypto_certificate_verification]
    Обратите внимание, что неправильная проверка сертификата TLS является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

    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, выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует 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), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (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.


    Достаточно для значка!

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]
    Обоснованием является «документальное подтверждение, которое дает убедительное и корректное доказательство того, что указанный набор критических заявлений относительно свойств системы адекватно оправдан для данного приложения в данной среде» (перевод выдержки из "Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Границы доверия - это границы, на которых меняется уровень доверия к данным или выполнению кода, например границы сервера в типичном веб-приложении. В обосновании обычно перечисляются принципы безопасного проектирования (такие как Saltzer and Schroeer) и общие слабости безопасности в реализации (такие как OWASP Top 10 или CWE/SANS Top 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 ●

  • Статический анализ кода


    Достаточно для значка!

    Проект ОБЯЗАН использовать хотя бы один инструмент статического анализа с правилами или подходами для поиска распространенных уязвимостей в анализируемом языке или окружении, если есть хотя бы один инструмент на СПО, который может реализовать этот критерий на выбранном языке. [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++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. [dynamic_analysis_unsafe]
    Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

    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).



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/14829/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Bharat Joshi и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Bharat Joshi.
2026-09-25 00:58:39 UTC, последнее изменение сделано 2026-09-25 03:48:40 UTC. Последний раз условия для получения значка были выполнены 2026-09-25 01:54:45 UTC.