egeria

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 3044 est silver Voici comment l'intégrer :

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

    Open Metadata and Governance

  • 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]

    The project has a core team of 10 + contributors who have been with the project since its inception. There is a good span of modules that have multiple contributors who can maintain the code. https://github.com/odpi/egeria/graphs/contributors


    Assez pour un badge !

    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. (URL requise) [contributors_unassociated]

    The community is pretty collaborative so there are no separate factions. However there are major contributions from people employed by IBM, ING and SAS: https://github.com/odpi/egeria/graphs/contributors


  • 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]

    We use SPDX tags to show license


  • 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]

    Repository on GitHub, which uses git. git is distributed.


    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]

    The project uses the label "good first issue" when these types of tasks are identified. See https://github.com/odpi/egeria/labels/good%20first%20issue


    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]

    GitHub enforces this ...


    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]

    Github enforces this ...


  • Normes de codage


    Assez pour un badge !

    Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. (URL requise) [code_review_standards]

    https://egeria.odpi.org/developer-resources/Reviewing-Code-Changes.html


    Assez pour un badge !

    Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. [two_person_review]

    We have a code owners who are notified when changes are made to the code. Significant changes are discussed on the developer calls. Many maintainers always ask for a review when they are making changes.


  • Système de construction opérationnel


    Assez pour un badge !

    Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). (URL requise) [build_reproducible]

    The project uses maven to probide a reproducible build: https://github.com/odpi/egeria/blob/master/pom.xml


  • Suite de tests automatisée


    Assez pour un badge !

    Une suite de tests DOIT être invocable d'une manière standard pour ce langage. (URL requise) [test_invocation]

    It is invokable as part of a standard Maven build process. https://github.com/odpi/egeria/blob/master/pom.xml


    Assez pour un badge !

    Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. (URL requise) [test_continuous_integration]

    We have a CI/CD pipeline that triggers a build on each commit and tests are automatic run. See: https://github.com/odpi/egeria/pulls


    Assez pour un badge !

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 90% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_statement_coverage90]

    Egeria modules go through a lifecycle that has 4 levels: In Development Technical Preview (optional) Released Deprecated

    See https://egeria.odpi.org/open-metadata-publication/website/content-status/

    While a module is in in-development status there are no test requirements. This is to ensure that new code capability is share quickly and often, allowing ongoing review of code.

    As the module matures and moves to tech-preview, there is an expectation that it is reasonably well tested with UT and FVT automated tests running in the build.

    At the released status, our modules have test cases that take them to 90% statement coverage. However we do not have an automated way to run both the Conformance Test Suite and the labs. These tests are run manually at each release (one per month). Because of this, we do not have a systematic capture of covernance statistics at the moment.


    Assez pour un badge !

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture de branche d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [test_branch_coverage80]

    Egeria modules go through a lifecycle that has 4 levels: In Development Technical Preview (optional) Released Deprecated

    See https://egeria.odpi.org/open-metadata-publication/website/content-status/

    While a module is in in-development status there are no test requirements. This is to ensure that new code capability is share quickly and often, allowing ongoing review of code.

    As the module matures and moves to tech-preview, there is an expectation that it is reasonably well tested with UT and FVT automated tests running in the build.

    At the released status, our modules have test cases that take them to 80% statement coverage. However we do not have an automated way to run both the Conformance Test Suite and the labs. These tests are run manually at each release (one per month). Because of this, we do not have a systematic capture of covernance statistics at the moment.


  • 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]

    HTTPS is the default communication protocol


    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]

    TLS is at latest available level - not sure what link to show this?


  • 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]

    The project content such as source code and website are delivered by well-known secure GitHub services. In regards to the static website, we have applied security hardening where possible: (1) Configured "Content-Security-Policy" via http-equiv meta directive for the static index.html page; (2) Configured "Strict-Transport-Security" response header on the GitHub Pages web server. // X-Content-Type-Options was not set to "nosniff".


  • 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]

    The project has a security team that meets each week and reviews security scans. The Egeria code was subject to a penetration test when ING started running it in production.


    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]

    Lint is enabled in both in Java and JS. Also CodeQL is run for every change. https://github.com/odpi/egeria/security


  • 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]

    This is the description of the texting conducted by the project: https://github.com/odpi/egeria/blob/master/CodeQualitySecurity.md


    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]

    The code has runtime assertions for testing parameters - these call our exception and audit log framework. The developers also use IntelliJ that is continually performing analysis on the code and detecting null pointer exceptions etc



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

Soumission du badge du projet appartenant à : Mandy Chessell.
Soumission créée le 2019-08-08 14:24:18 UTC, dernière mise à jour le 2022-12-20 12:06:18 UTC. Le dernier badge obtenu l'a été le 2020-08-20 09:29:41 UTC.

Retour