celeris

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 :

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/15387/badge)](https://www.bestpractices.dev/projects/15387)

ou en incorporant ceci dans votre HTML :

<a href="https://www.bestpractices.dev/projects/15387"><img src="https://www.bestpractices.dev/projects/15387/badge"></a>

Ce sont les critères du niveau

. Vous pouvez également afficher les critères des niveaux

.

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

Analyse 8/8 ●

Analyse statique de code

Criterion [static_analysis]
Atteint

Non atteint

N/A

?

Au moins un outil d'analyse statique de code (au-delà des avertissements du compilateur et des modes « sûrs » des languages) DOIT être appliqué à toute distribution majeure proposée avant sa sortie s'il existe au moins un outil FLOSS qui implémente ce critère dans le langage sélectionné. ^{[static_analysis]}
Un outil d'analyse statique de code examine le code logiciel (au niveau du code source, du code intermédiaire ou de l'exécutable) sans l'exécuter avec des entrées spécifiques. Aux fins de ce critère, les avertissements du compilateur et les modes de langage « sûrs » ne comptent pas comme des outils d'analyse statique de code (ceux-ci évitent généralement une analyse approfondie car la rapidité est vitale). Certains outils d'analyse statique se concentrent sur la détection de défauts génériques, d'autres se concentrent sur la détection de défauts spécifiques (tels que les vulnérabilités) et d'autres encore proposent une combinaison de ces deux types d'outils. Des exemples de tels outils d'analyse statique de code incluent cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (y compris FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy et HP Enterprise Fortify Static Code Analyzer. Des listes plus vastes d'outils peuvent être trouvées dans des endroits tels que la liste Wikipedia d'outils pour l'analyse statique de code, l'information OWASP sur l'analyse statique de code, la liste NIST des analyseurs de sécurité du code source et la liste des outils d'analyse statique de Wheeler. S'il n'y a pas d'outil d'analyse statique FLOSS disponible pour le(s) langage(s) d'implémentation utilisé(s), sélectionnez « N/A ».

Static analysis runs on every pull request and every push to main: golangci-lint with staticcheck and govet (required "Lint" check), govulncheck (required "Vulnerability Check"), and actionlint and zizmor on the workflows; the release workflow re-runs this CI. GitHub CodeQL for Go and GitHub Actions (default setup) also scans pull requests and pushes to main, and weekly. https://github.com/goceleris/celeris/blob/main/.github/workflows/ci.yml

Criterion [static_analysis_common_vulnerabilities]
Atteint

Non atteint

N/A

?

Il est PROPOSÉ qu'au moins l'un des outils d'analyse statique utilisés pour le critère d'analyse statique inclue des règles ou des approches pour rechercher des vulnérabilités courantes dans le langage ou l'environnement analysé. ^{[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 Go security queries and govulncheck both look for common vulnerabilities.

Criterion [static_analysis_fixed]
Atteint

Non atteint

N/A

?

Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse statique de code DOIVENT être corrigées en temps approprié après leur confirmation. ^{[static_analysis_fixed]}
Une vulnérabilité est considérée comme étant de gravité moyenne ou supérieure si son score qualitatif de base du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public. Remarquez que le critère vulnerabilities_fixed_60_days nécessite que de telles vulnérabilités soient corrigées dans les 60 jours de leur divulgation publique.

There are no open CodeQL findings. 14 code-scanning alerts were fixed, and 12 were dismissed with written reasons (false positives such as the protocol-mandated PostgreSQL MD5 response, and bounded integer conversions). The only open code-scanning alerts are Scorecard's own meta-checks (#20 this badge, #26 dependency advisories, see action 3).

Criterion [static_analysis_often]
Atteint

Non atteint

N/A

?

Il est PROPOSÉ que l'analyse statique du code source se produise à chaque commit ou au moins quotidiennement. ^{[static_analysis_often]}

On every PR and every push to main (CodeQL and golangci-lint), and govulncheck on every PR; CodeQL also has a weekly scheduled scan.

Analyse dynamique de code

Atteint

Non atteint

Il est PROPOSÉ qu'au moins un outil d'analyse dynamique soit appliqué à tout candidat pour une version majeure du logiciel avant sa distribution. ^{[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.

The Go race detector runs on the unit, adaptive, io_uring and middleware test steps of the CI that gates every PR and runs again from the release workflow. The conformance job runs h2spec/h1spec against a running server. The repo also contains 43 Go fuzz targets (run with mage fuzz), and the separate probatorium cluster matrix exercises releases under load.

Atteint

Non atteint

N/A

Il est PROPOSÉ que, si le logiciel produit par le projet comprend un logiciel écrit à l'aide d'un langage non sûr pour les accès mémoire (par exemple, C ou C ++), au moins un outil dynamique (par exemple, un fuzzer ou un scanner d'application Web) soit utilisé de façon routinière en combinaison avec un mécanisme pour détecter des problèmes de sécurité mémoire tels que les dépassements de zone mémoire. Si le projet ne produit pas de logiciel écrit dans un langage non sûr pour les accès mémoire, choisissez « 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.

The project is written in Go, a memory-safe language, with no C, C++ or assembly (no cgo, no .s/.c/.h files in the tree). Where unsafe is used, tests run under the race detector, which also enables checkptr.

Atteint

Non atteint

Il est PROPOSÉ que le projet utilise une configuration pour au moins une analyse dynamique (comme le test ou le fuzzing) qui active de nombreuses assertions. Dans de nombreux cas, ces assertions ne doivent pas être activées dans les versions de production. ^{[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.

Tests run with go test -race, which enables the race detector and Go's checkptr pointer-safety instrumentation. A dedicated build tag (celeris_closeprobe) adds extra close-path checks, vetted and tested in CI.

Atteint

Non atteint

N/A

Toutes les vulnérabilités exploitables de gravité moyenne ou plus découvertes avec une analyse de code dynamique DOIVENT être corrigées en un temps approprié après leur confirmation. ^{[dynamic_analysis_fixed]}

Si vous n'utilisez pas d'analyse de code dynamique et n'avez donc trouvé aucune vulnérabilité de cette manière, choisissez « non applicable » (N/A). Une vulnérabilité est considérée comme étant de gravité moyenne ou supérieure si son score qualitatif de base du Système Commun d'Évaluation des Vulnérabilités (CVSS) est moyen ou supérieur. Dans les versions CVSS 2.0 à 3.1, cela équivaut à un score CVSS de 4.0 ou supérieur. Les projets peuvent utiliser le score CVSS publié dans une base de données de vulnérabilité largement utilisée (telle que la base de données nationale des vulnérabilités) en utilisant la version la plus récente de CVSS rapportée dans cette base de données. Les projets peuvent aussi calculer eux-mêmes la gravité à l'aide de la dernière version de CVSS au moment de la divulgation de la vulnérabilité, si les entrées de calcul sont révélées publiquement une fois que la vulnérabilité est connue du public.

Problems found by the race detector and by soak runs were fixed: SECURITY.md records two memory-safety races closed in 1.5.x, and the release notes for v1.5.8-v1.5.11 list fixes found by dynamic testing. No open exploitable vulnerability from dynamic analysis is known.
Alternative: N/A is allowed if the maintainer prefers ("not running dynamic analysis finds nothing"), but the project does run it, so Met is the more accurate answer.

4. Evidence index (for the maintainer's reference)

Item	Where / what I saw
Ruleset "Main" (id 13624474)	PR required, 1 approval, code-owner review, last-push approval, thread resolution; blocks deletion and force-push; org admin can bypass
Ruleset "Main - CI" (id 22358875)	7 required checks, strict up-to-date
Ruleset "Release tags" (id 22357612)	v* tags cannot be updated or deleted (org admin bypass)
Ruleset "Sub-module tags" (id 22357613)	exists, active
Branch protection API	404 "Branch not protected" (rulesets are used instead; `branches/main` reports `protected: true`)
Repo security settings	secret scanning on, push protection on, Dependabot security updates on, private vulnerability reporting on
Workflows	CI, Drivers, Release, Release Checklist, Scorecard, Coverage, CodSpeed, Smoke Benchmark; CodeQL via default setup
Dependabot	`.github/dependabot.yml`, gomod daily across 10 modules, plus the tools module
Scorecard (api.securityscorecards.dev, 2026-10-11)	overall 8.2; SAST 10, Fuzzing 10, Security-Policy 10, Pinned-Dependencies 10, Token-Permissions 10, CI-Tests 10, Maintained 10, Dependency-Update-Tool 10, Dangerous-Workflow 10, License 10, Binary-Artifacts 10, Branch-Protection 8, Vulnerabilities 5 (see action 3), Contributors 3, Code-Review 0, CII-Best-Practices 0 (this task), Signed-Releases and Packaging n/a
Issues / PRs	585 issues (515 closed, 70 open; 584 by the maintainer, 1 external), 410 PRs (358 merged; 343 by the maintainer, 65 Dependabot, 2 external)
Releases	57 GitHub releases; latest v1.5.11 (2026-09-05); no v1.6.0 yet

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

Soumission du badge du projet appartenant à : FumingPower.
Soumission créée le 2026-10-11 18:12:02 UTC, dernière mise à jour le 2026-10-11 20:31:10 UTC. Le dernier badge obtenu l'a été le 2026-10-11 20:31:10 UTC.

celeris

Notions de base 13/13 ●

Général

Contenu basique du site Web du projet

Licence FLOSS

Documentation

Autre

Contrôle des modifications 9/9 ●

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

Numérotation unique de la version

Notes de version

Compte-rendu 8/8 ●

Procédure de signalement des bogues

Processus de signalement de vulnérabilité

Qualité 13/13 ●

Système de construction opérationnel

Suite de tests automatisée

Nouveau test de fonctionnalité

Options d'avertissement

3.5 Security

Sécurité 16/16 ●

Connaissance du développement sécurisé

Utiliser de bonnes pratiques de base de cryptographie

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

Vulnérabilités publiquement identifiées et corrigées

Autres problèmes de sécurité

Analyse 8/8 ●

Analyse statique de code

Analyse dynamique de code

4. Evidence index (for the maintainer's reference)