openbao-operator

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


Ce sont les critères du niveau Basique. Vous pouvez également afficher les critères des niveaux Argent 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 13/13 ●

  • Général

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

    OpenBao Operator automates the deployment and operation of OpenBao clusters on Kubernetes. It manages configuration, TLS certificates, backups, restores and upgrades, with controls for tenant isolation.

    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.

  • Contenu basique du site Web du projet


    Assez pour un badge !

    Le site du projet DOIT décrire succinctement ce que le logiciel fait (quel problème résout-il ?). [description_good]
    Cela DOIT être dans un langage que les utilisateurs potentiels peuvent comprendre (par exemple, il utilise un jargon minimal).

    The README explains how the operator manages OpenBao clusters on Kubernetes, including setup, security, backups, restores, and upgrades.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/README.md#L8-L36


    Assez pour un badge !

    Le site Web du projet DOIT fournir des informations sur la façon d'obtenir, de fournir des commentaires (comme des signalements de bogues ou des demandes d'amélioration) et de contribuer au logiciel. [interact]

    Our guides cover installation, bug reports, feature requests, and contributing. We use GitHub Issues and Discussions to work with users and contributors.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/docs/get-started/install.md#L1-L36
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/contribute/_index.md#L17-L44


    Assez pour un badge !

    L'information sur la façon de contribuer DOIT expliquer le processus de contribution (par exemple, les pull requests sont-ils utilisés ?) (URL requise) [contribution]
    Nous supposons que les projets sur GitHub utilisent les problèmes et les pull requests, sauf indication contraire. Cette information peut être courte, par exemple, en indiquant que le projet utilise les pull requests, un suivi des problèmes ou des messages dans une liste de diffusion (laquelle ?)

    We accept contributions through GitHub pull requests. The contribution guide explains how to set up the project, prepare a change, and run the checks.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/contribute/_index.md#L17-L44


    Assez pour un badge !

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

    Our contributor guide links to the coding standards and testing requirements for pull requests.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/contribute/standards.md#L14-L73
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/contribute/testing.md#L16-L53


  • Licence FLOSS


    Assez pour un badge !

    Le logiciel produit par le projet DOIT être distribué en tant que FLOSS. [floss_license]
    FLOSS est un logiciel distribué d'une manière qui répond à la Définition de l'Open Source ou à la Définition du Logiciel Libre. Des exemples de ces licences sont CC0, MIT, BSD 2-clause, BSD 3-clause révisée, Apache 2.0, Lesser GNU General Public License (LGPL), et GNU General Public License (GPL). Pour nos besoins, cela signifie que la licence DOIT être : Le logiciel PEUT également être distribué avec d'autres licences (par exemple, « GPLv2 ou propriétaire » est acceptable).

    We release OpenBao Operator under Apache-2.0. The license is included in the repository.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/LICENSE#L1-L20


    Assez pour un badge !

    Il est PROPOSÉ que toute licence requise pour le logiciel produit par le projet soit approuvée par l'Open Source Initiative (OSI). [floss_license_osi]
    L'OSI utilise un processus d'approbation rigoureux pour déterminer quelles licences sont OSS.

    Apache-2.0 is approved by the Open Source Initiative.

    https://opensource.org/license/apache-2-0


    Assez pour un badge !

    Le projet DOIT afficher la ou les licences de ses résultats dans un emplacement standard dans leur dépôt source. (URL requise) [license_location]
    Une convention est de publier la licence sous la forme d'un fichier à la racine du dépôt appelé LICENSE ou COPYING, qui PEUT être suivi d'une extension telle que « .txt » ou « .md ». Une autre convention est d'avoir un réportoire nommé LICENSES contenant le(s) fichier(s) de licence ; ces fichiers sont généralement nommés comme leur identifiant de licence SPDX suivi d'une extension de fichier appropriée, comme décrit dans la Spécification REUSE. Notez que ce critère est requis uniquement pour le dépôt de sources. Vous n'avez PAS besoin d'inclure le fichier de licence lors de la génération d'un élément à partir du code source (tel qu'un exécutable, un paquet ou un conteneur). Par exemple, lors de la génération d'un paquet R pour le réseau d'archives complet R (CRAN), suivez la procédure standard CRAN : si la licence est une licence standard, utilisez la spécification de standard courte (pour éviter d'installer une autre copie du texte) et listez le fichier LICENSE dans un fichier d'exclusion tel que .Rbuildignore. De même, lors de la création d'un paquet Debian, vous pouvez mettre un lien dans le fichier de copyright vers le fichier de licence dans /usr/share/common-licenses, et exclure le fichier de licence du paquet créé (par exemple, en supprimant le fichier après avoir appelé dh_auto_install). Nous encourageons fortement l'inclusion d'informations de licence lisibles automatiquement dans des formats générés lorsque cela est possible.

    The license is in the repository's top-level LICENSE file.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/LICENSE#L1-L20


  • Documentation


    Assez pour un badge !

    Le projet DOIT fournir une documentation de base pour le logiciel produit par le projet. [documentation_basics]
    Cette documentation doit se trouver dans un certain format (comme le texte ou la vidéo) qui comprend : comment l'installer, comment le démarrer, comment l'utiliser (éventuellement avec un tutoriel à l'aide d'exemples) et comment l'utiliser en toute sécurité (par exemple, quoi faire et ne pas faire) si c'est un sujet approprié pour le logiciel. La documentation de sécurité n'a pas besoin d'être longue. Le projet PEUT utiliser des liens hypertextes vers du matériel hors projet en tant que documentation. Si le projet ne produit pas de logiciel, choisissez « non applicable » (N/A).

    Our documentation covers installation, configuration, day-to-day operation, and security. It also explains the security profiles and tenant boundaries.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/docs/get-started/install.md#L1-L36
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/docs/security/_index.md#L31-L51
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/docs/security/tenant-boundaries.md#L30-L71


    Assez pour un badge !

    Le projet DOIT fournir une documentation de référence qui décrit l'interface externe (entrée et sortie) du logiciel produit par le projet. [documentation_interface]
    La documentation d'une interface externe explique à un utilisateur final ou un développeur comment l'utiliser. Cela inclut son interface de programmation (API) si le logiciel en possède une. S'il s'agit d'une bibliothèque, documentez les principales classes / types et méthodes / fonctions pouvant être appelés. S'il s'agit d'une application Web, définissez son interface URL (souvent son interface REST). S'il s'agit d'une interface de ligne de commande, documentez les paramètres et les options qu'elle supporte. Dans de nombreux cas, il est préférable que la majorité de cette documentation soit générée automatiquement, de sorte que cette documentation reste synchronisée avec le logiciel au fur et à mesure qu'il change, mais cela n'est pas nécessaire. Le projet PEUT utiliser des liens hypertextes vers du matériel hors projet en tant que documentation. La documentation PEUT être générée automatiquement (quand c'est possible, c'est souvent la meilleure façon de le faire). La documentation d'une interface REST peut être générée à l'aide de Swagger / OpenAPI. La documentation de l'interface de code PEUT être générée à l'aide d'outils tels que JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) et Doxygen (plusieurs). Le simple fait d'avoir des commentaires dans le code source n'est pas suffisant pour satisfaire ce critère ; il doit y avoir un moyen simple de voir l'information sans lire l'intégralité du code source. Si le projet ne produit pas de logiciel, choisissez « non applicable » (N/A).

    We publish a generated reference for the Kubernetes custom-resource API, including configuration fields and status outputs.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/docs/reference/api/openbaocluster.md#L1-L24


  • Autre


    Assez pour un badge !

    Les sites du projet (site Web, dépôt et URLs de téléchargement) DOIVENT supporter HTTPS en utilisant TLS. [sites_https]
    Cela nécessite que l'URL de la page d'accueil du projet et l'URL du référentiel de contrôle de version commencent par « https: » et non par « http: ». Vous pouvez obtenir des certificats gratuits de Let's Encrypt. Les projets PEUVENT mettre en œuvre ce critère en utilisant (par exemple) des pages GitHub, des pages GitLab ou des pages de projet SourceForge. Si vous prenez en charge HTTP, nous vous invitons à rediriger le trafic HTTP vers HTTPS.

    Our website, source repository, release downloads, container images, and Helm chart are available over HTTPS.

    https://docs.kubebao.org/
    https://github.com/kubebao/openbao-operator/releases/tag/0.5.2
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/docs/get-started/install.md#L123-L140


    Assez pour un badge !

    Le projet DOIT avoir un ou plusieurs mécanismes de discussion (y compris les changements et les problèmes proposés) qui peuvent être recherchés, permettent de désigner les messages et les sujets par une URL, permettent aux nouvelles personnes de participer à certaines des discussions et ne nécessitent pas d'installation côté client de logiciels propriétaires. [discussion]
    Parmi les exemples de mécanismes acceptables figurent les listes de diffusion archivées, les problèmes de GitHub et les discussions sur les pull requests, Bugzilla, Mantis et Trac. Les mécanismes de discussion asynchrones (comme IRC) sont acceptables s'ils répondent à ces critères ; assurez-vous qu'il existe un mécanisme d'archivage adressable par URL. Une solution propriétaire en JavaScript, tout en étant découragée, est autorisée.

    We use GitHub Issues, pull requests, and Discussions. These are public, searchable, and accessible in a web browser.

    https://github.com/kubebao/openbao-operator/issues
    https://github.com/kubebao/openbao-operator/discussions


    Assez pour un badge !

    Le projet DEVRAIT fournir de la documentation en anglais et être en mesure d'accepter les signalements de bogues et les commentaires sur le code en anglais. [english]
    L'anglais est actuellement la langue véhiculaire des technologies informatiques ; l'utilisation de l'anglais augmente le nombre de développeurs et de relecteurs potentiels dans le monde entier. Un projet peut répondre à ce critère même si la langue principale de ses principaux développeurs n'est pas l'anglais.

    We write the documentation and contributor guides in English and accept bug reports and code comments in English.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/README.md#L8-L36
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/CONTRIBUTING.md#L1-L32


    Assez pour un badge !

    Le projet DOIT être maintenu. [maintained]
    Au minimum, le projet doit tenter de répondre aux rapports de problèmes et de vulnérabilités importants. Un projet qui poursuit activement un badge est probablement maintenu. Tous les projets et tous les individus ont des ressources limitées, et les projets typiques doivent rejeter certaines modifications proposées, de sorte que les ressources limitées et les rejets de propositions n'indiquent pas en eux-mêmes un projet non maintenu.

    Lorsqu'un projet sait qu'il ne sera plus maintenu, il doit définir ce critère comme « Non satisfait » et utiliser le(s) mécanisme(s) approprié(s) pour indiquer aux autres qu'il n'est pas maintenu. Par exemple, utiliser « DEPRECATED » comme premier en-tête de son fichier README, ajouter « DEPRECATED » au début de sa page d'accueil, ajouter « DEPRECATED » au début de la description de projet de son dépôt de code, ajouter un badge sans maintenance dans son README et/ou sa page d'accueil, le marquer comme obsolète dans tous les dépôts de paquets (par exemple, npm deprecate), et/ou utiliser le système de marquage du dépôt de code pour l'archiver (par exemple, le paramètre « archive » de GitHub, le marquage « archivé » de GitLab, le statut « lecture seule » de Gerrit ou le statut de projet « abandonné » de SourceForge). Une discussion supplémentaire peut être trouvée ici.

 Contrôle des modifications 9/9 ●

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


    Assez pour un badge !

    Le projet DOIT avoir un dépôt source sous contrôle de version qui est publiquement lisible et possède une URL. [repo_public]
    L'URL PEUT être identique à l'URL du projet. Le projet PEUT utiliser des branches privées (non publiques) dans des cas spécifiques alors que la modification n'est pas diffusée publiquement (par exemple, pour la correction d'une vulnérabilité avant qu'elle ne soit révélée au public).

    Our Git repository is public on GitHub.

    https://github.com/kubebao/openbao-operator


    Assez pour un badge !

    Le dépôt source du projet DOIT suivre les changements apportés, qui a effectué les changements et quand les changements ont été effectués. [repo_track]

    Git records each change, its author, and its date. Commits and diffs are public on GitHub.

    https://github.com/kubebao/openbao-operator/commits/main/


    Assez pour un badge !

    Pour permettre une analyse collaborative, le dépôt source du projet DOIT inclure des versions provisoires pour examen entre versions officielles ; Il NE DOIT PAS inclure que les dernières versions. [repo_interim]
    Les projets PEUVENT choisir d'omettre des versions intermédiaires spécifiques dans leurs dépôts source publics (par exemple, celles qui corrigent des vulnérabilités de sécurité non publiques spécifiques, ne peuvent jamais être rendues publiques ou incluent des éléments qui ne peuvent être légalement publiés et ne sont pas dans la version finale).

    We publish development commits and pull requests between releases.

    https://github.com/kubebao/openbao-operator/commits/main/
    https://github.com/kubebao/openbao-operator/pulls


    Assez pour un badge !

    Il est PROPOSÉ qu'un logiciel reconnu de contrôle de version distribué soit utilisé (par exemple, git) pour le dépôt source du projet. [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.

    We use Git and host the repository on GitHub.

    https://github.com/kubebao/openbao-operator


  • Numérotation unique de la version


    Assez pour un badge !

    Les résultats du projet DOIVENT avoir un identifiant de version unique pour chaque version destinée à être utilisée par les utilisateurs. [version_unique]
    Cela PEUT être satisfait de diverses façons, y compris les identifiants de commit (comme git commit id ou mercure changeset id) ou un numéro de version (y compris les numéros de version qui utilisent la version sémantique ou les systèmes basés sur la date comme YYYYMMDD).

    Each release has a unique version number and Git tag.

    https://github.com/kubebao/openbao-operator/releases


    Assez pour un badge !

    Il est PROPOSÉ d'utiliser le format de numérotation de version appelé Versionage Sémantique (SemVer) ou Versionage Calendaire (CalVer). Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro. [version_semver]
    Les projets devraient généralement préférer le format attendu par leurs utilisateurs, par exemple, parce que c'est le format normal utilisé par leur écosystème. De nombreux écosystèmes préfèrent SemVer, et SemVer est généralement préféré pour les interfaces de programmation d'applications (API) et les kits de développement logiciel (SDK). CalVer a tendance à être utilisé par des projets de grande envergure, ayant un nombre inhabituellement élevé de dépendances développées indépendamment, ayant une portée en constante évolution ou étant sensibles au temps. Il est PROPOSÉ que ceux qui utilisent CalVer incluent une valeur de niveau micro, car l'inclusion d'un niveau micro prend en charge les branches maintenues simultanément chaque fois que cela devient nécessaire. D'autres formats de numérotation de version peuvent être utilisés, y compris les ID de commit git ou les ID de jeu de modifications mercurial, à condition qu'ils identifient de manière unique les versions. Cependant, certaines alternatives (telles que les ID de commit git) peuvent poser des problèmes en tant qu'identificateurs de version, car les utilisateurs peuvent ne pas être en mesure de déterminer facilement s'ils sont à jour. Le format de l'ID de version peut être sans importance pour l'identification des versions logicielles si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue).

    We use Semantic Versioning for stable releases and prerelease identifiers for development builds.

    https://github.com/kubebao/openbao-operator/releases
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/website/content/contribute/release.md#L128-L148


    Assez pour un badge !

    Il est PROPOSÉ que les projets identifient chaque version dans leur système de contrôle de version. Par exemple, il est PROPOSÉ que ceux qui utilisent git identifient chaque version à l'aide des tags de git. [version_tags]

    We tag releases in Git. For example, 0.5.2 has an annotated tag pointing to its source commit.

    https://github.com/kubebao/openbao-operator/releases/tag/0.5.2


  • Notes de version


    Assez pour un badge !

    Le projet DOIT fournir, avec chaque distribution, des notes de version qui sont un résumé lisible par les humains des changements majeurs dans cette version afin d'aider les utilisateurs à déterminer s'ils doivent se mettre à niveau et quel sera l'impact de la mise à niveau. Les notes de version NE DOIVENT PAS être la sortie brute d'un journal de contrôle de version (par exemple, les résultats de la commande « git log » ne sont pas des notes de version). Les projets dont les résultats ne sont pas destinés à être réutilisés dans plusieurs emplacements (tels que le logiciel pour un site Web ou un service unique) ET qui utilisent la livraison continue PEUVENT sélectionner « N/A ». (URL requise) [release_notes]
    Les notes de version PEUVENT être mises en œuvre de différentes façons. De nombreux projets les fournissent dans un fichier nommé « NEWS », « CHANGELOG » ou « ChangeLog », éventuellement avec des extensions telles que « .txt », « .md » ou « .html ». Historiquement, le terme « journal des modifications » signifiait un enregistrement de chaque changement, mais pour répondre à ces critères, il faut un résumé lisible par un humain. Les notes de version PEUVENT être fournies à la place par des mécanismes de système de contrôle de version tels que le GitHub Releases workflow.

    We publish release notes on GitHub with the changes and upgrade information for each release.

    https://github.com/kubebao/openbao-operator/releases/tag/0.5.2


    Assez pour un badge !

    Les notes de version DOIVENT identifier toutes les vulnérabilités connues du public corrigées dans cette version qui avaient déjà une affectation CVE ou similaire lors de la création de la version. Ce critère peut être marqué comme non applicable (N/A) si les utilisateurs ne peuvent pas en général mettre à jour le logiciel eux-mêmes (par exemple, comme c'est souvent le cas pour les mises à jour du noyau). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. S'il n'y a pas de notes de version ou qu'il n'y a pas eu de vulnérabilité publiquement connue, choisissez N/A. [release_notes_vulns]
    Ce critère aide les utilisateurs à déterminer si une mise à jour donnée corrigera une vulnérabilité connue publiquement, pour aider les utilisateurs à prendre une décision éclairée concernant la mise à jour. Si les utilisateurs ne peuvent généralement pas mettre à jour le logiciel eux-mêmes sur leur ordinateur, mais doivent à la place dépendre d'un ou plusieurs intermédiaires pour effectuer la mise à niveau (comme c'est souvent le cas pour un noyau et un logiciel de bas niveau associé à un noyau), le projet peut choisir « non applicable » (N/A) à la place, car ces informations supplémentaires ne seront pas utiles à ces utilisateurs. De même, un projet peut choisir N/A si tous les destinataires n'exécutent que la dernière version (par exemple, il s'agit du code d'un site Web ou d'un service Internet unique qui est constamment mis à jour par livraison continue). Ce critère s'applique uniquement aux résultats du projet, pas à ses dépendances. Énumérer les vulnérabilités de toutes les dépendances transitives d'un projet devient ingérable à mesure que les dépendances augmentent et varient, et n'est pas nécessaire car les outils qui examinent et suivent les dépendances peuvent le faire de manière plus évolutive.

    We have not released a fix for a publicly known runtime vulnerability in the operator itself with a CVE or similar identifier. Dependency advisories are outside this criterion.

    https://github.com/kubebao/openbao-operator/security/advisories
    https://github.com/kubebao/openbao-operator/releases/tag/0.5.2


 Compte-rendu 8/8 ●

  • Procédure de signalement des bogues


    Assez pour un badge !

    Le projet DOIT fournir un processus permettant aux utilisateurs de soumettre des signalements de bogue (par exemple, en utilisant un suivi des problèmes ou une liste de diffusion). (URL requise) [report_process]

    We use GitHub Issues for bugs and feature requests. SECURITY.md explains the separate private route for security reports.

    https://github.com/kubebao/openbao-operator/issues
    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/SECURITY.md#L3-L29


    Assez pour un badge !

    Le projet DEVRAIT utiliser un suivi des problèmes pour le suivi des problèmes individuels. [report_tracker]

    We track bugs and feature requests in GitHub Issues.

    https://github.com/kubebao/openbao-operator/issues


    Assez pour un badge !

    Le projet DOIT confirmer une majorité des signalements de bogues soumis au cours des 2 à 12 derniers mois (inclus) ; la réponse ne doit pas nécessairement inclure une correction. [report_responses]

    We acknowledged all eight human bug reports opened between 16 April and 16 October 2026. Six received maintainer comments on GitHub. We worked directly with the reporter on the other two, with fixes linked in PRs #791 and #794.

    https://github.com/kubebao/openbao-operator/issues/377
    https://github.com/kubebao/openbao-operator/issues/803
    https://github.com/kubebao/openbao-operator/issues/839
    https://github.com/kubebao/openbao-operator/pull/791
    https://github.com/kubebao/openbao-operator/pull/794


    Assez pour un badge !

    Le projet DEVRAIT répondre à une majorité (>50%) des demandes d'amélioration au cours des 2 à 12 derniers mois (inclus). [enhancement_responses]
    La réponse PEUT être « non » ou une discussion sur ses mérites. Le but est simplement qu'il y ait une réponse à certaines demandes, ce qui indique que le projet est toujours en vie. Aux fins de ce critère, les projets ne doivent pas compter les fausses demandes (par exemple, provenant de spammeurs ou de systèmes automatisés). Si un projet ne fait plus d'améliorations, sélectionnez « non satisfait » et incluez l'URL qui rend cette situation claire pour les utilisateurs. Si un projet tend à être submergé par le nombre de demandes d'amélioration, sélectionnez « non satisfait » et expliquez.

    Both enhancement requests opened between 16 April and 16 October 2026 received maintainer responses: #548 and #727. The latter was submitted by an external contributor.

    https://github.com/kubebao/openbao-operator/issues/548
    https://github.com/kubebao/openbao-operator/issues/727


    Assez pour un badge !

    Le projet DOIT avoir une archive publique pour les signalements et les réponses pour une recherche ultérieure. (URL requise) [report_archive]

    GitHub keeps public issues, comments, and their resolution history available for searching, including closed reports.

    https://github.com/kubebao/openbao-operator/issues


  • Processus de signalement de vulnérabilité


    Assez pour un badge !

    Le projet DOIT publier le processus de signalement des vulnérabilités sur le site du projet. (URL requise) [vulnerability_report_process]
    Les projets hébergés sur GitHub DEVRAIENT envisager d'activer le signalement privé d'une vulnérabilité de sécurité . Les projets sur GitLab DEVRAIENT envisager d'utiliser sa capacité à signaler une vulnérabilité en privé . Les projets PEUVENT identifier une adresse postale sur https://PROJECTSITE/security, souvent sous la forme security@example.org. Ce processus de rapport de vulnérabilité PEUT être le même que son processus de rapport de bogue. Les rapports de vulnérabilité PEUVENT toujours être publics, mais de nombreux projets ont un mécanisme de rapport de vulnérabilité privé.

    SECURITY.md explains how to report vulnerabilities privately through GitHub and how to request an alternative private contact.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/SECURITY.md#L3-L29


    Assez pour un badge !

    Si les signalements de vulnérabilités privés sont pris en charge, le projet DOIT inclure la façon d'envoyer l'information de manière confidentielle. (URL requise) [vulnerability_report_private]
    Des exemples incluent un signalement de défaut privé envoyé sur le Web en utilisant HTTPS (TLS) ou un courrier électronique chiffré à l'aide d'OpenPGP. Si les signalements de vulnérabilités sont toujours publics (donc il n'y a jamais de signalements de vulnérabilités privés), choisissez « non applicable » (N/A).

    GitHub private vulnerability reporting is enabled. SECURITY.md links to the reporting form and asks reporters to keep sensitive details out of public issues.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/SECURITY.md#L3-L29


    Assez pour un badge !

    Le temps de réponse initial du projet pour tout signalement de vulnérabilité reçu au cours des 6 derniers mois DOIT être inférieur ou égal à 14 jours. [vulnerability_report_response]
    S'il n'y a pas eu de vulnérabilité signalée au cours des 6 derniers mois, choisissez « non applicable » (N/A).

    We received no vulnerability reports between 17 April and 17 October 2026. Private reporting remains enabled and documented.

    https://github.com/kubebao/openbao-operator/blob/362bccea26e836ca3c107daf103f89d538118ef8/SECURITY.md#L3-L29


 Qualité 13/13 ●

 Sécurité 16/16 ●

 Analyse 8/8 ●


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

Soumission du badge du projet appartenant à : Roel de Cort.
Soumission créée le 2026-10-20 10:32:23 UTC, dernière mise à jour le 2026-10-20 14:06:38 UTC. Le dernier badge obtenu l'a été le 2026-10-20 14:06:38 UTC.