Gitano

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

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

ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/725"><img src="https://www.bestpractices.dev/projects/725/badge"></a>

Ce sont les critères du niveau

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

Analyse 2/2 ●

Analyse dynamique de code

Criterion [dynamic_analysis]
Atteint

Non atteint

N/A

?

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.

No dynamic analysis tools of this kind exist for Lua code.

Criterion [dynamic_analysis_enable_assertions]
Atteint

Non atteint

N/A

?

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.

As above, no dynamic analysis tooling available.

Ces données sont disponibles sous une licence Creative Commons Attribution version 3.0 ou ultérieure (CC-BY-3.0+). Chacun peut librement partager et adapter les données, à condition de créditer leur origine. Veuillez créditer Daniel Silverstone et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Daniel Silverstone.
Soumission créée le 2017-02-24 11:16:34 UTC, dernière mise à jour le 2019-02-20 08:41:41 UTC. Le dernier badge obtenu l'a été le 2019-02-20 07:57:44 UTC.

Retour

Gitano

Notions de base 4/5 ●

Identification

Conditions préalables

Supervision du projet

Autre

Contrôle des modifications 4/4 ●

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

Qualité 6/7 ●

Normes de codage

Système de construction opérationnel

Suite de tests automatisée

Sécurité 4/5 ●

Utiliser de bonnes pratiques de base de cryptographie

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

Autres problèmes de sécurité

Analyse 2/2 ●

Analyse dynamique de code