ONAP POLICY

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


Ce sont les critères du niveau Or. Vous pouvez également afficher les critères des niveaux Basique ou Argent.

        

 Notions de base 5/5 ●

  • Identification

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

    POLICY is the subsystem of ONAP that maintains, distributes, and operates on the set of rules that underlie ONAP’s control, orchestration, and management functions.

    POLICY provides a logically centralized environment for the creation and management of policies, including conditional rules. This provides the capability to create and validate policies/rules, identify overlaps, resolve conflicts, and derive additional policies as needed.

    Policies are used to control, influence, and help ensure compliance with goals. Policies can support infrastructure, products and services, operation automation, and security. Users, including network and service designers, operations engineers, and security experts, can easily create, change, and manage policy rules from the POLICY Manager in the ONAP Portal.

    A policy is defined to create a condition, requirement, constraint, decision, or a need that must be provided, evaluated, maintained, and/or enforced. The policy is validated and corrected for any conflicts, and then placed in the appropriate repository, and made available for use by other subsystems and components. Alternately, some policies are directly distributed to policy decision engines such as Drools or XACML. In this manner, the constraints, decisions and actions to be taken are distributed.

  • Conditions préalables


    Assez pour un badge !

    Le projet DOIT atteindre un badge de niveau argent. [achieve_silver]

  • Supervision du projet


    Assez pour un badge !

    Le projet DOIT avoir un « facteur bus » de 2 ou plus. (URL requise) [bus_factor]
    Un « bus factor » (aussi connu en tant que « truck factor ») est le nombre minimum de membres du projet qui doivent disparaître soudainement d'un projet (« écrasé par un bus ») avant que le projet ne se bloque en raison du manque de personnel compétent. L'outil truck-factor peut l'estimer pour des projets sur GitHub. Pour plus d'informations, voir Évaluation du « bus factor » des dépôts Git par Cosentino et al.

    All 5 project committers actively contribute to the codebase. Details on the committers is stored in INFO.yaml files for each repository. For example: https://gerrit.onap.org/r/gitweb?p=policy/parent.git;a=blob;f=INFO.yaml;hb=refs/heads/master


    Assez pour un badge !

    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. (URL requise) [contributors_unassociated]
    Les contributeurs sont associés s'ils sont payés pour leur travail par la même organisation (en tant qu'employé ou contractuel) et si l'organisation bénéficie des résultats du projet. Les subventions financières ne comptent pas comme provenant de la même organisation si elles passent par d'autres organisations (par exemple, les subventions scientifiques versées à différentes organisations par un même gouvernement ou ONG ne rendent pas les contributeurs associés). Quelqu'un est un contributeur significatif s'il a apporté des contributions non triviales au projet au cours de la dernière année. Des exemples de bons indicateurs d'un contributeur significatif sont : écrit au moins 1 000 lignes de code, a contribué à 50 commits ou au moins 20 pages de documentation.

    We have key developers contributing to Policy Framework from different organizations are listed below:

    https://gerrit.onap.org/r/q/owner:ajinkya-patil%2540t-systems.com https://gerrit.onap.org/r/q/owner:wayne.dunican%2540est.tech https://gerrit.onap.org/r/q/owner:francesco.fiora%2540est.tech https://gerrit.onap.org/r/q/owner:adam.kenihan%2540est.tech https://gerrit.onap.org/r/q/owner:saul.gill%2540est.tech


  • Autre


    Assez pour un badge !

    Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet]. [license_per_file]
    Cela PEUT également être fait en incluant une déclaration en langage naturel identifiant la licence. Le projet PEUT également inclure une URL stable indiquant le texte de la licence ou directement le texte complet de la licence. Notez que le critère license_location requiert que la licence du projet soit dans un emplacement standard. Voir ce didacticiel SPDX pour plus d'informations sur les expressions de licence SPDX. Notez la relation avec copyright_per_file, dont le contenu devrait généralement précéder les informations sur la licence.

    ONAP requires this via their CI/CD process that license/copyright are on every source file, or a single license file may be placed at the top of a directory structure. SPDX-License-Identifier is included. https://github.com/onap/policy-clamp/blob/master/common/src/main/java/org/onap/policy/clamp/common/acm/exception/AutomationCompositionException.java https://github.com/onap/policy-api/blob/master/main/src/main/java/org/onap/policy/api/main/service/PdpGroupService.java


 Contrôle des modifications 4/4 ●

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


    Assez pour un badge !

    Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). [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.

    Git and Gerrit are used.


    Assez pour un badge !

    Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. (URL requise) [small_tasks]
    Cette identification se fait typiquement en marquant les problèmes sélectionnés dans un outil de suivi de problèmes avec une ou plusieurs étiquettes que le projet utilise à cet effet, par exemple up-for-grabs, first-timers-only, « Small fix », microtask ou IdealFirstBug. Ces nouvelles tâches n'ont pas besoin d'ajouter des fonctionnalités ; elles peuvent améliorer la documentation, ajouter des cas de test ou toute autre chose qui aide le projet et aide le contributeur à en comprendre davantage sur le projet.

    https://lf-onap.atlassian.net/jira/software/c/projects/POLICY/issues?jql=project%20%3D%20%22POLICY%22%20ORDER%20BY%20created%20DESC


    Assez pour un badge !

    Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. [require_2FA]

    LF requires a Linux Foundation ID for accessing repos . LF Id requires a 2FA.


    Assez pour un badge !

    L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. [secure_2FA]
    Un mécanisme 2FA qui répond à ce critère serait une application de mot de passe à usage unique basé sur le temps (TOTP) qui génère automatiquement un code d'authentification qui change après un certain laps de temps. Notez que GitHub prend en charge TOTP.

    2FA for LF id uses authenticator app.


 Qualité 7/7 ●

 Sécurité 4/5 ●

  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Assez pour un badge !

    Le logiciel produit par le projet DOIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DOIVENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (N/A). [crypto_used_network]

    The projects supports secure TLS and HTTPS in these applications. HTTP is allowed only through service mesh.


    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (N/A). [crypto_tls12]

    The products support TLS version 1.2


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


    Pas assez pour un badge.

    Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. (URL requise) [hardened_site]
    Notez que GitHub et GitLab sont connus pour le faire. Des sites tels que https://securityheaders.com/ peuvent le vérifier rapidement. Les en-têtes clés de durcissement sont : Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (comme « nosniff ») et X-Frame-Options. Les sites Web complètement statiques sans possibilité de se connecter à travers les pages Web peuvent éventuellement omettre certains entêtes de durcissement avec moins de risques, mais il n'existe aucune manière fiable de détecter ces sites, donc nous exigeons ces en-têtes mêmes pour les sites complètement statiques.

    We have got A rating from the securityheaders.com for the project website, repository and download site. Policy is hosted on Git hub which is a protected with hardening headers. Download site https://nexus3.onap.org/ project repository https://github.com/onap?q=policy&type=all&language=&sort= Project website https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16230647/Policy+Framework+Project // One or more of the required security hardening headers is missing.


  • Autres problèmes de sécurité


    Assez pour un badge !

    Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. [security_review]
    Cela PEUT être fait par les membres du projet et/ou une évaluation indépendante. Cette évaluation PEUT être soutenue par des outils d'analyse statiques et dynamiques, mais il doit aussi y avoir une revue par des humains pour identifier les problèmes (en particulier dans la conception) que les outils ne peuvent pas détecter.

    Policy Framework had the security review done last year. https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16519988/PF+-+ONAP+Security+Review+Questionnaire


    Assez pour un badge !

    Des mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. (URL requise) [hardening]
    Les mécanismes de durcissement peuvent inclure des en-têtes HTTP comme Content Security Policy (CSP), des options de compilation pour atténuer les attaques (telles que -fstack-protector) ou des options de compilation pour éliminer les comportements indéfinis. Pour nos besoins, le principe de plus faible privilège n'est pas considéré comme un mécanisme de durcissement (le principe de plus faible privilège est important, mais séparé).

    The project tries to use hardening mechanisms whenever possible. The application uses Swagger for RESTful API, wherein it is set that Authorization headers are required for accessing API documentation. Policy Framework as a production service must be installed using the OOM helm charts, which are using Service Mesh and following the required user privilege for network and file system access. In these deployments, K8s secrets which are generated and stored as the application is deployed. The user has the option to provide a username/password to the helm chart - in this case a kubernetes secret will be generated by the chart and used for authentication. Any unused functionality, service (as whole or as REST API), credential is reviewed and removed from the base code. https://lf-onap.atlassian.net/wiki/spaces/DW/pages/16519988/PF+-+ONAP+Security+Review+Questionnaire


 Analyse 2/2 ●

  • Analyse dynamique de code


    Assez pour un badge !

    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.

    The project runs sonar against the code on every code reviews. Jmeter is also used for analyzing the performance and application behavior on load conditions. Observability is available with prometheus metrics in the runtime applications.

    Ex: https://jenkins.onap.org/job/policy-api-sonar-verify/ Jmeter analysis: https://docs.onap.org/projects/onap-policy-parent/en/latest/development/devtools/testing/s3p/api-s3p.html


    Assez pour un badge !

    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 project validates prometheus metrics on the integration tests as runtime assertions. https://jenkins.onap.org/job/policy-api-master-project-csit-api/1829/robot/Api-Test%20&%20Api-Slas/Api-Slas/



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit mrsjackson76 and the OpenSSF Best Practices badge contributors.

Soumission du badge du projet appartenant à : mrsjackson76.
Soumission créée le 2018-02-02 19:29:43 UTC, dernière mise à jour le 2024-11-05 13:37:29 UTC. Le dernier badge obtenu l'a été le 2018-05-02 14:24:07 UTC.

Retour