Cross-Border Stablecoin Register (CBSR)

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 14172 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/14172/badge)](https://www.bestpractices.dev/projects/14172)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/14172"><img src="https://www.bestpractices.dev/projects/14172/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.

    CBSR is an open, versioned, machine-readable register of stablecoin regulation across twelve jurisdictions, with a deterministic policy engine for evidence-bound cross-border research. Records distinguish claim type, legal status, provenance, source disposition, freshness and independent review. Policy evaluations are decision support only: execution_authorized remains false. The 20 August 2026 snapshot contains 152 records and 46 structural candidates, with 0 strictly citable current-law records; those counts are not verified current-law coverage. The software is Apache-2.0 and the dataset is CC-BY-4.0. Release assets and available archival identifiers are linked from the repository; an archive DOI is not claimed for every tag.

    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.

    Scope note for reviewers: this project produces two artifacts under two
    licenses. The software (src/cbsr_mcp/, tools/, scripts/, build*.py)
    is Apache-2.0 and is what these criteria are answered against. The dataset
    (*.yaml, dataset.json, analysis/, api/) is CC-BY-4.0; CC-BY-4.0 is not
    OSI-approved and is not claimed as a FLOSS software license. See LICENSING.md.

    The project uses cryptographic hashing (SHA-256) for artifact checksums and
    tamper-evident decision receipts. It performs no encryption, no key agreement,
    no key generation, and no password storage. Receipts detect mutation only;
    they are not signatures. Crypto criteria are answered on that basis.

  • 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]

    CONTRIBUTING.md states the requirements for an acceptable contribution: a
    record must be schema-valid, must cite a primary source with a pinpoint that
    the contributor has verified personally, and must pass the single canonical
    gate python -m tools.verify with no committed-output drift across two
    generation passes. Draft records carrying <VERIFY markers are accepted but are
    merged as drafts, not as verified coverage. Dependency changes additionally
    require a passing Linux Python 3.10-3.13 matrix and a Windows clean-room job.
    The sourcing rule is in METHODOLOGY.md.
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/CONTRIBUTING.md


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

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CONTRIBUTING.md


    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.

    GOVERNANCE.md documents the project's decision-making model, the accountable maintainer, contributor responsibilities, review and verification stages, merge and release decisions, amendment process, licensing boundary, and conflict-of-interest safeguards. It explicitly distinguishes committed workflow declarations from separately configured repository enforcement.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/GOVERNANCE.md


    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 root CODE_OF_CONDUCT.md requires professional and evidence-based participation, prohibits harassment, discrimination, threats, doxxing and privacy violations, defines maintainer enforcement powers, and provides a confidential reporting route with conflict disclosure and protection against retaliation.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/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.

    GOVERNANCE.md identifies Yunjie Fan as the accountable maintainer and defines responsibilities for data integrity, verification standards, releases and charter enforcement. It also defines contributor and review responsibilities. CODEOWNERS maps repository areas to the responsible maintainer account; this is a responsibility map, not evidence of a second maintainer or completed independent review.

    Evidence:


    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]

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/GOVERNANCE.md#7-amendment-and-continuity


    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.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/security/OPENSSF_GOLD.md


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

    Section 25 of the architecture white paper documents a three-year roadmap: year one addresses official-source, freshness, review and engineering-governance gaps; year two considers reviewed domain packs and authenticated/signed receipts in controlled pilots; year three evaluates adoption, interoperability, redress and longitudinal outcomes. These phases are conditional on evidence and governance approval. The Charter documents continuing non-goals and scope boundaries, including no unsupported claims or predictions and depth before breadth.

    Evidence:


    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.

    Paste-ready justification:

    ADR 0001 documents the high-level architecture and responsibilities of the typed core, offline data loader, evidence and event layers, stablecoin domain pack, canonical serialization, public API projections, tool registry and server composition root. It describes interface versioning, compatibility boundaries and the separation between generic policy models and domain-specific rules.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/adr/0001-modular-mcp-policy-boundaries.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.

    SECURITY.md and the threat model state the software's security requirements and limitations: offline decision support, fail-closed evidence handling, no transaction execution or key custody, and execution_authorized always false. They distinguish mutation-detecting hashes from signatures and document supply-chain checks, release hard stops and residual human-review limitations.

    Evidence:


    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 README provides isolated-environment setup and the canonical verification command. CONNECT_MCP.md provides prerequisites, source installation, copy-paste client configurations and initial example queries, and also describes a zero-setup static JSON API. Platform and hash-lock limitations are explicitly documented.

    Evidence:


    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 enforces many generated documentation and identifier consistency checks, but known inconsistencies remain. ROADMAP.md still labels v0.10.0 as current, and the compatibility matrix still describes hosted Linux and Windows evidence as unverified despite newer published successful runs. These documents must be corrected or clearly labelled as historical before this criterion is marked Met.

    Evidence:


    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.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/README.md


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

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/index.html


    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.

    The software consistently supports UTF-8 input/output and non-UTF-8 console environments, but its user-facing Register interface and many messages remain hard-coded in English without a localization resource layer. Unicode portability and a separate bilingual landing page do not by themselves establish internationalization of the produced software.

    Evidence:


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

    CBSR's project-operated website and public data/download interfaces are static and do not implement external-user accounts or store user passwords. Repository and issue-tracker authentication is provided by GitHub, which the official criterion's detailed guidance identifies as meeting this requirement. CBSR does not handle or store GitHub account credentials. This answer covers the project sites and does not assert that CBSR implements its own password-storage system.

    Evidence:


 Contrôle des modifications 1/1 ●

 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 the GitHub issue tracker for individual issues, with issue
    templates configured in .github/ISSUE_TEMPLATE/.
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/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]

    The available public evidence does not establish the complete set of vulnerability reports resolved during the previous 12 months or whether every reporter received the requested credit or anonymity. The maintainer must check the private reporting and remediation records before selecting Met or N/A. An empty public advisory list or a clean dependency audit does not establish that no reports were resolved.

    Evidence:


    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.

    SECURITY.md documents confidential reporting, required report information, a protected-channel fallback, acknowledgement within three business days, initial triage within seven business days, coordinated disclosure with a default 90-day target, and completion checks for regression tests, dependency/security gates, checksums and advisories. These are documented response targets, not a claim that every historical report met them.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/SECURITY.md#response-expectations-and-coordinated-disclosure


 Qualité 19/19 ●

 Sécurité 13/13 ●

 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's default Python query suite includes rules for common vulnerability classes in the language and environment, including injection, path traversal and unsafe deserialization.


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

    N/A: the project produces no software written in a memory-unsafe language. The implementation is pure Python.



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/14172/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 yunjiefanresearch-hub et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : yunjiefanresearch-hub.
Soumission créée le 2026-08-20 07:54:43 UTC, dernière mise à jour le 2026-09-28 05:52:56 UTC. Le dernier badge obtenu l'a été le 2026-08-20 10:57:39 UTC.