Configuration Persistence Service (CPS)

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

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

CPS has a project set up with ONAP Sonarcloud for analysis, see https://sonarcloud.io/component_measures?metric=coverage&view=treemap&id=onap_cps wherein a minimum of 97% code coverage is always maintained by the team. CPS also uses the SonarQube Scanner for Maven which uses the JaCoCo plugin to generate code coverage reports during the build process and track code coverage during run-time.

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.

Instead of run-time assertions, pre-run assertions are included where all the tests including the Integration tests are executed. Only after the successful pre-run tests, the projects are released and deployed on production. CPS uses Groovy for all unit and integration testing which is compiled and executed at runtime. CPS uses its capability to perform runtime assertions, see the following example https://gerrit.onap.org/r/gitweb?p=cps.git;a=blob;f=cps-ncmp-service/src/test/groovy/org/onap/cps/ncmp/api/impl/operations/DmiDataOperationsSpec.groovy;h=03825c2bbf34398df77a0028ee0825e96f5a5fbb;hb=3d97a963ce51c4f0ecdb656a3b25bcabf2f6f8b7

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

Soumission du badge du projet appartenant à : mrsjackson76.
Soumission créée le 2020-11-06 15:16:30 UTC, dernière mise à jour le 2023-11-06 20:25:48 UTC. Le dernier badge perdu l'a été le 2021-07-15 11:20:34 UTC. Le dernier badge obtenu l'a été le 2021-07-26 15:12:53 UTC.

Retour

Configuration Persistence Service (CPS)

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