roblogic-codespace-template

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 7341 est gold

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

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

Code is a config and does not need code analysis
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.
The Roblogic Codespace Template project acknowledges the importance of run-time assertions in software development. Run-time assertions are valuable for detecting and preventing unexpected behavior during code execution, helping to maintain the stability and reliability of the software.

While the Roblogic Codespace Template project provides a foundation for developers to set up and work with a Roblogic project in a GitHub Codespace environment, it does not enforce the use of run-time assertions by default. However, the project encourages developers to include run-time assertions in their code, as appropriate, to improve the overall quality and robustness of their applications.

In addition to including run-time assertions in the code, the project recommends using dynamic analysis tools for the primary languages, such as:
1. React (JavaScript): Developers can utilize tools like React Developer Tools and Redux DevTools for dynamic analysis of React components and application state.
2. Python: Developers can use dynamic analysis tools like pdb (Python Debugger) and Py-Spy for run-time debugging and performance profiling of Python code.

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 Robert Wilkins III et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Robert Wilkins III.
Soumission créée le 2023-05-05 21:42:50 UTC, dernière mise à jour le 2023-05-06 04:06:54 UTC. Le dernier badge obtenu l'a été le 2023-05-06 00:14:03 UTC.

Retour

roblogic-codespace-template

Notions de base 5/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é 7/7 ●

Normes de codage

Système de construction opérationnel

Suite de tests automatisée

Sécurité 5/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