docker-net-dhcp

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


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

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

        

 Notions de base 2/5 ●

  • Général

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

    Docker network plugin: containers get DHCP leases from the LAN. Modernized fork of devplayer0/docker-net-dhcp with macvlan attachment mode.

    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


    Pas assez pour un badge.

    Le projet DOIT atteindre un badge de niveau argent. [achieve_silver]

  • Supervision du projet


    Pas assez pour un badge.

    Le projet DOIT avoir un « facteur bus » 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 bus factor is 1. This is stated openly rather than glossed at https://github.com/claymore666/docker-net-dhcp/blob/main/GOVERNANCE.md — the project is single-maintainer today and explicitly invites co-maintainers.


    Pas assez pour un badge.

    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. (URL requise) [contributors_unassociated]
    Les contributeurs sont associés s'ils sont payés pour leur travail par la même organisation (en tant qu'employé ou contractuel) et si l'organisation bénéficie des résultats du projet. Les subventions financières ne comptent pas comme provenant de la même organisation si elles passent par d'autres organisations (par exemple, les subventions scientifiques versées à différentes organisations par un même gouvernement ou ONG ne rendent pas les contributeurs associés). Quelqu'un est un contributeur significatif s'il a apporté des contributions non triviales au projet au cours de la dernière année. Des exemples de bons indicateurs d'un contributeur significatif sont : écrit au moins 1 000 lignes de code, a contribué à 50 commits ou au moins 20 pages de documentation.

    The fork has one significant contributor. Outside contributions arrive as issues and occasional pull requests, but not at the level of two significant unassociated contributors.


  • Autre


    Assez pour un badge !

    Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet]. [license_per_file]
    Cela PEUT également être fait en incluant une déclaration en langage naturel identifiant la licence. Le projet PEUT également inclure une URL stable indiquant le texte de la licence ou directement le texte complet de la licence. Notez que le critère license_location requiert que la licence du projet soit dans un emplacement standard. Voir ce didacticiel SPDX pour plus d'informations sur les expressions de licence SPDX. Notez la relation avec copyright_per_file, dont le contenu devrait généralement précéder les informations sur la licence.

    Every source file in the repository carries "SPDX-License-Identifier: GPL-3.0-only" as its second comment line. The same gate, scripts/check-license-headers.sh, enforces it over the same set of files and rejects any other SPDX expression. The expression is GPL-3.0-only and not GPL-3.0-or-later because neither LICENSE.md here nor in devplayer0/docker-net-dhcp, the project this one succeeds, says "or any later version"; under GPLv3 section 14 that silence means only version 3 applies, and adopting -or-later would extend a permission the original authors never granted.


 Contrôle des modifications 3/4 ●

  • Dépôt source public sous contrôle de version


    Assez pour un badge !

    Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). [repo_distributed]
    Git n'est pas spécifiquement requis et les projets peuvent utiliser un logiciel de contrôle de version centralisé (comme subversion) avec justification.

    Repository on GitHub, which uses git. git is distributed.


    Pas assez pour un badge.

    Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. (URL requise) [small_tasks]
    Cette identification se fait typiquement en marquant les problèmes sélectionnés dans un outil de suivi de problèmes avec une ou plusieurs étiquettes que le projet utilise à cet effet, par exemple up-for-grabs, first-timers-only, « Small fix », microtask ou IdealFirstBug. Ces nouvelles tâches n'ont pas besoin d'ajouter des fonctionnalités ; elles peuvent améliorer la documentation, ajouter des cas de test ou toute autre chose qui aide le projet et aide le contributeur à en comprendre davantage sur le projet.

    Unmet today. The tracker carries a good first issue label and it was seeded with self-contained starter tasks, each stating the gap, the file to look at and the command that verifies the fix. Those were closed as the work they described landed, and no unclaimed work currently qualifies: the project's own standard is that a starter task is a real gap found during ordinary work, not one invented to carry the label, and inventing three would satisfy this criterion by making the claim false in a different way. The README's Contributing section says so plainly and, instead of linking a filter that returns nothing, sends a newcomer to the repository's Q&A discussions, which is a route that exists: it is published as a contact link on the new-issue chooser, and neither issue form fits the request because each stamps a type label that would be wrong for it. This answer is enforced, not remembered: scripts/check-good-first-issues.sh binds the status, the README's promise, the ask route and the label's open count to each other in both directions, so it goes red the day a genuine starter task is filed and this answer becomes Met again, and red too if the route the README names stops being one the repository offers.


    Assez pour un badge !

    Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. [require_2FA]

    Two-factor authentication is enabled and enforced on the only account with write access to the repository and with access to private vulnerability reports; the GitHub API reports two_factor_authentication as true. Two factors are registered: a WebAuthn passkey and a TOTP application. No bot or machine account bypasses it.


    Assez pour un badge !

    L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. [secure_2FA]
    Un mécanisme 2FA qui répond à ce critère serait une application de mot de passe à usage unique basé sur le temps (TOTP) qui génère automatiquement un code d'authentification qui change après un certain laps de temps. Notez que GitHub prend en charge TOTP.

    Both registered factors use cryptographic mechanisms. The primary is a WebAuthn passkey, which is public-key based and phishing-resistant; a TOTP application is registered as the fallback, which the criterion also accepts. SMS-based 2FA is not used.


 Qualité 4/7 ●

  • Normes de codage


    Assez pour un badge !

    Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. (URL requise) [code_review_standards]
    Voir aussi two_person_review et contribution_requirements.

    What a change must satisfy to be acceptable is documented for contributors — target branch, coding standard, test expectations, authorship rule, and the full set of checks that must be green before merge — at https://github.com/claymore666/docker-net-dhcp#contributing, with a pull request template that restates the checklist. Branch protection enforces the mechanical half of that review on every pull request.


    Pas assez pour un badge.

    Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. [two_person_review]

    Honestly unmet: with a single maintainer, changes cannot be reviewed before release by a person other than the author. Automated review substitutes as far as it can — required unit, staticcheck, live integration, govulncheck, actionlint, and attribution checks on every pull request, plus CodeQL — but that is not a second human reviewer.


  • Système de construction opérationnel


    Assez pour un badge !

    Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). (URL requise) [build_reproducible]
    Une construction reproductible signifie que plusieurs parties peuvent refaire indépendamment le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Dans certains cas, cela peut être résolu en forçant un ordre de tri. Les développeurs JavaScript peuvent envisager d'utiliser npm shrinkwrap et webpack OccurenceOrderPlugin. Les utilisateurs GGC et clang peuvent trouver l'option -frandom-seed utile. L'environnement de construction (y compris le jeu d'outils) peut souvent être défini pour les parties externes en spécifiant le hachage cryptographique d'un conteneur spécifique ou d'une machine virtuelle qu'ils peuvent utiliser pour la reconstruction. Le projet de construction reproductible dispose de documentation sur la façon de le faire.

    A published procedure lets anyone reproduce the build and check a release against it: https://claymore666.github.io/docker-net-dhcp/verifying-releases/#rebuilding-the-binaries-yourself . Verified end to end rather than self-checked: rebuilding the v1.4.0 tag from a clean git archive, on a BuildKit builder created fresh so no cache mount could be shared, produced binaries whose SHA-256 exactly match the ones inside the published v1.4.0 release tarball (net-dhcp 0ac36b87391c5bd5ea7a4b268183ca3fd86c686bf9b5d0505b97c4e0780d710b, dhcp-handler 0eb5b698698f2d8f4e997062c77f295726915c9ba31125db1800e602edfa4bf8). Determinism rests on digest-pinned base images, version-pinned Alpine packages, a fixed in-container build path, and no timestamp or VCS stamping. It is enforced, not asserted: the Reproducible build workflow builds the same commit twice on two cold builders and fails if the binaries differ, weekly and on any pull request touching the Dockerfile or the Go module files. Scope, stated plainly: the reproducible outputs are the compiled binaries. The release tarball itself is not byte-reproducible because tar and gzip record modification times, so the documented procedure compares the binaries extracted from that tarball rather than the tarball digest.


  • Suite de tests automatisée


    Assez pour un badge !

    Une suite de tests DOIT être invocable d'une manière standard pour ce langage. (URL requise) [test_invocation]
    Par exemple, « make check », « mvn test » ou « rake test » (Ruby).

    The unit suite is invoked the standard Go way: go test ./.... That is literally what CI runs (as go test -race -count=1 ./...); see the test job in https://github.com/claymore666/docker-net-dhcp/blob/main/.github/workflows/test.yaml . The live integration suites cannot be invoked that way, because they need root and a real Docker daemon to install the plugin against; they are invoked as sudo make integration-local, which rebuilds the plugin, installs it and runs both the main and the failure suite; see the integration-local target in https://github.com/claymore666/docker-net-dhcp/blob/main/Makefile . Both invocations are documented for contributors under "Running the tests": https://claymore666.github.io/docker-net-dhcp/latest/internals/#running-the-tests .


    Assez pour un badge !

    Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. (URL requise) [test_continuous_integration]
    Dans la plupart des cas, cela signifie que chaque développeur qui travaille à plein temps sur le projet intègre son code au moins tous les jours.

    Every push and every pull request to the integration branches runs the full gate on GitHub Actions: unit tests with the race detector, staticcheck, actionlint, govulncheck, CodeQL, a dependency review, and the live integration suites against a real DHCP server on a self-hosted runner. Workflow definitions: https://github.com/claymore666/docker-net-dhcp/tree/main/.github/workflows ; run history: https://github.com/claymore666/docker-net-dhcp/actions . The checks are required by branch protection on both integration branches, so a change cannot merge without them, and release pull requests additionally run a coverage ratchet that fails on any per-package regression. A weekly scheduled run repeats the gate so vulnerabilities published between commits surface without waiting for the next push.


    Pas 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 90% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage90]

    Measured merged unit-plus-integration statement coverage is 85.8 percent as a statement-weighted total over the shipped packages (pkg/plugin 85.0 percent of 1811 statements, pkg/dhcp 89.9 of 338, pkg/util 98.5 of 78, cmd/net-dhcp 76.4 of 72, cmd/dhcp-handler 75.0 of 16). That clears the silver threshold of 80 percent but not the gold threshold of 90. Per-package floors are enforced by a coverage ratchet at release time and are raised as error-path tests land.


    Pas assez pour un badge.

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture de branche d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_branch_coverage80]

    Branch coverage is not measured. The Go toolchain's coverage support reports statement coverage, which is what the project's ratchet gate enforces; no branch-coverage figure is available to substantiate this criterion.


 Sécurité 3/5 ●

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

    Pas assez pour un badge.

    Le logiciel produit par le projet DOIT 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 DOIVENT ê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]

    Honestly unmet, and structurally so: the plugin's purpose is to obtain addresses from the LAN's existing DHCP server, and DHCP (v4 and v6) has no encrypted variant to prefer or fall back to. Its other communication channel is the local Docker Unix socket, which does not traverse a network. SECURITY.md documents the resulting residual risk — a hostile DHCP server can hand out bad addressing — as accepted and outside the plugin's control.


    Assez pour un badge !

    Le logiciel produit par le projet DOIT, 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 neither supports nor uses TLS.


  • Livraison sécurisée contre les attaques man-in-the-middle (MITM)


    Pas assez pour un badge.

    Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. (URL requise) [hardened_site]
    Notez que GitHub et GitLab sont connus pour le faire. Des sites tels que https://securityheaders.com/ peuvent le vérifier rapidement. Les en-têtes clés de durcissement sont : Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (comme « nosniff ») et X-Frame-Options. Les sites Web complètement statiques sans possibilité de se connecter à travers les pages Web peuvent éventuellement omettre certains entêtes de durcissement avec moins de risques, mais il n'existe aucune manière fiable de détecter ces sites, donc nous exigeons ces en-têtes mêmes pour les sites complètement statiques.

    The repository and release download sites are GitHub and GHCR, which do send hardening headers including CSP and HSTS. The project documentation site is GitHub Pages, which serves static content without configurable response headers, so the project cannot add hardening headers there. Unmet rather than N/A, because the shortfall is real even though it is not fixable on the current hosting.


  • Autres problèmes de sécurité


    Assez pour un badge !

    Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. [security_review]
    Cela PEUT être fait par les membres du projet et/ou une évaluation indépendante. Cette évaluation PEUT être soutenue par des outils d'analyse statiques et dynamiques, mais il doit aussi y avoir une revue par des humains pour identifier les problèmes (en particulier dans la conception) que les outils ne peuvent pas détecter.

    A security review of this fork was performed and written up as the assurance case in https://github.com/claymore666/docker-net-dhcp/blob/main/SECURITY.md#security-assurance-case — it states the security goals, enumerates the adversaries (malicious container, hostile LAN DHCP server, supply-chain tampering), identifies the trust boundary around DHCP-server-supplied bytes and the privileged plugin process, and argues why the mitigations suffice, closing with the accepted residual risk. It is re-read as part of the release documentation review. Continuous automated review runs alongside it: CodeQL, govulncheck, staticcheck, and Dependency Review on every pull request.


    Assez pour un badge !

    Des 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é. (URL requise) [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 plugin is written in Go, a memory-safe language, and imports the unsafe package in zero source files, so entire classes of memory-corruption defects cannot occur. The race detector runs over the unit suite in CI, the untrusted parsers are fuzzed on every pull request, and the plugin requests an explicit, minimal capability set in config.json rather than running fully privileged — the daemon shows that set to the user before installation. See https://github.com/claymore666/docker-net-dhcp/blob/main/SECURITY.md#security-assurance-case


 Analyse 2/2 ●

  • Analyse dynamique de code


    Assez pour un badge !

    Le projet DOIT appliquer au moins un outil d'analyse dynamique à tout candidat pour une version majeure du logiciel produit par le projet avant sa sortie. [dynamic_analysis]
    Un outil d'analyse dynamique examine le logiciel en l'exécutant avec des entrées spécifiques. Par exemple, le projet PEUT utiliser un outil de fuzzing (par exemple, American Fuzzy Lop) ou un scanner d'application Web (par exemple, OWASP ZAP ou w3af). Dans certains cas, le projet OSS-Fuzz peut être prêt à appliquer des tests de fuzzing à votre projet. Aux fins de ce critère, l'outil d'analyse dynamique doit varier les entrées d'une manière ou d'une autre pour rechercher différents types de problèmes ou être une suite de test automatisée avec au moins 80% de couverture de branche. La page Wikipedia sur l'analyse dynamique et la page OWASP sur le fuzzing identifient certains outils d'analyse dynamique. Le ou les outils d'analyse PEUVENT être axés sur la recherche de vulnérabilités de sécurité, mais cela n'est pas nécessaire.

    live integration suite + -race + native fuzzing


    Assez pour un badge !

    Le projet DEVRAIT inclure de nombreuses assertions à l'exécution dans le logiciel qu'il produit, et vérifier ces assertions lors d'une analyse dynamique. [dynamic_analysis_enable_assertions]
    Ce critère ne suggère pas d'activer les assertions en production ; c'est entièrement au projet et à ses utilisateurs de le décider. L'objectif de ce critère est plutôt d'améliorer la détection des défauts lors de l'analyse dynamique avant le déploiement. L'activation des assertions en production est complètement différente de l'activation des assertions pendant l'analyse dynamique (comme les tests). Dans certains cas, il est extrêmement imprudent d'activer les assertions en production (en particulier dans les composants à haute intégrité). Il existe de nombreux arguments contre l'activation des assertions en production, par exemple, les bibliothèques ne devraient pas faire échouer les appelants, leur présence peut provoquer le rejet par les magasins d'applications et/ou l'activation d'une assertion en production peut exposer des données privées telles que des clés privées. Attention, dans de nombreuses distributions Linux, NDEBUG n'est pas défini, donc assert() sera activé par défaut en C/C++ pour la production dans ces environnements. Il peut être important d'utiliser un mécanisme d'assertion différent ou de définir NDEBUG pour la production dans ces environnements.

    -race detector + fuzz targets are runtime-assertion mechanisms



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

Soumission du badge du projet appartenant à : Chris.
Soumission créée le 2026-06-14 12:10:55 UTC, dernière mise à jour le 2026-09-28 18:09:32 UTC. Le dernier badge obtenu l'a été le 2026-06-14 13:17:33 UTC.