ONAP APPC (Application Controller)

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

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

        

 Grundlagen 12/13

  • Identifizierung

    ONAP APPC is one of the components of the ONAP platform. It is responsible for handling the Life Cycle Management (LCM) of Virtual Network Functions (VNFs). ONAP APPC infrastructure is implemented on virtual machine in an OpenStack cloud in the Amsterdam release. ONAP APPC is created on the top of the OpenDaylight (ODL) platform. ONAP APPC contains three containers: VM#1: ONAP APPC(ODL Framework & APPC OSGI Bundles), VM#2: MYSQL DB, VM#3: DG Builder ( as of Amsterdam release) The ONAP APPC HTTP API supports LCM commands, allowing users to manage virtual applications and their components via other ONAP components.

    Welche Programmiersprache wird verwendet, um das Projekt umzusetzen?
  • Grundlegende Informationen auf der Projektwebseite


    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]

    The description of the software could be found in the following URL: https://wiki.onap.org/pages/viewpage.action?pageId=3246996



    Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. [interact]

    The following URLs describe the process to join the community, developing the software and provide feedback: https://wiki.onap.org/display/DW/Joining+the+Community, https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA, https://wiki.onap.org/display/DW/Developing+ONAP



    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]

    The process could be found in the following URL: https://wiki.onap.org/display/DW/Development+Procedures+and+Policies



    Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z. B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) [contribution_requirements]

    The Javascript 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/jsguide.html We avoid the restriction on the number of characters in one line of code to improve readability.


  • FLOSS-Lizenz

    Unter welcher Lizenz/welchen Lizenzen ist das Projekt veröffentlicht?



    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. [floss_license_osi]

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).



    Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) [license_location]
  • Dokumentation


    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]

    The documentation describing the project can be found in http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/index.html



    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]

    APPC is a part of the ONAP. Documentation on how to install ONAP can be found in : http://onap.readthedocs.io/en/latest/guides/onap-developer/settingup/fullonap.html


  • Andere


    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]

    Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]

    A mailing list is used for project related discussion. New users could also check, search the old discussion online at onap-discuss website: https://wiki.onap.org/display/DW/Joining+the+Community



    Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. [english]

    JIRA is used to track bugs. The whole website is in English. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA



    The project MUST be maintained. [maintained]

    The APPC project has been archived.



(Erweitert) Welche anderen Benutzer haben zusätzliche Rechte zum Bearbeiten dieses Badge-Antrags? Derzeit: [2044]



  • Öffentliches Versionskontroll-Source-Repository


    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]

    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]

    Tracking is provided by using a combination of JIRA and git history. Every commit has an user and a Jira number attached to it. Git history for APPC's master branch:https://gerrit.onap.org/r/#/q/projects:+appc Jira for ONAP: https://jira.onap.org/secure/Dashboard.jspa



    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es DARF NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]

    Gerrit provides an temperate branch for reviewing and providing comments. Once approved, the code will be merged and the temperate branch will be removed.



    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]

    Git and Gerrit are used.


  • Einzigartige Versionsnummerierung


    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]

    Release version is with format ${major}.${minor}.${patch} and will be updated accordingly for each release.



    Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]


    Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [version_tags]

    Each release is tagged within the Gerrit repository.


  • Versionshinweise


    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes DÜRFEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z. B. die "git log"-Befehlsergebnisse sind keine Releasenotes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z. B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]

    Die Releasenotes MÜSSEN jede öffentlich bekannte Laufzeit-Sicherheitslücke mit einer CVE-Zuweisung oder Ähnlichem kennzeichnen, die in der aktuellen veröffentlichten Version behoben sind. Dieses Kriterium darf als nicht anwendbar (N/A) markiert werden, wenn Benutzer typischerweise nicht selbst die Software aktualisieren. Diese Kirterium trifft nur auf die Projektergebnisse zu, nicht auf Abhängikeiten. Wenn keine Releasenotes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie (N/A). [release_notes_vulns]

    Release notes with identified vulnerabilities can be found in http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/release-notes.html

    No vulnerabilities have yet been identified.


  • Bug-Report-Prozess


    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue-Tracker oder eine Mailing-Liste). (URL erforderlich) [report_process]

    The description of the process can be found in the following URL: https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA



    Das Projekt SOLLTE einen Issue-Tracker für die Nachverfolgung einzelner Issues verwenden. [report_tracker]

    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]

    The reported issues are being handled as soon as possible.



    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]

    The reported issues are being handled as soon as possible.



    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [report_archive]

    The report of issues are listed here: https://wiki.onap.org/display/DW/Issue+Reports


  • Anfälligkeits-Prozessbericht


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

    The process on how to report a vulnerability can be found in https://wiki.onap.org/display/DW/ONAP+Vulnerability+Management



    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]

    Private vulnerability reports are not supported.



    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]

    There's no vulnerabilities reported so far.


  • Produktivsystem


    Falls die vom Projekt entwickelte Software vor Benutzung kompiliert werden muss, MUSS das Projekt ein funktionierendes Buildsystem bereitstellen, das den Quellcode automatisch in Software übersetzt. [build]

    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. [build_common_tools]

    Maven is used to build the project



    Das Projekt SOLLTE allein mit FLOSS-Werkzeugen gebaut werden können. [build_floss_tools]

    Maven is under Apache 2.0 license.


  • Automatisierte Test-Suite


    Das Projekt MUSS mindestens eine automatisierte Test-Suite verwenden, die öffentlich als FLOSS veröffentlicht wird (diese Test-Suite kann als separates FLOSS-Projekt gepflegt werden). Das Project MUSS verständlich zeigen oder dokumentieren, wie die Test-Suite ausgeführt wird (z. B. durch ein Continuous Integration (CI) Script oder als Dokumentation in Dateien, wie z. B. BUILD.md, README.md oder CONTRIBUTING.md). [test]

    APPC uses JUNIT and mockito to run the unit tests



    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]

    Tests can be run, by running the command "mvn test"



    Es wird erwartet, dass die Test-Suite die meisten (oder idealerweise alle) Code-Zweige, Eingabefelder und Funktionalitäten abdeckt. [test_most]

    The combination of junit and mockito has the ability to cover all the branches and input fields



    Es wird erwartet, dass das Projekt eine kontinuierliche Integration durchführt (wo neuer oder geänderter Code häufig in ein zentrales Code-Repository integriert wird und automatisierte Tests auf diesen Ergebnissen durchgeführt werden). [test_continuous_integration]

    For each pull request, the project needs to be built successfully before the Merge option becomes activated. The test will be run automatically during the building process as well. Once build successfully and all tests has past, the Merge option will be activated.


  • Neue Funktionalitätsüberprüfung


    Das Projekt MUSS allgemeine Grundregeln (formal oder nicht) haben, die als wesentliche neue Funktionalität der Software des Projektes hinzugefügt werden. Tests dieser Funktionalität sollten zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy]

    The code coverage is evaluated by Sonar on daily bases. If the code coverage reduced, actions will be taken to add more test cases. All tests on for Clamp is trigger by Maven build and could be launched automatically by Jenkins.



    Das Projekt MUSS nachweisen, dass die test_policy für das Hinzufügen von Tests in den jüngsten großen Änderungen an der Projektsoftware eingehalten wurde. [tests_are_added]

    The daily sonar report contains a link for recent overall coverage on the new code. Here is the link: https://sonar.onap.org/drilldown/measures?id=org.onap.appc%3Aappc&metric=new_overall_uncovered_lines&period=1&highlight=new_overall_coverage



    Es wird erwartet, dass diese Richtlinien zum Hinzufügen von Tests (siehe test_policy ) in den Anweisungen für Änderungsvorschläge dokumentiert werden. [tests_documented_added]
  • Warnhinweise


    Das Projekt MUSS einen oder mehrere Compiler-Warn-Flags, einen "sicheren" Sprachmodus oder ein separates "Linter" -Tool verwenden, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium implementieren kann in der gewählten sprache [warnings]

    Sonar is used to examine the quality of the source code. Sonar uses different rules to verify the quality of the code and to address the vulnerability of the code.



    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]

    A task is created in JIRA to remove such warnings in a continuous way. https://jira.onap.org/browse/APPC-254



    Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. [warnings_strict]

    Build systems run the compile with test flag enabled by default. So any failure in test cases will fail the ci and the merge request.


  • Wissen über sichere Entwicklungspraktiken


    Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]


    Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]

  • 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 entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). [crypto_published]

    Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. [crypto_call]

    APPC is using java.security.Provider, and javax.crypto.Cipher classes to implement cryptographic function.



    Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. [crypto_floss]

    APPC is using java.security.Provider, and javax.crypto.Cipher classes to implement cryptographic function. all those classes are using FLOSS.



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. [crypto_keylength]


    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. [crypto_working]

    APPC runs security scan software to uncover any security risks.



    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). [crypto_weaknesses]

    APPC runs security scan software to uncover any security risks.



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN Perfect Forward Secrecy für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. [crypto_pfs]

    Security scans are used to ensure this is not comprised.



    Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, 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). Siehe auch OWASP Password Storage Cheat Sheet). [crypto_password_storage]

    In Beijing release, we are going to use AAF for user authentication and authorization. also Openstack credentials are used in the APPC encryption tool



    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DÜRFEN NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. [crypto_random]

    cryptographic encrypted key is generated by java.security.Provider and javax.crypto.Cipher classed provided by Java.


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


    Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. [delivery_mitm]

    The website to store the delivered software is: https://nexus3.onap.org/



    Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]

  • Öffentlich bekannte Schwachstellen wurden behoben


    Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]

    Updated 2019-05-08: Several Vulnerabilities are inherited by Open Day Light (ODL) open source project. APPC is strongly based on ODL. APPC/SDNC had meeting with ODL community with SECCOM.



    Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. [vulnerabilities_critical_fixed]

    APPC uses tool like Sonar to detect vulnerabilities and fix it as soon as possible when find any.


  • Andere Sicherheitsissues


    Die öffentlichen Repositorys DÜRFEN NICHT gültige private Zugriffsdaten enthalten (z. B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. [no_leaked_credentials]

    APPC uses a sample or test credential for testing in onap.org FQDN, which is in onap source code. User can read source code or follow the document, then change the credential for their own environment.


  • Statische Codeanalyse


    Mindestens ein Tool zur Analyse statischer Codes (über Compiler-Warnungen und "sichere" Sprachmodi hinaus) MUSS vor der Veröffentlichung auf jede vorgeschlagene größere Produktionsversion der Software angewendet werden, wenn mindestens ein FLOSS-Tool dieses Kriterium in der ausgewählten Sprache implementiert. [static_analysis]

    Sonar is used for static code analysis. https://sonar.onap.org



    Es wird davon ausgegangen, dass mindestens eines der statischen Analysewerkzeuge, die für das statische Analysekriterium verwendet wurde, Regeln oder Ansätze einschließt, um nach häufigen Schwachstellen in der analysierten Sprache oder Umgebung zu suchen. [static_analysis_common_vulnerabilities]

    Sonar uses different rules for static code analysis. The list of rules used by APPC is: https://sonar.onap.org/coding_rules#qprofile=java-sonar-way-74911|activation=true



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. [static_analysis_fixed]

    A task is created in JIRA to remove such warnings in a continuous way https://jira.onap.org/browse/APPC-254



    Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. [static_analysis_often]

    it's triggered daily


  • Dynamische Codeanalyse


    Es ist EMPFHOLEN, dass mindestens ein dynamisches Analyse-Tool auf jede vorgeschlagene größere Veröffentlichung der Software vor seiner Freigabe angewendet wird. [dynamic_analysis]

    Sonar is used as Dynamic code analysis tool.



    Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software, falls sie Software von einer Speicher-unsicheren Sprache (z. B. C oder C ++) enthält, regelmäßig mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Anwendungs-Scanner) in Kombination mit einem Mechanismus zur Erkennung von Speichersicherheitsproblemen wie Puffer-Overwrites verwendet. Wenn das Projekt keine Software entwickelt, die in einer Speicher-unsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]

    APPC uses Java



    Es ist EMPFHOLEN, dass das Projekt eine Konfigurations benutzt, die zumindest etwas dynamischen Analyse nutzt (wie z.B. testing oder fuzzing), welche Assertions erlauben. In vielen Fällen sollten diese Assertions nicht in Production Builds aktiviert sein. [dynamic_analysis_enable_assertions]

    only JUNIT does assertions, not for run-time.



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. [dynamic_analysis_fixed]

    After discovering the vulnerabilities, they will be fixed as soon as possible. A task is created in JIRA to remove such warnings in a continuous way. https://jira.onap.org/browse/APPC-254



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-01-22 14:57:37 UTC, zuletzt aktualisiert: 2023-06-13 15:51:52 UTC.

Zurück