ONAP Optimization Framework (OOF)

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 1720 ist passing So können Sie ihn einbetten:

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

        

 Grundlagen 17/17 ●

  • Identifizierung

    The ONAP Optimization Framework provides a declarative, policy- and model-driven functionality for creating and managing optimization applications for a broad range of use cases within ONAP. Specifically, it provides a framework for rapidly developing new optimization applications independent of how the underlying optimization modules are implemented.

  • Voraussetzungen


    Genug für ein Badge!

    Das Projekt MUSS ein bestimmtes Level erreichen. [achieve_passing]

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. (URL erforderlich) [contribution_requirements]

    Acceptable contributions are based on the ONAP requirements captured here:

    https://wiki.onap.org/display/DW/Development+Procedures+and+Policies https://wiki.onap.org/display/DW/Developing+ONAP https://wiki.onap.org/display/DW/Developer+Best+Practices

    The Python code should meet the requirements except for the number of characters in a line of code specified by the styleguide https://google.github.io/styleguide/pyguide.html

    We are in the process of ensuring that the seed code is adapted per the Google Style Guide and will require that new commits meet pylint --rcfile=


  • Projektüberwachung


    Genug für ein Badge!

    Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. (URL erforderlich) [dco]

    ONAP requires both a Developer Certificate of Origin (DCO), and a Contributor License Agreement (CLA). https://wiki.onap.org/display/DW/Contribution+Agreements


    Genug für ein Badge!

    Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. (URL erforderlich) [governance]

    The project governance is described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance

    Further information can be found at https://wiki.onap.org/display/DW/ONAP+Technical+Community+Document


    Genug für ein Badge!

    Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. (URL erforderlich) [code_of_conduct]

    Follows LF Code of conduct

    https://www.linuxfoundation.org/code-of-conduct/


    Genug für ein Badge!

    Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. (URL erforderlich) [roles_responsibilities]

    The key roles in the project and their responsibilities are described at https://wiki.onap.org/display/DW/Community+Offices+and+Governance Current members are listed at https://wiki.onap.org/pages/viewpage.action?pageId=8226539


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). (URL erforderlich) [access_continuity]

    OOF has multiple committers and multiple contributes who are listed in : https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-OptimizationFramework

    All committers have access and rights to maintain the code base, approve and review incoming changes and release a new version of the artifact. This will let the project continue with minimal to no interruption if one person is incapacitated. More committers can be included in the project, as this is supported by the linux foundation.


    Genug für ein Badge!

    Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. (URL erforderlich) [bus_factor]

    The project covered in this report has more than 2 persons who actively contribute and maintain code. At any point of time, the list of committers for the project is maintained here : https://wiki.onap.org/display/DW/Resources+and+Repositories#ResourcesandRepositories-OptimizationFramework


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. (URL erforderlich) [documentation_roadmap]

    The road map for OOF can be found in the corresponding release planning phase. For example,

    https://wiki.onap.org/display/DW/OOF+Dublin+M1+Release+Planning


    Genug für ein Badge!

    Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [documentation_architecture]

    The high-level design and architecture of OOF (and its evolutions) can be found under each release planning phase. For example, in Dublin release:

    https://wiki.onap.org/display/DW/OOF+Dublin+%28R4%29+Architecture+Alignment


    Genug für ein Badge!

    Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. (URL erforderlich) [documentation_security]

    A security sub-committee oversees the release requirements, best practices. Agreed recommendations become integral parts of an ONAP release and are assessed during milestones: https://wiki.onap.org/display/DW/ONAP+Security+coordination

    Further, the release note clearly states what has been achieved, along with the release checklists and links to individual JIRA items that covers the above security requirements. OOF adheres to the overall security requirements of ONAP and also provides a per release vulnerability threat.


    Genug für ein Badge!

    Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. (URL erforderlich) [documentation_quick_start]

    Information on setting up ONAP can be found at https://onap.readthedocs.io/en/latest/guides/onap-developer/settingup/index.html.

    Project specific guides are also available: https://wiki.onap.org/display/DW/HAS+Developer+Guide


    Genug für ein Badge!

    Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. [documentation_current]

    ONAP projects are required to update all documents on readthedocs.io as a part of the release process. The current documentation for OOF can be found at:

    https://docs.onap.org/en/latest/guides/onap-developer/developing/index.html#optimization-framework


    Genug für ein Badge!

    Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. (URL erforderlich) [documentation_achievements]

    The project website displays the latest badge.

    https://wiki.onap.org/display/DW/Optimization+Framework+Project


  • Zugänglichkeit und Internationalisierung


    Genug für ein Badge!

    Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. [accessibility_best_practices]

    OOF has no user interfaces and is a runtime component; the project site is configurable for font size/colors.


    Genug für ein Badge!

    Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). [internationalization]

    OOF doesn't provide an end user interface currently.


  • Andere


    Genug für ein Badge!

    Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, müssen die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z. B. Argon2id, Bcrypt, Scrypt, or PBKDF2). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. [sites_password_security]

    All passwords are stored either as kubernetes secrets or imported from a secret management service. They are not stored as plain text within the project


  • Vorherige Versionen


    Genug für ein Badge!

    Das Projekt MUSS die am häufigsten verwendeten älteren Versionen des Produkts beibehalten oder einen Upgrade-Pfad zu neueren Versionen bieten. Wenn der Upgrade-Pfad schwierig durchzuführen ist, muss das Projekt dokumentieren, wie das Upgrade durchgeführt werden kann (z. B. die Interfaces, die sich geändert haben, detaillierte Anleitung für die Aktualisierung des Upgrades). [maintenance_or_update]

    All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when an upgrade requires certain steps to be followed they are being added to the release documents as needed


  • Bug-Report-Prozess


    Genug für ein Badge!

    Das Projekt MUSS ein Issue-Tracking-System zur Verwaltung einzelner Issues verwenden. [report_tracker]

    Jira is used to track issues. https://jira.onap.org/projects/OPTFRA

    Additional details are provided at: https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS die Reporter/in von allen in den letzten 12 Monaten bekanntgegebenen Schwachstellenberichte aufführen, mit Ausnahme der Reporter, die Anonymität erbeten. Wurde in den letzten 12 Monaten keine Schwachstelle festgestellt, wählen Sie "nicht anwendbar" (N/A). (URL erforderlich) [vulnerability_report_credit]

    Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711

    The wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_response_process]

    Vulnerability handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711


  • Programmierstil


    Genug für ein Badge!

    Das Projekt MUSS die spezifischen Codierungsstilrichtlinien für die primären Programmierprachen, die es verwendet, einhalten, und erfordern, dass die Beiträge die Bedingungen generell erfüllen. (URL erforderlich) [coding_standards]

    Google coding style is used in ONAP https://github.com/google/styleguide


    Genug für ein Badge!

    Das Projekt MUSS automatisch dafür sorgen, dass die ausgewählten Stilrichtlinien eingehalten werden, wenn mindestens ein FLOSS-Tool vorhanden ist, welches das in der gewählten Programmiersprache tun kann. [coding_standards_enforced]

    SONAR compile time and Static Reporting tools enforce coding styles. For java applications, maven-checkstyle-plugin is used and is referenced in the parent POM. For Python applications, PEP8 checks is used.


  • Produktivsystem


    Genug für ein Badge!

    Build-Systeme für native Binärdateien MÜSSEN die relevanten Compiler- und Linker- (Umgebungs-) Variablen, die an sie übergeben werden (z.B. CC, CFLAGS, CXX, CXXFLAGS und LDFLAGS), respektieren und an Compiler- und Linker-Aufrufe weiterleiten. Ein Build-System DARF sie mit zusätzlichen Flags erweitern; Es DARF NICHT einfach die mitgelieferten Werte ersetzen. Wenn keine nativen Binärdateien erzeugt werden, wählen Sie "nicht anwendbar" (N/A). [build_standard_variables]

    The project does not create native binaries.


    Genug für ein Badge!

    Das Build- und Installationssystem SOLLTE Debugging-Informationen beibehalten, wenn sie in den entsprechenden Flags angefordert werden (z. B. "install -s" wird nicht verwendet). Wenn kein Build- oder Installationssystem vorhanden ist (z. B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_preserve_debug]

    The project does not create native binaries. Each components build and installation process provides debugging information (eg. pip install)


    Genug für ein Badge!

    Das Build-System für die Software, die durch das Projekt erzeugt wird, DARF NICHT rekursive Unterverzeichnisse aufbauen, wenn es Querverweise in den Unterverzeichnissen gibt. Wenn kein Build- oder Installationssystem vorhanden ist (z.B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). [build_non_recursive]

    There are no cross dependencies.


    Genug für ein Badge!

    Das Projekt MUSS in der Lage sein, den Prozess der Generierung von Informationen aus Quelldateien zu wiederholen und genau das gleiche Bit-für-Bit-Ergebnis zu erhalten. Wenn kein Build auftritt (z. B. Skriptsprachen, in denen der Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "nicht anwendbar" (N / A). [build_repeatable]

    All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.


  • Installationssystem


    Genug für ein Badge!

    Das Projekt MUSS eine Möglichkeit zur einfachen Installation und Deinstallation der Software haben, unter Benutzung einer häufig verwendeten Methode. [installation_common]

    All packages are delivered either as jar artifacts or as docker images. * Maven artifacts can be removed using the pom file. * Docker containers can be spun up easily using helm, and the orchestration through Kubernetes allows easy exclusion of specific containers. * Python components can be easily installed via pip


    Genug für ein Badge!

    Das Installationssystem für den/die Endbenutzer/in MUSS Standardkonventionen zur Auswahl des Zielortes, in dem gebildete Artefakte zur Installationszeit geschrieben werden, folgen. Zum Beispiel, wenn es Dateien auf einem POSIX-System installiert, muss es die DESTDIR-Umgebungsvariable verwenden. Wenn es kein Installationssystem oder keine Standardkonvention gibt, wählen Sie "nicht anwendbar" (N/A). [installation_standard_variables]

    Docker containers are used for installation, so the conventions of the host operating system are not relevant. Python components are typically installed within their own virtual environments, which is a best practice.


    Genug für ein Badge!

    Das Projekt MUSS einen Weg für potenzielle Entwickler bereithalten, um schnell alle erforderlich Projektergebnisse und Support-Umgebungen zu installieren, um Änderungen vornehmen zu können, einschließlich der Tests und Test-Umgebung. Dies MUSS mit einer gängigen Methode durchgeführt werden können. [installation_development_quick]

    OOM based deployment is documented clearly in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html. Each independent component has its own developers guide that prepares the required dev environment, the process of which is well automated.

    For example: https://wiki.onap.org/display/DW/HAS+Developer+Guide


  • Externe gepflegte Komponenten


    Genug für ein Badge!

    Das Projekt MUSS externe Abhängigkeiten in computerlesbarer Form auflisten. (URL erforderlich) [external_dependencies]

    External dependencies are controlled using the pom file for java projects, and via requirements.txt that is used by pip for python projects.

    https://gerrit.onap.org/r/gitweb?p=optf/has.git;a=blob;f=conductor/requirements.txt;h=d6d413d506df3fe82d2779f1e16fa2093a4f40f2;hb=HEAD https://gerrit.onap.org/r/gitweb?p=optf/osdf.git;a=blob;f=requirements.txt;h=23dc1b510f658d35dd8147b91b0201ef6fc42f7c;hb=HEAD https://gerrit.onap.org/r/gitweb?p=optf/cmso.git;a=blob;f=cmso-topology/pom.xml;h=553fe91bb27c9eb44d9bca8b78d991f1533c2f19;hb=HEAD


    Genug für ein Badge!

    Projekte MÜSSEN ihre externen Abhängigkeiten (einschließlich Bequemlichkeitskopien) überwachen oder regelmäßig überprüfen, um bekannte Schwachstellen zu erkennen und ausnutzbare Schwachstellen zu beheben oder sie als unausweichlich zu verifizieren. [dependency_monitoring]

    NexusIQ sonar scan is run on the project on a weekly basis: https://jenkins.onap.org/view/optf/


    Genug für ein Badge!

    Das Projekt MUSS entweder:
    1. Es einfach machen, wiederverwendbare extern gepflegte Komponenten zu identifizieren und zu aktualisieren;oder
    2. Die Standardkomponenten des Systems oder der Programmiersprache verwenden.
    Dann, wenn eine Schwachstelle in einer wiederverwendeten Komponente gefunden wird, wird es einfach sein diese Komponente zu aktualisieren. [updateable_reused_components]

    Identifying and Updating an external component simply involves making an update to the pom.xml or requirements.txt file for that project.


    Genug für ein Badge!

    Das Projekt SOLLTE vermeiden veraltete oder obsolete Funktionen und APIs zu verwenden, für die FLOSS-Alternativen in der eingesetzten Technologie verfügbar sind (ihr "Technologie-Stack") und eine Supermajorität der Benutzer, die das Projekt unterstützt (so dass die Benutzer den Zugriff auf die Alternative haben ). [interfaces_current]

    We avoid using deprecated and obsolete functions and APIs when possible. We use open source solutions in every case and choose up-to-date versions of the components.


  • Automatisierte Test-Suite


    Genug für ein Badge!

    Eine automatisierte Test-Suite MUSS bei jedem Check-In auf ein gemeinsames Repository für mindestens einen Zweig angewendet werden. Diese Test-Suite muss einen Bericht über Erfolg oder Misserfolg des Testes produzieren. [automated_integration_testing]

    Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.

    https://jenkins.onap.org/view/optf/


    Genug für ein Badge!

    Das Projekt MUSS Regressionstests zu einer automatisierten Test-Suite hinzufügen für mindestens 50% der, in den letzten sechs Monaten, gefixten Bugs. [regression_tests_added50]

    Tests are added for new code contributions and as regression occurs.


    Nicht genug für ein Badge.

    Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) haben, die mindestens 80% Aussage Berichterstattung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache erfüllen kann. [test_statement_coverage80]

    Code coverage is being enhanced progressively over each release, but it hasn't yet breached the 80% target.


  • Neue Funktionalitätsüberprüfung


    Genug für ein Badge!

    Das Projekt MUSS eine formale schriftliche Richtlinie dazu haben, wie wichtige neue Funktionalität hinzugefügt werden. Tests für die neue Funktionalität MÜSSEN zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy_mandated]

    Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies


    Genug für ein Badge!

    Das Projekt MUSS in seinen dokumentierten Anweisungen für Änderungsvorschläge die Richtlinien enthalten, die Tests für große neue Funktionalität hinzugefügt werden sollen. [tests_documented_added]

    The code coverage requirement is listed as a developer best practice here: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis


  • Warnhinweise


    Genug für ein Badge!

    Projekte MÜSSEN praktischerweise sehr streng mit Warnungen in der Projektsoftware sein. [warnings_strict]

    Sonarqube is used to analyze and report code smells and warnings, and the project is committed to fixing them.


  • Wissen über sichere Entwicklungspraktiken


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS sichere Designprinzipien (von "know_secure_design"), soweit anwendbar, umsetzen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). [implement_secure_design]

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

    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der Projektsoftware DÜRFEN NICHT von kryptographischen Algorithmen oder Modi mit bekannten schweren Mängeln abhängen (z.B. der SHA-1-Kryptographie-Hash-Algorithmus oder der CBC-Modus in SSH). [crypto_weaknesses]

    We use ONAP-wide recommended cryptographic protocols and algorithms: https://wiki.onap.org/pages/viewpage.action?pageId=15995347


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt SOLLTE mehrere kryptographische Algorithmen unterstützen, so dass Benutzer schnell wechseln können, wenn eines defekt ist. Verbreitete symmetrische Schlüsselalgorithmen umfassen AES, Twofish und Serpent. Verbreitete kryptographische Hash-Algorithmus-Alternativen umfassen SHA-2 (einschließlich SHA-224, SHA-256, SHA-384 UND SHA-512) und SHA-3. [crypto_algorithm_agility]

    Genug für ein Badge!

    Das Projekt MUSS die Speicherung von Anmeldeinformationen (z.B. Passwörter und dynamische Token) und private kryptografische Schlüssel in Dateien, die von anderen Informationen getrennt sind (z.B. Konfigurationsdateien, Datenbanken und Protokolle), unterstützen und den Benutzern erlauben, sie ohne Code-Neukompilierung zu aktualisieren und zu ersetzen . Wenn das Projekt keine Anmeldeinformationen und private kryptographische Schlüssel verarbeitet, wählen Sie "nicht anwendbar" (N/A). [crypto_credential_agility]

    All authentication credentials are being managed by an external secret management service. It will be fetched by the app during startup.


    Genug für ein Badge!

    Die vom Projekt produzierte Software SOLLTE 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 SOLLTEN 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]

    The project uses HTTPS protocol with TLS1.2


    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, TLS unterstützt oder verwendet, SOLLTE sie mindestens TLS Version 1.2 verwenden. 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]

    OOF components use AAF based certificate verification. https://jira.onap.org/browse/OPTFRA-223 https://jira.onap.org/browse/OPTFRA-263 https://jira.onap.org/browse/OPTFRA-461 https://jira.onap.org/browse/OPTFRA-391 https://jira.onap.org/browse/OPTFRA-293


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, muss, wenn es TLS unterstützt, die TLS-Zertifikatsüberprüfung standardmäßig bei der Verwendung von TLS, einschließlich auf Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_certificate_verification]

    OOF components use AAF based certificate verification. https://jira.onap.org/browse/OPTFRA-223 https://jira.onap.org/browse/OPTFRA-263 https://jira.onap.org/browse/OPTFRA-461 https://jira.onap.org/browse/OPTFRA-391 https://jira.onap.org/browse/OPTFRA-293


    Genug für ein Badge!

    Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, eine Zertifikatsüberprüfung durchführen, bevor HTTP-Header mit privaten Informationen (wie z.B. sichere Cookies) versendet werden. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). [crypto_verification_private]

    Role based authentication with AAF certs is performed prior to any processing.


  • Sicheres Release


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS kryptographisch unterschriebene Releases der Projektergebnisse aufzeichnen, die für weit verbreitete Verwendung gedacht sind, und es MUSS ein dokumentierter Prozess sein, der den Benutzern/innen erklärt, wie sie die öffentlichen Signaturschlüssel erhalten und die Signatur(en) überprüfen können. Der private Schlüssel für diese Signatur(en) MUSS NICHT auf der Seite(n) verwendet werden, die öffentlich zugänglich sind. Wenn Releases nicht für eine weit verbreitete Verwendung bestimmt sind, wählen Sie "nicht anwendbar" (N/A). [signed_releases]

    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Es wird empfohlen, dass in dem Versionskontrollsystem jeder wichtige Versions-Tag (ein Tag, der Teil eines Hauptrelease, eines kleineren Release, oder eines Fixes, öffentlich gemeldeten Schwachstellen, ist) kryptographisch signiert und verifizierbar ist, wie in Signed_releases. [version_tags_signed]

  • Andere Sicherheitsissues


    Nicht genug für ein Badge.

    Die Projektergebnisse MÜSSEN alle Eingaben aus potenziell nicht vertrauenswürdigen Quellen überprüfen, um sicherzustellen, dass sie gültig sind (eine *Allowliste*) und ungültige Eingaben ablehnen, wenn überhaupt Einschränkungen für die Daten vorliegen. [input_validation]

    All OOF APIs are exposed only within the ONAP cluster except opt_eng which exposes APIs to the user to create, update, and delete optimization models. This is newly introduced in the frankfurt release and it is not part of the deployment. There is a basic input validation being done for these APIs, but it has to be improved to reject invalid inputs.


    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Härtungsmechanismen SOLLTEN in der Software, die das Project entwickelt, verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. [hardening]

    Unbekannte erforderliche Informationen, nicht genug für ein Badge.

    Das Projekt MUSS einen "Assurance Case" bereithalten, der rechtfertigt, wie die Sicherheitsanforderungen erfüllt werden. Der Assurance Case muss Folgendes beinhalten: eine Beschreibung des Bedrohungsmodells, eine eindeutige Identifizierung von Vertrauensgrenzen, eine Beschreibung wie sichere Designprinzipien angewendet wurden, und eine Beschreibung wie die üblichen Implementierungssicherheitsschwächen beseitige wurden. (URL erforderlich) [assurance_case]

  • Statische Codeanalyse


    Genug für ein Badge!

    Das Projekt MUSS mindestens ein statisches Analyse-Tool mit Regeln oder Ansätzen verwenden, um nach bekannten Schwachstellen in der analysierten Sprache oder Umgebung zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache implementieren kann. [static_analysis_common_vulnerabilities]

    Sonar uses different rules for static code analysis. The list of rules used by OOF is at: https://sonar.onap.org/coding_rules#languages=py


  • Dynamische Codeanalyse


    Genug für ein Badge!

    Wenn die Projektsoftware Software mit einer speicherunsicheren Sprache (z.B. C oder C ++) enthält, MUSS mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Applikationsscanner) routinemäßig in Kombination mit einem Mechanismus verwendet werden, welche Speichersicherheitsproblemen wie Puffer-Cach Überschreibe erkennen. Wenn das Projekt keine Software verwendet, die in einer speicherunsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]

    The code is written in Python, which is a memory-safe language.



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 mrsjackson76 und die OpenSSF Best Practices Badge Mitwirkenden an.

Projekt-Badge-Eintrag im Besitz von: mrsjackson76.
Eintrag erstellt: 2018-03-13 13:12:11 UTC, zuletzt aktualisiert: 2021-02-17 10:13:35 UTC. Letztes verlorenes Badge: 2019-05-28 15:49:38 UTC. Letztes erreichtes Badge: 2019-11-05 18:02:59 UTC.

Zurück