Wrangle

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

    Prepare scientific data with native Polars, reusable YAML protocols, a readable CLI and reproducible evidence. Researchers and agents use the same checked preparation engine.

    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]

    CONTRIBUTING states acceptable researcher-focused changes, scientific declarations, coding rules, meaningful tests, documentation and review requirements. pyproject.toml specifies the enforced Ruff rules and exceptions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


  • Supervision du projet


    À peine suffisant 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 has no DCO or CLA mechanism for non-trivial contributions. Contributions use the existing MIT license through reviewed pull requests. A compulsory legal-origin attestation is not imposed by this modernization; its absence is a considered SHOULD limitation.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/LICENSE


    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 documents scope decisions, the lead maintainer, reviewer/contributor roles, release authority, disagreement handling and the process for governance changes.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/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.

    CODE_OF_CONDUCT defines respectful behavior, prohibited conduct, private reporting, maintainer investigation/enforcement and an appeal route. It applies across project participation spaces.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CODE_OF_CONDUCT.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.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 lists responsibilities and assignments for lead, reviewing and backup maintainers, contributors and security reporters. The lead is mikkokotila and the owner-confirmed backup is EnergyGuy3.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


    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]

    The project owner confirms EnergyGuy3 can handle issues, merges and GitHub releases within one week if the lead is unavailable. Existing GitHub administrator access was verified. GOVERNANCE records this affirmation; an independent rehearsal is not claimed or required by this criterion.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security/releases.md


    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 owner identifies mikkokotila as lead and EnergyGuy3 as a functioning backup with issue/merge/release continuity and secure-development expertise. GOVERNANCE records the two maintainer assignments and owner affirmation.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.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.

    ROADMAP gives dated October 2026 through September 2027 plans for researcher workflows, correctness and data preparation, with explicit excluded neural-network and generic infrastructure scope.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/ROADMAP.md


    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 shipped architecture document describes inspect/draft/prepare, expression compilation, validation, eager/disk execution, publication, evidence and the Python/CLI boundary. The agent entry file links exact engine and manual paths.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/architecture.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/AGENTS.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 shipped security requirements define accepted inputs, allowlists, unresolved-decision gates, integrity/publication guarantees and environment/resource limits. SECURITY defines supported versions and vulnerability handling.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md


    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 and shipped getting-started guide supply complete CLI and Python examples, expected results and the real-file guided path. Executable examples are verified in CI and against installed distributions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/human_workflow.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/start_workflow.py


    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 generated operation catalog is checked against engine definitions. Public CI executes all eight examples and installed-package workflows; the issue/PR templates match the current native preparation interface.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/build_catalog.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/verify_distribution.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/ISSUE_TEMPLATE/bug-report.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


    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 public README links the live OpenSSF Scorecard badge, published within forty-eight hours of assessment. Passing was awarded on 2026-10-01; the Best Practices badge is being published in the same session within its forty-eight-hour window. Evidence: https://github.com/autonomio/wrangle/blob/ae4ea7273889c39f4169ecdf7278f3f56c3be154/README.md https://www.bestpractices.dev/en/projects/15135


  • 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 CLI provides keyboard-operated plain-text prompts, named choices, stable readable errors and complete textual guides. Unicode scientific labels are supported and notebook tables have headers. This supports accessible common paths; no unperformed user trial or formal conformance audit is claimed.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_presentation.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md


    À peine suffisant 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 human CLI and manuals are English and lack a localization framework. The current research workflows prioritize a small consistent interface and language-independent stable error codes; Unicode labels and data are supported. This is a considered SHOULD limitation, not N/A.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_presentation.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md


  • 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 website/repository use GitHub, which the official Silver details explicitly state satisfies this password-storage criterion. Wrangle operates no additional password-authentication site.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md https://github.com/autonomio/wrangle https://www.bestpractices.dev/en/criteria/1?details=true&rationale=true#1.sites_password_security


 Contrôle des modifications 1/1 ●

 Compte-rendu 3/3 ●

 Qualité 19/19 ●

 Sécurité 13/13 ●

 Analyse 2/2 ●


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/15135/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 Mikko Kotila et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Mikko Kotila.
Soumission créée le 2026-10-01 15:20:31 UTC, dernière mise à jour le 2026-10-01 19:59:56 UTC. Le dernier badge obtenu l'a été le 2026-10-01 19:54:19 UTC.