spector

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 14829 est silver Voici comment l'intégrer :
Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14829/badge)](https://www.bestpractices.dev/projects/14829)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/14829"><img src="https://www.bestpractices.dev/projects/14829/badge"></a>


Ce sont les critères du niveau Argent. Vous pouvez également afficher les critères des niveaux Basique ou Or.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base 17/17 ●

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

    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.

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.

  • Conditions préalables


    Assez pour un badge !

    Le projet DOIT atteindre un badge de niveau basique. [achieve_passing]

  • Contenu basique du site Web du projet


    Assez pour un badge !

    Les informations sur la façon de contribuer DOIVENT inclure les exigences pour des contributions acceptables (par exemple, une référence à toute règle de codage requise). (URL requise) [contribution_requirements]

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


  • Supervision du projet


    Assez pour un badge !

    Le projet DEVRAIT avoir un mécanisme juridique par lequel tous les développeurs de quantités non triviales de logiciel du projet affirment qu'ils sont légalement autorisés à effectuer ces contributions. L'approche la plus commune et facilement mise en œuvre pour ce faire est d'utiliser un Certificat d'origine du développeur (DCO), où les utilisateurs ajoutent une information « sign-off-by » dans leurs commits et le projet pointe vers le site Web du DCO. Cependant, cela PEUT être mis en œuvre en tant que contrat de licence de contributeur (CLA), ou tout autre mécanisme juridique. (URL requise) [dco]
    Le DCO est le mécanisme recommandé, car il est facile à mettre en œuvre, suivi dans le code source, et git prend directement en charge une fonction « approuvé » en utilisant « commit -s ». Pour être plus efficace, il est préférable que la documentation du projet explique ce que signifie « approuvé » pour ce projet. Un CLA est un accord juridique qui définit les termes en vertu desquels des travaux intellectuels ont été licenciés à une organisation ou un projet. Un accord de cession (CAA) est un accord légal qui transfère les droits dans un travail intellectuel à une autre partie ; il n'est pas exigé d'avoir des CAA pour les projets, car un CAA augmente le risque que les contributeurs potentiels ne contribuent pas, en particulier si le destinataire est un organisme à but lucratif. Les CLA de la Fondation Apache (la licence de contributeur individuel et la CLA d'entreprise) sont des exemples de CLA pour des projets qui déterminent que les risques de ces types de CLA au projet sont inférieurs à leurs avantages.

    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


    Assez pour un badge !

    Le projet DOIT définir et documenter clairement son modèle de gouvernance de projet (la façon dont il prend ses décisions, y compris les rôles clés). (URL requise) [governance]
    Il doit y avoir une manière documentée bien établie de prendre des décisions et de résoudre les différends. Dans les petits projets, cela peut être aussi simple que « le propriétaire du projet et dirigeant prend toutes les décisions finales ». Il existe différents modèles de gouvernance, y compris le dictateur bienveillant et la méritocratie formelle ; pour plus de détails, voir Modèles de gouvernance. Les approches centralisées (par exemple, un seul mainteneur) et décentralisées (par exemple, les groupes de mainteneurs) ont été utilisées avec succès dans des projets. L'information sur la gouvernance n'a pas besoin de documenter la possibilité de créer une duplication de projet, car cela est toujours possible pour les projets 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.

    Assez pour un badge !

    Le projet DOIT adopter un code de conduite et le publier dans un lieu standard. (URL requise) [code_of_conduct]
    Les projets peuvent être en mesure d'améliorer la civilité de leur communauté et d'établir des attentes quant à une conduite acceptable en adoptant un code de conduite. Cela peut aider à éviter les problèmes avant leur apparition et faire du projet un lieu plus accueillant pour encourager les contributions. Cela devrait se concentrer uniquement sur le comportement au sein de la communauté / lieu de travail du projet. Des exemples de codes de conduite sont le code de conduite du noyau Linux, le code de conduite du pacte de contributeur, le code de conduite du projet Debian, le code de conduite du projet Ubuntu, le code de conduite du projet Fedora, le code de conduite du projet GNOME, le code de conduite de la communauté KDE", le code de conduite de la communauté Python, le guide de conduite de la communauté Ruby, et le code de conduite du projet Rust.

    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


    Assez pour un badge !

    Le projet DOIT clairement définir et documenter publiquement les rôles clés dans le projet et leurs responsabilités, y compris les tâches que ces rôles doivent accomplir. Il DOIT être clairement exprimé qui a quel(s) rôle(s), mais cela pourrait ne pas être documenté de la même manière. (URL requise) [roles_responsibilities]
    La documentation pour la gouvernance et les rôles et responsabilités peut être à un seul endroit.

    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)


    Assez pour un badge !

    Le projet DOIT pouvoir continuer avec une interruption minimale si une personne décède, est invalidée ou ne peut/veut plus continuer à maintenir le projet. En particulier, le projet DOIT être en mesure de créer et de fermer des problèmes, d'accepter les modifications proposées et de publier des versions du logiciel, dans un délai d'une semaine après confirmation du retrait d'un individu du projet. Cela PEUT être fait en s'assurant que quelqu'un d'autre possède les clés, les mots de passe et les droits juridiques nécessaires pour poursuivre le projet. Les personnes qui exécutent un projet FLOSS PEUVENT faire cela en fournissant des clés dans un coffre-fort et un testament fournissant les droits légaux nécessaires (par exemple, pour les noms DNS). (URL requise) [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.


    Assez pour un badge !

    Le projet DEVRAIT avoir un « bus factor » de 2 ou plus. (URL requise) [bus_factor]
    Un « bus factor » (aussi connu en tant que « truck factor ») est le nombre minimum de membres du projet qui doivent disparaître soudainement d'un projet (« écrasé par un bus ») avant que le projet ne se bloque en raison du manque de personnel compétent. L'outil truck-factor peut l'estimer pour des projets sur GitHub. Pour plus d'informations, voir Évaluation du « bus factor » des dépôts Git par Cosentino et al.

    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


    Assez pour un badge !

    Le projet DOIT avoir une feuille de route documentée qui décrit ce que le projet a l'intention de faire et ne pas faire pour au moins l'année suivante. (URL requise) [documentation_roadmap]
    Le projet pourrait ne pas atteindre la feuille de route, et c'est acceptable ; le but de la feuille de route est d'aider les utilisateurs et les contributeurs potentiels à comprendre l'orientation prévue du projet. Elle ne doit nécessairement pas être détaillée.

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


    Assez pour un badge !

    Le projet DOIT inclure la documentation de l'architecture (aussi appelée conception de haut niveau) du logiciel produit par le projet. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). (URL requise) [documentation_architecture]
    Une architecture de logiciel explique les structures fondamentales d'un programme, c'est-à-dire les principaux composants du programme, les relations entre eux et les propriétés clés de ces composants et de ces relations.

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


    Assez pour un badge !

    Le projet DOIT documenter ce à quoi l'utilisateur peut et ne peut pas s'attendre en termes de sécurité à partir du logiciel produit par le projet (ses « exigences de sécurité »). (URL requise) [documentation_security]
    Ce sont les exigences de sécurité que le logiciel est supposé remplir.

    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.


    Assez pour un badge !

    Le projet DOIT fournir un guide de « démarrage rapide » pour les nouveaux utilisateurs afin de les aider à faire rapidement quelque chose avec le logiciel. (URL requise) [documentation_quick_start]
    L'idée est de montrer aux utilisateurs comment démarrer et de faire en sorte que le logiciel fasse quelque chose. Ceci est d'une importance cruciale pour les utilisateurs potentiels pour les aider à démarrer.

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


    Assez pour un badge !

    Le projet DOIT faire un effort pour maintenir la documentation conforme à la version actuelle des résultats du projet (y compris les logiciels produits par le projet). Tous les défauts de la documentation connus la rendant incohérente DOIVENT être corrigés. Si la documentation est généralement à jour, mais inclut de manière erronée certaines informations antérieures qui ne sont plus vraies, considérez cela comme un défaut, puis faites le suivi et corrigez comme d'habitude. [documentation_current]
    La documentation PEUT inclure des informations sur les différences ou les modifications entre les versions du logiciel et/ou des liens vers les anciennes versions de la documentation. L'objectif de ce critère est de faire en sorte que la documentation soit cohérente et non pas que la documentation soit parfaite.

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


    Assez pour un badge !

    La page d'accueil et/ou le site Web du dépôt du projet DOIVENT identifier et pointer tous les accomplissements, y compris ce badge sur les meilleures pratiques, dans les 48 heures suivant la reconnaissance publique que l'accomplissement a été atteint. (URL requise) [documentation_achievements]
    Un accomplissement est un ensemble de critères externes que le projet a spécifiquement cherché à atteindre, y compris certains badges. Cette information ne doit pas nécessairement être sur la page d'accueil du site Web du projet. Un projet utilisant GitHub peut mettre des accomplissements sur la page d'accueil du dépôt en les ajoutant au fichier 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.


  • Accessibilité et internationalisation


    Assez pour un badge !

    Le projet (à la fois les sites du projet et les résultats du projet) DEVRAIT suivre les meilleures pratiques d'accessibilité afin que les personnes handicapées puissent encore participer au projet et utiliser les résultats du projet où il est raisonnable de le faire. [accessibility_best_practices]
    Pour les applications Web, consultez les Directives d'accessibilité des contenus Web (WCAG 2.0) et son document à l'appui Comprendre WCAG 2.0 ; voir aussi les informations d'accessibilité du W3C. Pour les applications IHM, envisagez d'utiliser les directives d'accessibilité spécifiques à l'environnement (telles que Gnome, KDE, XFCE, Android, IOS, Mac et Windows). Certaines applications IHM textuelles (par exemple, les programmes « ncurses ») peuvent faire certaines choses pour se rendre plus accessibles (par exemple, le paramètre « force-arrow-cursor » de « alpine »). La plupart des applications en ligne de commande sont assez accessibles telles quelles. Ce critère est souvent N/A, par exemple, pour les bibliothèques. Voici quelques exemples d'actions à prendre ou de questions à considérer :
    • Fournir des alternatives de texte pour tout contenu non textuel afin qu'il puisse être changé en d'autres formes dont les gens ont besoin, comme une plus grande taille, le braille, une sortie vocale, des symboles ou une langue plus simple (WCAG 2.0 directive 1.1)
    • La couleur n'est pas utilisée comme le seul moyen visuel de transmettre des informations, d'indiquer une action, de provoquer une réponse ou de distinguer un élément visuel. (WCAG 2.0 directive 1.4.1)
    • La présentation visuelle du texte et des images du texte a un taux de contraste d'au moins 4,5:1, à l'exception du grand texte, du texte incident, et des logotypes (WCAG 2.0 directive 1.4.3)
    • Rendez toutes les fonctionnalités disponibles à partir d'un clavier (WCAG directive 2.1)
    • Une IHM ou un projet basé sur le Web DEVRAIT tester avec au moins un lecteur d'écran sur la (les) plate-forme(s) cible(s) (par exemple NVDA, Jaws ou WindowEyes sur Windows ; VoiceOver sur Mac & iOS ; Orca sous Linux/BSD ; TalkBack sur Android). Les programmes IHM textuels PEUVENT travailler à réduire le retrait excessif pour éviter la lecture redondante par les lecteurs d'écran.

    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.


    Assez pour un badge !

    Le logiciel produit par le projet DEVRAIT être internationalisé pour permettre une localisation facile pour la culture, la région ou la langue du public cible. Si l'internationalisation (i18n) ne s'applique pas (par exemple, le logiciel ne génère pas de texte destiné aux utilisateurs finaux et ne trie pas de texte lisible par les humains), sélectionnez « non applicable » (N/A). [internationalization]
    La localisation « réfère à l'adaptation du contenu d'un produit, d'une application ou d'un document pour répondre aux exigences linguistiques, culturelles et autres d'un marché cible spécifique (un lieu). » L'internationalisation est la « conception et le développement du contenu d'un produit, d'une application ou d'un document qui permette une localisation facile pour les publics cibles qui varient en culture, en région ou en langue. » (Voir la page « Localisation ou Internationalisation » du W3C.) Le logiciel répond à ce critère simplement en étant internationalisé. Aucune localisation pour une autre langue spécifique n'est requise, car une fois que le logiciel a été internationalisé, d'autres peuvent travailler sur la localisation.

    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.


  • Autre


    Assez pour un badge !

    Si les sites du projet (site Web, dépôt et URL de téléchargement) entreposent des mots de passe pour l'authentification d'utilisateurs externes, les mots de passe DOIVENT être entreposés comme hachages itérés avec salage par utilisateur en utilisant un algorithme d'étirement des clés (itéré) (par exemple, Argon2id, Bcrypt, Scrypt, ou PBKDF2). Si les sites du projet n'entreposent pas de mots de passe à cette fin, sélectionnez « non applicable » (N/A). [sites_password_security]
    Notez que l'utilisation de GitHub répond à ce critère. Ce critère s'applique uniquement aux mots de passe utilisés pour l'authentification d'utilisateurs externes sur les sites du projet (càd l'authentification entrante). Si les sites du projet doivent se connecter à d'autres sites (càd l'authentification sortante), ils devront peut-être entreposer différemment des jetons d'identification à cette fin (puisque conserver un code de hachage serait inutile). Ceci applique le critère crypto_password_storage aux sites du projet, de manière similaire à 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.


 Contrôle des modifications 1/1 ●

  • Versions précédentes


    Assez pour un badge !

    Le projet DOIT maintenir les anciennes versions les plus utilisées du produit ou fournir un chemin de mise à niveau vers des versions plus récentes. Si le chemin de mise à niveau est difficile, le projet DOIT documenter comment effectuer la mise à niveau (par exemple, les interfaces qui ont changé et une suggestion d'étapes détaillées pour aider la mise à niveau). [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.


 Compte-rendu 3/3 ●

  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [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


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT créditer les auteurs de tous les signalements de vulnérabilité résolus au cours des 12 derniers mois, à l'exception des auteurs qui demandent l'anonymat. S'il n'y a pas eu de vulnérabilité résolue au cours des 12 derniers mois, sélectionnez « non applicable » (N/A). (URL requise) [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).


    Assez pour un badge !

    Le projet DOIT avoir un processus documenté pour répondre aux signalements de vulnérabilité. (URL requise) [vulnerability_response_process]
    Ceci est fortement lié à vulnerability_report_process, qui exige qu'il existe un moyen documenté de signaler les vulnérabilités. Il a également trait à la vulnerability_report_response, qui nécessite une réponse aux signalements de vulnérabilité dans un certain laps de temps.

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


 Qualité 19/19 ●

  • Normes de codage


    Assez pour un badge !

    Le projet DOIT identifier les guides de style de codage spécifiques pour les langages principaux qu'il utilise, et exiger que les contributions le respectent en général. (URL requise) [coding_standards]
    Dans la plupart des cas, cela se fait en se référant à certains guides de style existants, ce qui permet d'énumérer les différences. Ces guides de style peuvent inclure des moyens d'améliorer la lisibilité et les moyens de réduire la probabilité de défauts (y compris les vulnérabilités). Beaucoup de langages de programmation ont un ou plusieurs guides de style largement utilisés. Des exemples de guides de style incluent les guides de style de Google et les Règles de codage du 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.


    Assez pour un badge !

    Le projet DOIT imposer automatiquement son ou ses styles de codage sélectionnés s'il existe au moins un outil FLOSS qui peut le faire dans le(s) langage(s) sélectionné(s). [coding_standards_enforced]
    Cela PEUT être mis en œuvre en utilisant des outils d'analyse statique et/ou en faisant passer le code à travers des outils de remise en forme. Dans de nombreux cas, la configuration de l'outil est incluse dans le dépôt du projet (car différents projets peuvent choisir différentes configurations). Les projets PEUVENT permettre des exceptions de style (et le font habituellement) ; là où les exceptions se produisent, elles DOIVENT être rares et documentées dans le code à leur emplacement, afin que ces exceptions puissent être revues et que les outils puissent les gérer automatiquement à l'avenir. Des exemples de tels outils incluent ESLint (JavaScript), Rubocop (Ruby) et devtools check (R).

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


  • Système de construction opérationnel


    Assez pour un badge !

    Les systèmes de construction pour les binaires natifs DOIVENT honorer les variables (d'environnement) pertinentes du compilateur et du lieur qui leur sont transmises (par exemple, CC, CFLAGS, CXX, CXXFLAGS et LDFLAGS) et les transmettre aux invocations du compilateur et du lieur. Un système de construction PEUT les étendre avec des options supplémentaires ; il NE DOIT PAS simplement remplacer les valeurs fournies par les siennes. Si aucun fichier binaire natif n'est généré, sélectionnez « non applicable » (N/A). [build_standard_variables]
    Il devrait être facile d'activer des fonctionnalités de construction spéciales telles que Address Sanitizer (ASAN), ou de se conformer aux meilleures pratiques de durcissement de la distribution (par exemple, en activant facilement les options de compilation pour le faire).

    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.


    Assez pour un badge !

    Le système de construction et d'installation DEVRAIT préserver les informations de débogage si elles sont demandées dans les options correspondants (par exemple, « install -s » n'est pas utilisé). S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_preserve_debug]
    Par exemple, la définition de CFLAGS (C) ou CXXFLAGS (C++) devrait créer les informations de débogage pertinentes si ces langages sont utilisés et elles ne devraient pas être retirées pendant l'installation. Des informations de débogage sont nécessaires pour le support et l'analyse, et également utiles pour mesurer la présence de fonctionnalités de durcissement dans les binaires compilés.

    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.


    Assez pour un badge !

    Le système de construction pour le logiciel produit par le projet NE DOIT PAS reconstruire de manière récursive des sous-répertoires s'il existe des dépendances croisées dans les sous-répertoires. S'il n'y a pas de système de construction ou d'installation (par exemple, les bibliothèques JavaScript typiques), sélectionnez « non applicable » (N/A). [build_non_recursive]
    Les informations de dépendance internes du système de construction du projet doivent être précises, sinon, les modifications apportées au projet peuvent ne pas s'effectuer correctement. Des constructions incorrectes peuvent entraîner des défauts (y compris des vulnérabilités). Une erreur courante dans les grands systèmes de construction est d'utiliser une « construction récursive », c'est-à-dire une hiérarchie de sous-répertoires contenant des fichiers source, chaque sous-répertoire étant construit de manière indépendante. Sauf si chaque sous-répertoire est entièrement indépendant, ceci est une erreur, car les informations de dépendance sont incorrectes.

    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.


    Assez pour un badge !

    Le projet DOIT pouvoir répéter le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Si aucune construction ne se produit (par exemple, dans les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). [build_repeatable]
    Les utilisateurs GCC et Clang peuvent trouver l'option -frandom-seed utile ; dans certains cas, cela peut être résolu en forçant un ordre de tri. Plus de suggestions peuvent être trouvées sur le site pour une construction reproductible.

    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.


  • Système d'installation


    Assez pour un badge !

    Le projet DOIT fournir un moyen d'installer et de désinstaller facilement le logiciel produit par le projet en utilisant une convention couramment utilisée. [installation_common]
    Des exemples comprennent l'utilisation d'un gestionnaire de paquets (au niveau du système ou du langage), « make/install/uninstall » (supportant DESTDIR), un conteneur dans un format standard ou une image de machine virtuelle dans un format standard. Le processus d'installation et de désinstallation (par exemple, son paquetage) PEUT être mis en œuvre par un tiers tant qu'il est 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.


    Assez pour un badge !

    Le système d'installation pour les utilisateurs finaux DOIT honorer les conventions standard pour sélectionner l'emplacement où les artefacts construits sont écrits au moment de l'installation. Par exemple, s'il installe des fichiers sur un système POSIX, il DOIT honorer la variable d'environnement DESTDIR. S'il n'y a pas de système d'installation ou pas de convention standard, sélectionnez « non applicable » (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.


    Assez pour un badge !

    Le projet DOIT fournir un moyen pour les développeurs potentiels d'installer rapidement tous les résultats du projet ainsi que l'environnement nécessaire pour apporter des modifications, y compris les tests et l'environnement de test. Cela DOIT être effectué avec une convention couramment utilisée. [installation_development_quick]
    Cela PEUT être implémenté à l'aide d'un conteneur généré et/ou d'un script d'installation. Les dépendances externes sont généralement installées en invoquant des gestionnaires de paquets du système et/ou du langage, comme précisé dans 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.


  • Composants maintenus à l'extérieur


    Assez pour un badge !

    Le projet DOIT afficher ses dépendances externes de manière analysable par ordinateur. (URL requise) [external_dependencies]
    Généralement, cela se fait en utilisant les conventions du gestionnaire de paquets et/ou du système de construction. Notez que cela permet d'implémenter 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).


    Assez pour un badge !

    Les projets DOIVENT surveiller ou vérifier périodiquement leurs dépendances externes (y compris les copies de commodité) pour détecter les vulnérabilités connues, et corriger les vulnérabilités exploitables ou les vérifier comme inexploitables. [dependency_monitoring]
    Cela peut se faire à l'aide d'un outil d'analyse d'origine, de vérification de dépendance ou d'analyse de la composition du logiciel tel que Dependency-Check d'OWASP, Nexus Auditeur de Sonartype, Black Duck Software Composition Analysis de Synopsys, et Bundler-audit (pour Ruby). Certains gestionnaires de paquets comprennent des mécanismes pour le faire. Il est acceptable que la vulnérabilité des composants ne puisse pas être exploitée, mais cette analyse est difficile et il est parfois plus simple de mettre à jour ou de corriger la dépendance.

    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.


    Assez pour un badge !

    Le projet DOIT :
    1. rendre facile l'identification et la mise à jour des composants maintenus extérieurement au projet ; ou
    2. utiliser des composants standards fournis par le système ou le langage de programmation.
    Ensuite, si une vulnérabilité se trouve dans un composant réutilisé, il sera facile de mettre à jour ce composant. [updateable_reused_components]
    Une façon typique de respecter ce critère est d'utiliser les systèmes de gestion des paquets du système et du langage de programmation. De nombreux programmes FLOSS sont distribués avec des « bibliothèques de commodité » qui sont des copies locales de bibliothèques standard (éventuellement dupliquées). En soi, c'est acceptable. Cependant, si le programme *doit* utiliser ces copies locales (dupliquées), la mise à jour des bibliothèques « standard » lors de mises à jour de sécurité laissera ces copies supplémentaires encore vulnérables. C'est particulièrement un problème pour les systèmes basés sur le cloud ; si le fournisseur du cloud met à jour ses librairies « standard » mais que le programme ne les utilise pas, les mises à jour ne vous aideront pas. Voir, par exemple, « Chromium : pourquoi il n'est pas encore un vrai paquet dans Fedora » par 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).


    Assez pour un badge !

    Le projet DEVRAIT éviter d'utiliser des fonctions et des API obsolètes quand des alternatives FLOSS sont disponibles dans l'ensemble de technologies qu'il utilise (sa « pile de technologies ») et disponibles à une large majorité des utilisateurs supportés par le projet (afin que les utilisateurs puissent avoir accès à l'alternative). [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.


  • Suite de tests automatisée


    Assez pour un badge !

    Une suite de tests automatisée DOIT être appliquée à chaque commit dans un dépôt partagé pour au moins une branche. Cette suite de tests DOIT produire un rapport sur le succès ou l'échec du test. [automated_integration_testing]
    Cette exigence peut être considérée comme un sous-ensemble de test_continuous_integration, mais axée sur le simple test, sans nécessiter une intégration continue.

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


    Assez pour un badge !

    Le projet DOIT ajouter des tests de régression à une suite de tests automatisée pour au moins 50% des bogues corrigés au cours des six derniers mois. [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.


    Assez pour un badge !

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage80]
    De nombreux outils FLOSS sont disponibles pour mesurer la couverture des tests, y compris gcov/lcov, Blanket.js, Istanbul, JCov et covr (R). Notez que respecter ce critère n'est pas une garantie que la suite de tests est complète, mais, à l'inverse, ne pas respecter ce critère est un indicateur fort d'une suite de tests insuffisante.

    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.


  • Nouveau test de fonctionnalité


    Assez pour un badge !

    Le projet DOIT avoir une politique écrite formelle, que dès qu'une nouvelle fonctionnalité majeure est ajoutée, des tests pour la nouvelle fonctionnalité DOIVENT être ajoutés à une suite de tests automatisée. [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).


    Assez pour un badge !

    Le projet DOIT inclure, dans ses instructions documentées pour les propositions de changement, la politique selon laquelle des tests doivent être ajoutés pour toute nouvelle fonctionnalité majeure. [tests_documented_added]
    Cependant, même une règle informelle est acceptable tant que les tests sont ajoutés dans la pratique.

    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


  • Options d'avertissement


    Assez pour un badge !

    Les projets DOIVENT être maximalement stricts avec les avertissements dans le logiciel produit par le projet, quand cela est approprié. [warnings_strict]
    Certains avertissements ne peuvent être efficacement activés sur certains projets. Ce qui est nécessaire est la preuve que le projet s'efforce d'activer les options d'avertissements où il peut, de sorte que les erreurs soient détectées tôt.

    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


 Sécurité 13/13 ●

  • Connaissance du développement sécurisé


    Assez pour un badge !

    Le projet DOIT implémenter des principes de conception sécurisés (à partir de « know_secure_design »), quand cela est approprié. Si le projet ne produit pas de logiciel, sélectionnez « non applicable » (N/A). [implement_secure_design]
    Par exemple, les résultats du projet devraient avoir des valeurs sécurisées par défaut (les décisions d'accès devraient être de refuser par défaut et l'installation des projets devrait être sécurisée par défaut). Ils devraient également avoir une médiation complète (tout accès qui pourrait être limité doit être vérifié pour l'autorité et être non contournable). Notez que, dans certains cas, ces principes entrent en conflit, auquel cas un choix doit être fait (par exemple, de nombreux mécanismes peuvent rendre les choses plus complexes, en contravention de « l'économie de mécanisme » / principe KISS).

    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.


  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Assez pour un badge !

    Les mécanismes de sécurité par défaut dans le logiciel produit par le projet NE DOIVENT PAS dépendre d'algorithmes ou de modes cryptographiques avec des faiblesses sérieuses connues (par exemple, l'algorithme de hachage cryptographique SHA-1 ou le mode CBC en SSH). [crypto_weaknesses]
    Les préoccupations concernant le mode CBC en SSH sont discutées dans CERT : vulnérabilité 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.


    Assez pour un badge !

    Le projet DEVRAIT supporter plusieurs algorithmes cryptographiques, afin que les utilisateurs puissent rapidement changer si l'un deux est cassé. Les algorithmes à clés symétriques courants incluent AES, Twofish et Serpent. Les alternatives d'algorithme de hachage cryptographique courantes incluent SHA-2 (y compris SHA-224, SHA-256, SHA-384 ET SHA-512) et 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.


    Assez pour un badge !

    Le projet DOIT supporter le stockage des informations d'authentification (comme les mots de passe et les jetons dynamiques) et des clés cryptographiques privées dans des fichiers distincts des autres informations (fichiers de configuration, bases de données et journaux) et permettre aux utilisateurs de les mettre à jour et de les remplacer sans recompilation de code. Si le projet ne traite jamais d'informations d'authentification et de clés cryptographiques privées, sélectionnez « non applicable » (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.


    Assez pour un badge !

    Le logiciel produit par le projet DEVRAIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DEVRAIENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (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.


    Assez pour un badge !

    Le logiciel produit par le projet DEVRAIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (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.


    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il prend en charge TLS, effectuer la vérification des certificats TLS par défaut lors de l'utilisation de TLS, y compris sur les sous-ressources. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_certificate_verification]
    Notez que la vérification incorrecte du certificat TLS est une erreur courante. Pour plus d'informations, voir « Le code le plus dangereux du monde : la validation des certificats SSL dans du logiciel qui ne vient pas d'un navigateur » de Martin Georgiev et al. et « Avez-vous confiance en cette application ? » par 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.


    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il supporte TLS, effectuer une vérification de certificat avant d'envoyer des en-têtes HTTP avec des informations privées (telles que des cookies sécurisés). Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (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.


  • Livraison sécurisée


    Assez pour un badge !

    Le projet DOIT signer cryptographiquement les versions des résultats du projet destinées à une utilisation répandue, et il DOIT y avoir un processus documenté expliquant aux utilisateurs comment ils peuvent obtenir les clés de signature publique et vérifier la ou les signatures. La clé privée pour ces signature(s) NE DOIT PAS être sur le(s) site(s) utilisé(s) pour distribuer directement le logiciel au public. Si les versions ne sont pas destinées à une utilisation répandue, sélectionnez « non applicable » (N/A). [signed_releases]
    Les résultats du projet incluent à la fois le code source et les produits livrés générés, le cas échéant (par exemple, les exécutables, les paquetages et les conteneurs). Les livrables générés PEUVENT être signés séparément du code source. Ces signatures PEUVENT être mises en œuvre sous forme de tags git signées (utilisant des signatures numériques cryptographiques). Les projets PEUVENT fournir des résultats générés séparément d'outils comme git, mais dans ce cas, les résultats distincts DOIVENT être signés séparément.

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


    Assez pour un badge !

    Il est PROPOSÉ que, dans le système de contrôle de la version, chaque tag d'une version importante (un tag faisant partie d'une version majeure, d'une version mineure ou qui corrige des vulnérabilités notées publiquement) soit cryptographiquement signé et vérifiable comme décrit dans 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>.


  • Autres problèmes de sécurité


    Assez pour un badge !

    Les résultats du projet DOIVENT vérifier toutes les entrées provenant de sources potentiellement non fiables pour s'assurer qu'elles sont valides (une liste blanche) et rejeter les entrées non valides, en cas de restrictions sur les données. [input_validation]
    Notez que la comparaison de l'entrée par rapport à une liste de « mauvais formats » (aussi appelée liste noire) n'est normalement pas suffisante, car les attaquants peuvent souvent contourner une liste noire. En particulier, les nombres sont convertis en formats internes puis vérifiés pour s'assurer s'ils se situent entre leur minimum et maximum (inclus), et les chaînes de texte sont vérifiées pour s'assurer qu'elles sont des motifs de texte valides (par exemple, UTF-8 valide, longueur valide, syntaxe valide, etc.). Certaines données peuvent avoir besoin d'être « du tout venant » (par exemple, un téléchargement de fichier), mais celles-ci sont généralement rares.

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


    Assez pour un badge !

    Les mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. [hardening]
    Les mécanismes de durcissement peuvent inclure des en-têtes HTTP comme Content Security Policy (CSP), des options de compilation pour atténuer les attaques (telles que -fstack-protector) ou des options de compilation pour éliminer les comportements indéfinis. Pour nos besoins, le principe de plus faible privilège n'est pas considéré comme un mécanisme de durcissement (le principe de plus faible privilège est important, mais séparé).

    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.


    Assez pour un badge !

    Le projet DOIT fournir une analyse de fiabilité qui justifie pourquoi ses exigences de sécurité sont respectées. L'analyse de fiabilité DOIT inclure : une description du modèle de menace, une identification claire des limites de confiance, un argument selon lequel des principes de conception sécurisés ont été appliqués et un argument selon lequel les faiblesses de sécurité courantes de l'implémentation ont été contrées. (URL requise) [assurance_case]
    Une analyse de fiabilité est « une preuve documentée qui fournit un argumentaire convaincant et correct selon lequel un ensemble spécifié de revendications critiques concernant les propriétés d'un système est adéquatement justifié pour une application donnée dans un environnement donné » (« Software Assurance Using Structured Assurance Case Models », Thomas Rhodes et al, NIST Interagency Report 7608). Les limites de confiance sont des limites où les données ou l'exécution modifient leur niveau de confiance, par exemple, les limites d'un serveur dans une application Web typique. Il est fréquent d'énumérer des principes de conception sécurisés (tels que Saltzer et Schroeer) et des faiblesses de sécurité courantes de l'implémentation (comme le OWASP top 10 ou le CWE/SANS top 25) et de montrer comment chacun est contré. L'analyse de fiabilité de BadgeApp peut être un exemple utile. Ceci est lié à documentation_security, documentation_architecture et 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).


 Analyse 2/2 ●

  • Analyse statique de code


    Assez pour un badge !

    Le projet DOIT utiliser au moins un outil d'analyse statique avec des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé, s'il existe au moins un outil FLOSS qui peut mettre en œuvre ce critère dans le langage sélectionné. [static_analysis_common_vulnerabilities]
    Les outils d'analyse statique spécialement conçus pour détecter les vulnérabilités les plus courantes sont plus susceptibles de les détecter. Cela dit, l'utilisation d'outils statiques aidera généralement à trouver des problèmes, nous suggérons donc, sans l'exiger, de le faire pour le badge de niveau « passant ».

    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


  • Analyse dynamique de code


    Assez pour un badge !

    Si le logiciel produit par le projet inclut un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple C ou C++), alors le projet DOIT utiliser au moins un outil dynamique (par exemple, un fuzzer ou un scanneur d'application Web) utilisé de manière routinière en combinaison avec un mécanisme permettant de détecter des problèmes de sécurité mémoire tels que les dépassement mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, sélectionnez « non applicable » (N/A). [dynamic_analysis_unsafe]
    Des exemples de mécanismes pour détecter les problèmes de sécurité de la mémoire comprennent Address Sanitizer (ASAN) (disponible dans GCC et LLVM), Memory Sanitizer et valgrind. D'autres outils potentiellement utilisés incluent thread sanitizer et undefined behavior sanitizer. La généralisation de l'utilisation des assertions fonctionnera également.

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



Vous pouvez utiliser des outils et des systèmes d'IA pour proposer des modifications via une URL simple, par exemple https://www.bestpractices.dev/fr/projects/14829/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consultez notre système de propositions d'automatisation pour savoir comment procéder. Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Bharat Joshi et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Bharat Joshi.
Soumission créée le 2026-09-25 00:58:39 UTC, dernière mise à jour le 2026-09-25 03:48:40 UTC. Le dernier badge obtenu l'a été le 2026-09-25 01:54:45 UTC.