egeria

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative-/OpenSSF-Badge erhalten haben.

Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badge-Level für Projekt 3044 ist silver So können Sie ihn einbetten:

Dies sind die Kriterien das Level Gold. Sie können auch die Kriterien für die Level Passing oder Silber sehen.

        

 Grundlagen 5/5

  • Identifizierung

    Open Metadata and Governance

  • Voraussetzungen


    Das Projekt MUSS ein Silber-Siegel erreichen. [achieve_silver]

  • Projektüberwachung


    Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. (URL erforderlich) [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



    Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. (URL erforderlich) [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


  • Andere


    Das Projekt MUSS eine Lizenzerklärung in jeder Quelldatei enthalten. Dies DARF als Kommentar relativ am Anfangs jeder Datei einfügt sein: SPDX-License-Identifier: [SPDX license expression for project]. [license_per_file]

    We use SPDX tags to show license


  • Öffentliches Versionskontroll-Source-Repository


    Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. [repo_distributed]

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



    Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. (URL erforderlich) [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



    Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. [require_2FA]

    GitHub enforces this ...



    Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. [secure_2FA]

    Github enforces this ...


  • Programmierstil


    Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. (URL erforderlich) [code_review_standards]

    Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden [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.


  • Produktivsystem


    Das Projekt MUSS ein reproducible Build haben. Wenn kein Building erforderlich ist (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [build_reproducible]

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


  • Automatisierte Test-Suite


    Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. (URL erforderlich) [test_invocation]

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



    Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. (URL erforderlich) [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



    Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. [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.



    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. [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.


  • Verwende grundlegend gute kryptographische Praktiken

    Beachten Sie, dass einige Software keine kryptographischen Mechanismen verwenden muss. Wenn Ihr Project Software erstellt das (1) kryptographische funktionen einbindet, aktiviert, oder ermöglicht und (2) aus den USA heraus an nicht US-Bürger verteilt wird, dann könnten sie rechtlich zu weiterne Schritten gezwungen sein. Meistens beinhaltet dies lediglich das Senden einer E-Mail. Für mehr Informationen, siehe den Abschnitt zu Encryption in Understanding Open Source Technology & US Export Controls.

    Die vom Projekt produzierte Software MUSS sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 MÜSSEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_used_network]

    HTTPS is the default communication protocol



    Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_tls12]

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


  • Gesicherte Zustellung gegen Man-in-the-Middle-/MITM-Angriffe


    Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. (URL erforderlich) [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".


  • Andere Sicherheitsissues


    Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. [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.



    Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. (URL erforderlich) [hardening]

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


  • Dynamische Codeanalyse


    Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. [dynamic_analysis]

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



    Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. [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



Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Open Source Security Foundation unter den Nutzungsbedingungen. Es ist allen erlaubt, die Daten zu teilen und anzupassen, müssen aber einen angemessene Hinweis auf den Urheber geben. Bitte geben Sie als Urheber Mandy Chessell und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: Mandy Chessell.
Eintrag erstellt: 2019-08-08 14:24:18 UTC, zuletzt aktualisiert: 2022-12-20 12:06:18 UTC. Letztes erreichtes Badge: 2020-08-20 09:29:41 UTC.

Zurück