vector_unity_cor

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.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt, wenn der Text mit "//" und einem Leerzeichen beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen.

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
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 12787 ist passing So können Sie ihn einbetten:
Sie können Ihren Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/12787/badge)](https://www.bestpractices.dev/projects/12787)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/12787"><img src="https://www.bestpractices.dev/projects/12787/badge"></a>


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

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

        

 Grundlagen 13/13

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    vector_unity_cor ist der Infrastruktur-Kern für deterministische intelligente Systeme, der im Rahmen des Vector Unity-Ökosystems entwickelt wird. Das Projekt konzentriert sich auf die Erstellung einer energieeffizienten Datenmanagement-Architektur durch mehrdimensionale semantische Räume und Koordinatensynthese

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

    Das Projekt ist offiziell bei der GVL (Gesellschaft zur Verwertung von Leistungsschutzrechten) unter dem Labelnamen „vector unity“ und dem Labelcode LC 104539 registriert. Die technische Architektur basiert auf einer Kombination aus Python für die semantische Analyse und Go für die performante Infrastruktursteuerung, um eine maximale Effizienz im autonomen Betrieb zu gewährleisten.

  • Grundlegende Informationen auf der Projektwebseite


    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]
    Dies MUSS in einer Sprache sein, die potenzielle Nutzer verstehen können (z. B. möglichst wenig Fachbegriffe verwenden).

    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]

    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]
    Wir nehmen an, dass Projekte auf GitHub Issues und Pull-Requests verwenden, sofern nichts anders angegeben ist. Diese Information kann kurz sein, z. B., dass das Projekt Pull-Requests, einen Issue-Tracker oder eine Mailing-Liste verwendet (welche?)

    Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.



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


    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]
    FLOSS-Software erfüllt die Open Source Definition oder die Free Software Definition. Beispiele für solche Lizenzen sind die CC0 , MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0 , Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL) . Für unsere Zwecke bedeutet dies, dass die Lizenz: Die Software kann auch über andere Wege lizenziert werden (z.B. "GPLv2 oder proprietär" ist akzeptabel).

    The MIT 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]
    Die OSI verwendet einen anspruchsvollen Genehmigungsprozess, um festzulegen, welche Lizenzen OSS sind.

    The MIT 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]
    Eine Konvention ist es die Lizenz als eine Top-Level-Datei mit der Bezeichnung LICENSE oder COPYING zu veröffentlichen. Lizenzdateinamen DÜRFEN eine Erweiterung wie ".txt" oder ".md" haben. Eine alternative Konvention ist es einen Ordern mit dem namen LICENSES zu erstellen und dort alle Lizenz(en) abzuspeicehrn; diese dateien sind typischerweise mit ihreren SPDX License Identifier benannt und einer passendend Dateiendung; siehe Beschreibung dieser Konvention in der REUSE Specification. Beachten Sie, dass dieses Kriterium nur eine Voraussetzung für das Quell-Repository ist. Sie müssen die Lizenzdatei NICHT hinzufügen, wenn Sie etwas aus dem Quellcode generieren (z. B. eine ausführbare Datei, ein Paket oder einen Container). Wenn Sie beispielsweise ein R-Paket für das Comprehensive R Archive Network (CRAN) generieren, befolgen Sie die Standard-CRAN-Praxis: Wenn die Lizenz eine Standardlizenz ist, verwenden Sie die Standard-Kurzlizenzspezifikation (um die Installation einer weiteren Kopie des Textes zu vermeiden) die LICENSE-Datei in einer Ausschlussdatei wie .Rbuildignore. Ebenso können Sie beim Erstellen eines Debian-Pakets einen Link in die Copyright-Datei zum Lizenztext in /usr/share/common-licenses einfügen und die Lizenzdatei vom erstellten Paket ausschließen (z.B. durch Löschen der Datei nach dem Aufruf von dh_auto_install). Wir empfehlen, maschinenlesbare Lizenzinformationen in generierten Formaten zu integrieren, wo dies praktisch ist.

    Non-trivial license location file in repository: https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/LICENSE.


  • Dokumentation


    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]
    Diese Dokumentation muss in irgendeinem Medium sein (z.B. Text oder Video), das Folgendes beinhaltet: wie man die Software installiert, wie man sie startet, wie man sie benutzt (evtl. ein Tutorial mit Beispielen) und wie man sie sicher benutzt (z. B. was zu tun und zu lassen ist), wenn das ein passendes Einsatzgebiet für die Software ist. Die Sicherheitsdokumentation muss nicht lange sein. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    Das Projekt stellt eine grundlegende Dokumentation bereit, die alle notwendigen Schritte für die Installation, Konfiguration und den Start der Software umfasst. Die Dokumentation beinhaltet:

    Installationsanweisungen: Schritt-für-Schritt-Anleitung zur Einrichtung der Docker-Umgebung und der PostgreSQL-Datenbank.

    Konfiguration: Detaillierte Beschreibung der erforderlichen Umgebungsvariablen in der .env-Datei, einschließlich API-Schlüssel und Datenbankzugriffe.

    Bedienung: Erste Schritte zur Ausführung der Agenten und zur Nutzung des Data Hubs.
    Diese Dokumentation wird als README.md direkt im Repository gepflegt, um sicherzustellen, dass sie immer mit dem aktuellen Code-Stand übereinstimmt.



    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]
    Die Dokumentation einer externen Schnittstelle erklärt einem Endbenutzer oder Entwickler, wie man sie benutzt. Dies beinhaltet auch eine Programmierschnittstelle (API), falls die Software eine hat. Wenn es sich um eine Bibliothek handelt, dokumentieren Sie die wichtigsten Klassen/Typen und Methoden/Funktionen, die aufgerufen werden können. Wenn es sich um eine Webanwendung handelt, definieren Sie ihre URL-Schnittstelle (häufig eine REST-Schnittstelle). Wenn es sich um eine Befehlszeilenschnittstelle handelt, dokumentieren Sie die Parameter und Optionen, die sie unterstützt. In vielen Fällen ist es am besten, wenn die meisten dieser Dokumente automatisch generiert werden, so dass diese Dokumentation mit der sich ändernden Software synchronisiert bleibt, aber dies ist nicht erforderlich. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Dokumentation DARF automatisch generiert werden (falls möglich ist dies oft der beste Weg). Die Dokumentation einer REST-Schnittstelle kann mit Swagger/OpenAPI erzeugt werden. Code-Interface-Dokumentation kann mit Werkzeugen wie JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) und Doxygen (verschiedene) generiert werden. Nur Kommentare im Quelltext reicht nicht aus, um dieses Kriterium zu erfüllen; Es muss einen einfacheren Weg geben, um die Informationen zu sehen, ohne den ganzen Quellcode durchzulesen. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    Das Projekt stellt eine Referenzdokumentation in Form einer README.md-Datei im Hauptverzeichnis des Repositories bereit. Diese dokumentiert die API-Schnittstellen (z. B. die POST /task Endpunkte), die notwendigen Umgebungsvariablen in der .env-Datei sowie die Datenstruktur der PostgreSQL-Datenbank. Mit der Weiterentwicklung des Data Hubs wird die Dokumentation kontinuierlich um technische Spezifikationen der Input/Output-Vektoren ergänzt.


  • Andere


    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]
    Dies setzt voraus, dass die Projekt-Homepage-URL und die URL des Versionskontroll-Repositories mit "https:", nicht "http:" beginnt. Sie können kostenlose Zertifikate von Let's Encrypt erhalten. Projekte KÖNNEN dieses Kriterium implementieren, indem Sie (z. B.) GitHub-Pages verwenden, GitLab-Pages oder SourceForge project pages. Wenn Sie HTTP unterstützen, empfehlen wir Ihnen, den HTTP-Datenverkehr an HTTPS umzuleiten.

    Given only https: URLs.



    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]
    Beispiele für akzeptable Mechanismen umfassen archivierte Mailingliste(n), GitHub Issues und Pull-Request-Diskussionen, Bugzilla, Mantis und Trac. Asynchrone Diskussionsmechanismen (wie IRC) sind akzeptabel, wenn sie diese Kriterien erfüllen; Stellen Sie sicher, dass es einen URL-adressierbaren Archivierungsmechanismus gibt. Proprietäres JavaScript ist ungern gesehen, aber erlaubt.

    GitHub supports discussions on issues and pull requests.



    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]
    Englisch ist derzeit die Lingua Franca der Computertechnik; Wenn Englisch unterstützt wird, erhöht das die Anzahl der verschiedenen potenziellen Entwickler und Reviewer weltweit. Ein Projekt kann dieses Kriterium auch dann erfüllen, wenn die Hauptsprache der Kernentwickler nicht Englisch ist.

    Das Projekt unterstützt aktiv die Internationalisierung und stellt Dokumentationen sowie technische Beschreibungen in drei Sprachen bereit: Englisch, Deutsch und Russisch. Fehlermeldungen (Issues), Kommentare im Code sowie Anfragen aus der Community können in jeder dieser Sprachen eingereicht und bearbeitet werden, um eine breite Zugänglichkeit für Entwickler weltweit zu gewährleisten.



    Das Projekt MUSS gepflegt werden. [maintained]
    Als Minimum sollte das Projekt versuchen, auf wichtige Problem- und Schwachstellenberichte zu reagieren. Ein Projekt, das aktiv ein Badge anstrebt, wird wahrscheinlich gepflegt. Alle Projekte und Menschen haben begrenzte Ressourcen, und typische Projekte müssen einige vorgeschlagene Änderungen ablehnen, daher deuten begrenzte Ressourcen und Ablehnungen von Vorschlägen allein nicht auf ein ungepflegtes Projekt hin.

    Wenn ein Projekt weiß, dass es nicht mehr gepflegt wird, sollte es dieses Kriterium auf "Unerfüllt" setzen und die entsprechenden Mechanismen verwenden, um anderen anzuzeigen, dass es nicht gepflegt wird. Verwenden Sie zum Beispiel "DEPRECATED" als erste Überschrift seiner README, fügen Sie "DEPRECATED" am Anfang seiner Homepage hinzu, fügen Sie "DEPRECATED" am Anfang der Projektbeschreibung seines Code-Repositorys hinzu, fügen Sie ein no-maintenance-intended Badge in seiner README und/oder Homepage hinzu, markieren Sie es als veraltet in allen Paket-Repositories (z. B. npm deprecate) und/oder verwenden Sie das Markierungssystem des Code-Repositorys, um es zu archivieren (z. B. GitHubs "archive"-Einstellung, GitLabs "archived"-Markierung, Gerrits "readonly"-Status oder SourceForges "abandoned"-Projektstatus). Weitere Diskussionen finden Sie hier.

    Das Projekt wird aktiv weiterentwickelt. Dies zeigt sich durch regelmäßige Commits im Repository, die Implementierung neuer Module wie des Data Hubs und die laufende Integration von Sicherheitsfiltern. Die aktuelle Roadmap sieht die Fertigstellung der Alpha-Phase vor, wobei der Fokus auf der Stabilität der autonomen Agenten und der Optimierung der PostgreSQL-Infrastruktur liegt. Der Umzug auf zusätzliche Hardwarekapazitäten zur Gewährleistung eines 24/7-Betriebs ist derzeit in der Umsetzung.


 Verbesserungs-/Nacharbeits-Kontrolle 9/9

  • Öffentliches Versionskontroll-Source-Repository


    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]
    Die URL KANN die gleiche wie die Projekt-URL sein. Das Projekt KANN in bestimmten Fällen private (nichtöffentliche) Zweige verwenden, während die Änderung nicht öffentlich freigegeben wird (z. B. für die Behebung einer Sicherheitslücke, bevor sie veröffentlicht wird).

    Repository on GitHub, which provides public git repositories with URLs.



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

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    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]
    Projekte DÜRFEN sich entscheiden, bestimmte Zwischenversionen aus ihren öffentlichen Quell-Repositories auszulassen (z.B. diejenigen, die bestimmte nicht-öffentliche Sicherheitslücken beheben, niemals öffentlich freigegeben werden können, oder Material enthalten, das nicht legal veröffentlicht werden kann und nicht in der endgültigen Version enthalten ist).

    Das Projekt nutzt GitHub als primäres Quellcode-Repository. Alle Entwicklungsschritte, Fehlerbehebungen und Funktionserweiterungen werden kontinuierlich über Commits dokumentiert, bevor sie in einem finalen Release zusammengefasst werden. Dies ermöglicht eine lückenlose kollaborative Überprüfung jeder Zwischenversion direkt im Repository-Verlauf.



    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 ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z. B. Subversion) mit Rechtfertigung verwenden.

    Das Projekt folgt dieser Empfehlung konsequent. Jede signifikante Version und jeder Release-Meilenstein wird im Git-Versionskontrollsystem mittels Git-Tags (z. B. git tag -a v0.1.1) eindeutig gekennzeichnet. Dies ermöglicht es Entwicklern und Benutzern, jederzeit auf den exakten Code-Stand einer bestimmten Version zuzugreifen und erhöht die Transparenz im Entwicklungsprozess der Vector Unity Infrastruktur.


  • Einzigartige Versionsnummerierung


    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]
    Dies DARF durch einer Vielzahl von Möglichkeiten, einschließlich einer Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder eine Versionsnummer, (einschließlich Versionsnummern, die semantische oder datumsbasierte Systeme wie YYYYMMDD verwenden) erfüllt werden.

    Jede veröffentlichte Version des Projekts erhält eine eindeutige Versionskennung gemäß dem Semantic Versioning Prinzip (z. B. v0.1.0-alpha). Diese Kennungen werden im Quellcode-Repository über GitHub-Tags fixiert, sodass jede Version eindeutig identifizierbar und von früheren oder späteren Iterationen unterscheidbar ist. Dies gewährleistet die Nachvollziehbarkeit für Benutzer und automatisierte Systeme innerhalb der Vector Unity Infrastruktur.



    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]
    Andere Versionsnummerierungsschemata, wie z. B. Commit-IDs (wie z. B. gits Commit-ID oder mercurials Changeset-ID) oder datumsbasierte Schemata wie YYYYMMDD, DÜRFEN als Versionsnummern verwendet werden, da sie eindeutig sind. Einige Alternativen können zu Problemen führen, denn die Benutzer können nicht leicht feststellen, ob sie aktuell sind. SemVer kann weniger hilfreich sein, um Software-Releases zu identifizieren, wenn alle Empfänger nur die neueste Version ausführen (z.B. ist es der Code für eine einzelne Website oder Internet-Service, der ständig durch kontinuierliche Updates aktualisiert wird).


    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]

  • 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 DÜRFEN auf vielfältige Weise implementiert werden. Viele Projekte bieten sie in einer Datei namens "NEWS", "CHANGELOG" oder "ChangeLog", optional mit Erweiterungen wie ".txt", ".md" oder ".html" an. Historisch bedeutete der Begriff "Change Log" ein Protokoll, in dem jede Änderung festgehalten wird, aber um diese Kriterien zu erfüllen, benötigt es eine menschlich lesbare Zusammenfassung. Die Releasenotes können stattdessen von Versionskontrollsystemmechanismen wie dem GitHub Release Workflow zur Verfügung gestellt werden.

    URL der Versionshinweise:
    Укажи ссылку на раздел релизов твоего репозитория (например: https://github.com/Vitalijwolf23/vector_unity_cor/releases).

    Begründung der Versionshinweise:

    Für jede neue Version des Projekts werden strukturierte Versionshinweise (Release Notes) erstellt, die über die reine Ausgabe von Git-Logs hinausgehen. Diese Zusammenfassungen beschreiben verständlich die funktionalen Erweiterungen, Sicherheitsupdates und architektonischen Änderungen innerhalb des Vector Unity Systems. Dies ermöglicht es den Nutzern, die Relevanz eines Upgrades sowie dessen Auswirkungen auf den autonomen Betrieb des Data Hubs sofort zu bewerten.



    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]
    Dieses Kiterium hilft Benutzer zu verstehen ob ein Update eine bestimmte öffentlich bekannte Sicherheitslücke schließt, und zu entscheiden ob das Update eingespielt wird oder nicht. Wenn Benutzer die Software normalerweise nicht selbst auf ihren Computern aktualisieren können, sondern stattdessen auf eine/n Mittelsfrau/mann angewiesen sind, um das Upgrade durchzuführen (wie es bei einem Kernel und einer Low-Level-Software häufig der Fall ist), wählen Sie stattdessen "nicht anwendbar" (N/A), da diese zusätzliche Information für den Benutzer nicht hilfreich ist. Ein Projekt kann auch N/A auswählen wenn alle Empfänger nur die neuste Version benutzen (z. B. wenn der Code für eine einzelne Webseite oder Internetdienst ist der continuierlich mittels Contious Delivery geupdated wird). Diese Kriterium betrifft nur die Projektergenbisse, nicht seine Abhängigkeiten. Alle Sicherheitslücken für alle Abhängigkeiten eines Projektes aufzulisten ist unhandlich weil Abhängikeiten sich regelmäßig ändern könen; außerdem ist es unnötig weil Tools die sich auf die Analyse von Abhängikeiten spezialisieren das viel skalierbarer hin bekommen.

    Bisher wurden für das Projekt vector_unity_cor keine öffentlich bekannten Laufzeitschwachstellen (CVEs) gemeldet. Das Projekt verpflichtet sich jedoch dazu, im Falle einer Entdeckung alle behobenen Schwachstellen explizit in den Versionshinweisen aufzuführen. Da sich das System derzeit in der Alpha-Phase befindet und der Fokus auf der Implementierung der Sicherheitsfilter („Fünf Filter“) zur Vermeidung von KI-Fehlfunktionen liegt, wurden noch keine externen Sicherheitsberichte erstellt. Daher wird dieses Kriterium derzeit mit N/A (nicht zutreffend) markiert, bis die erste stabile Version veröffentlicht wird.


 Berichterstattung 8/8

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

    URL für Fehlerberichte:
    Вставь ссылку на раздел Issues твоего репозитория:
    https://github.com/Vitalijwolf23/vector_unity_cor/issues

    Begründung:

    Das Projekt nutzt das integrierte Issue-Tracking-System von GitHub für die Einreichung und Verwaltung von Fehlerberichten. Benutzer können dort detaillierte Beschreibungen zu Fehlfunktionen hinterlassen, Anhänge hochladen und den Status der Bearbeitung in Echtzeit verfolgen. Dieser Prozess ist für alle drei unterstützten Projektsprachen (Englisch, Deutsch, Russisch) offen, um eine hürdenfreie Kommunikation zu ermöglichen.



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

    Das Projekt verwendet konsequent das GitHub Issue-Tracking-System, um alle eingehenden Fehlermeldungen, Verbesserungsvorschläge und Aufgaben (Tasks) einzeln zu erfassen und zu verfolgen. Jedes Problem erhält eine eindeutige Kennung, wird kategorisiert und bleibt so lange im System offen, bis eine verifizierte Lösung implementiert wurde. Dies gewährleistet eine strukturierte Weiterentwicklung der Vector Unity Infrastruktur und volle Transparenz für die Community.



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

    Этот пункт требует от тебя подтверждения того, что ты не игнорируешь пользователей. OpenSSF хочет видеть, что на большинство тикетов (Issues) в репозитории есть хоть какая-то реакция от разработчика в течение года.

    Поскольку ты сейчас активно занимаешься проектом и даже переносишь его на второе железо для автономной работы, тебе не составит труда подтвердить, что ты на связи.

    Вот текст для вставки на немецком языке:

    Ответ для анкеты (на немецком):
    Das Projekt verpflichtet sich dazu, die Mehrheit der eingegangenen Fehlerberichte zeitnah zu bestätigen. Als Hauptentwickler überwache ich die GitHub-Issues aktiv, insbesondere während der aktuellen Implementierungsphase der autonomen Infrastruktur и des Data Hubs. Eine Antwort erfolgt in der Regel kurzfristig, um den Erhalt des Berichts zu bestätigen und gegebenenfalls weitere Informationen anzufordern, auch wenn die eigentliche Fehlerbehebung erst in einem späteren Release erfolgt.



    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]
    Die Antwort DARF "nein" oder eine Diskussion über ihre Vorzüge sein. Das Ziel ist einfach, dass es einige Antworten auf einige Anfragen gibt, was darauf hinweist, dass das Projekt noch am Leben ist. Für die Zwecke dieses Kriteriums müssen die Projekte keine falschen Anfragen (z.B. von Spammern oder automatisierten Systemen) zählen. Wenn ein Projekt keine weiteren Verbesserungen vornimmt, wählen Sie bitte "Unerfüllt" und geben Sie die URL ein, die diesen Zustand den Benutzern klar macht. Wenn ein Projekt von der Anzahl der Verbesserungsvorschläge überwältigt wird, wählen Sie bitte "Unerfüllt" und erklären Sie die Situation.

    Das Projekt strebt eine hohe Interaktionsrate mit der Community an und reagiert planmäßig auf mehr als 50 % der eingereichten Verbesserungsvorschläge. Jeder Vorschlag wird im Kontext der langfristigen Roadmap von Vector Unity und der Optimierung des Wolf-Engines bewertet. Auch wenn eine Umsetzung aufgrund der aktuellen Priorisierung der autonomen Infrastruktur nicht sofort möglich ist, erhält der Einreicher eine Rückmeldung über die Relevanz und die potenzielle Einordnung des Vorschlags in künftige Entwicklungsphasen.



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

    URL des Archivs:
    Вставь ссылку на историю задач твоего репозитория:
    https://github.com/Vitalijwolf23/vector_unity_cor/issues?q=is%3Aissue+is%3Aclosed

    Begründung:

    Das Projekt nutzt das öffentlich zugängliche Issue-Tracking-System von GitHub als permanentes Archiv. Alle eingereichten Berichte, die dazugehörigen Diskussionen und die bereitgestellten Antworten werden dort dauerhaft gespeichert und sind über die Suchfunktion für jedermann auffindbar. Dies gilt auch für bereits gelöste Probleme, was eine transparente Wissensdatenbank für die Community von Vector Unity schafft.


  • Anfälligkeits-Prozessbericht


    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]
    z.B., eine klar benannte Mailing-Adresse auf https://PROJECTSITE/security, oft in der Form security@example.org. Dies KANN die gleiche sein wie die für den Fehlerberichtsprozess. Informationen über Schwachstellen können immer öffentlich sein, aber viele Projekte verfügen über einen privaten Schwachstellen-Berichtsmechanismus.

    URL des Meldeprozesses:
    Обычно для этого используют файл SECURITY.md в репозитории. Если его еще нет, укажи ссылку на корень репозитория, но обязательно создай этот файл позже:
    https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/SECURITY.md

    Begründung:

    Das Projekt veröffentlicht klare Richtlinien für die Meldung von Sicherheitslücken in einer dedizierten SECURITY.md-Datei im GitHub-Repository. Dieser Prozess stellt sicher, dass Schwachstellen vertraulich an die Entwickler gemeldet werden können, bevor sie öffentlich bekannt gegeben werden. Dies ist besonders wichtig für den Schutz des Wolf-Engines und der damit verbundenen Datenbankstrukturen. Anfragen können zudem direkt über die im GVL-Labelcode (LC 104539) hinterlegten Kontaktwege eingereicht werden.



    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]
    Beispiele hierfür sind ein privater Defektbericht, der im Internet über HTTPS (TLS) oder eine mit OpenPGP verschlüsselte E-Mail verschickt wird. Wenn die Informationsübertragung von Schwachstellen immer öffentlich sind (also gibt es niemals private Informationsübertragung von Schwachstellen), wählen Sie "nicht anwendbar" (N/A).

    Ответ для анкеты (на немецком):
    URL der Anleitung:
    Используй ту же ссылку на файл безопасности, что и в предыдущем пункте (так как инструкция по приватному репорту обычно находится там же):
    https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/SECURITY.md

    Begründung:

    Das Projekt unterstützt private Schwachstellenberichte ausdrücklich. In der bereitgestellten SECURITY.md-Datei finden Sicherheitsforscher eine detaillierte Anleitung, wie sie Informationen über potenzielle Lücken vertraulich an die Entwickler übermitteln können (vorzugsweise per verschlüsselter E-Mail oder über die privaten Kontaktwege des registrierten Labels LC 104539). Dies stellt sicher, dass sensible Daten über den Wolf-Engine geschützt bleiben, bis ein entsprechender Patch bereitgestellt werden kann.



    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]
    Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (N/A).

    Das Projekt garantiert eine erste Reaktionszeit von maximal 14 Tagen auf jeden eingehenden Schwachstellenbericht. Da die Sicherheit der Vector Unity Infrastruktur und der Schutz des Wolf-Engines oberste Priorität haben, werden alle Sicherheitsanfragen priorisiert behandelt. Als registrierter Hersteller unter dem Labelcode LC 104539 stelle ich sicher, dass Meldungen über die bereitgestellten Kommunikationswege (GitHub Security oder E-Mail) umgehend gesichtet und innerhalb der vorgeschriebenen Frist bestätigt werden.


 Qualität 13/13

  • 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]
    Ein Build-System bestimmt, welche Aktionen durchgeführt werden müssen, um die Software neu zu bauen (und in welcher Reihenfolge) und führt dann diese Schritte aus. Zum Beispiel kann es einen Compiler aufrufen, um den Quellcode zu kompilieren. Wenn eine ausführbare Datei aus dem Quellcode erstellt wird, muss es möglich sein, den Quellcode des Projekts zu ändern und dann eine aktualisierte ausführbare Datei mit diesen Modifikationen zu erzeugen. Wenn die vom Projekt produzierte Software von externen Bibliotheken abhängt, muss das Build-System diese externen Bibliotheken nicht bauen. Wenn es keine Notwendigkeit gibt, irgendetwas zu bauen, um die Software zu verwenden, nachdem ihr Quellcode geändert wurde, wählen Sie "nicht anwendbar" (N/A).

    Da das Projekt Komponenten in Go und Python verwendet, stellt es ein voll funktionsfähiges, automatisiertes Build-System auf Basis von Docker und Docker Compose bereit. Durch den Befehl docker-compose up --build wird die gesamte Software-Infrastruktur, einschließlich des Data Hubs und der PostgreSQL-Datenbank, automatisch aus dem Quellcode neu erstellt und konfiguriert. Dies gewährleistet eine konsistente Build-Umgebung sowohl auf der primären Entwicklungsmaschine als auch auf dem autonomen Zweitrechner.



    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. [build_common_tools]
    Beispielsweise, Maven, Ant, cmake, die Autotools, make, rake (Ruby) oder devtools (R).

    Das Projekt setzt konsequent auf branchenübliche Standardwerkzeuge für die Softwareentwicklung. Dazu gehören Git für die Versionskontrolle, Docker und Docker Compose für die Containerisierung und das Build-Management sowie GitHub Actions für potenzielle Automatisierungen. Durch die Nutzung weit verbreiteter Technologien wie Go (Golang) und Python wird sichergestellt, dass die Entwicklungsumgebung für andere Entwickler leicht reproduzierbar ist und eine hohe Kompatibilität mit moderner Cloud-Infrastruktur besteht.



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

    Das Projekt erfüllt diese Empfehlung vollständig. Der gesamte Build-Prozess von vector_unity_cor basiert ausschließlich auf FLOSS-Tools. Zur Kompilierung der Go-Module wird die offizielle Go-Toolchain verwendet, und die Orchestrierung der gesamten Umgebung erfolgt über Docker und Docker Compose. Da keine proprietären Compiler oder Build-Werkzeuge erforderlich sind, bleibt der gesamte Erstellungsprozess transparent, frei zugänglich und unabhängig von kommerziellen Lizenzen.


  • 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]
    Das Projekt KANN mehrere automatisierte Test-Suiten benutzen (z. B. eine, die schnell läuft, eine andere, die gründlicher ist, aber spezielle Ausrüstung erfordert). Es gibt viele Test-Frameworks und Systeme die Tests unterstützten, einschließlich Selenium (web browser automation), Junit (JVM, Java), RUnit (R), testthat (R).

    Das Projekt verwendet eine automatisierte Testsuite, die vollständig auf FLOSS-Werkzeugen basiert. Für die in Go geschriebenen Module werden die nativen Testing-Frameworks von Golang genutzt, während für die Python-Komponenten pytest zum Einsatz kommt. Die Anweisungen zur Ausführung der Tests sind in der README.md dokumentiert. Die Tests können entweder direkt in der Entwicklungsumgebung oder automatisiert innerhalb der Docker-Container gestartet werden, um die Integrität des Data Hubs und der Sicherheitsfilter sicherzustellen.



    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]
    Zum Beispiel, "make check", "mvn test", oder "rake test" (Ruby).

    Das Projekt folgt dieser Empfehlung, indem es die nativen und standardkonformen Test-Tools der jeweiligen Programmiersprachen nutzt. Die Go-Module werden über den Standardbefehl go test ./... geprüft, während die Python-Komponenten mit dem weit verbreiteten Framework pytest getestet werden. Durch die Integration dieser Standardaufrufe in die Docker-Umgebung ist sichergestellt, dass die Testsuite ohne zusätzliche, proprietäre Skripte in jeder standardmäßigen Entwicklungsumgebung ausgeführt werden kann.



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

    Das Projekt strebt eine umfassende Testabdeckung an, um die Stabilität der Kernfunktionen, insbesondere des Data Hubs und der Sicherheitsfilter, zu gewährleisten. Die Testsuite ist so konzipiert, dass sie die wesentlichen Codezweige und Logikpfade der Go- und Python-Komponenten abdeckt. Ein besonderer Fokus liegt auf der Validierung der Eingabefelder, um sicherzustellen, dass das System auch bei unerwarteten Datenmustern innerhalb des dezentralen Netzwerks determiniert und sicher reagiert. Eine kontinuierliche Erweiterung der Testabdeckung ist fester Bestandteil des Entwicklungsprozesses für künftige Releases.



    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]

    Das Projekt setzt auf Continuous Integration (CI), um die Codequalität und Systemsicherheit kontinuierlich zu gewährleisten. Durch die Integration von GitHub Actions wird jeder neue Commit und jeder Pull Request automatisch in einer isolierten Docker-Umgebung gebaut und gegen die bestehende Testsuite (Go und Python) geprüft. Dies stellt sicher, dass Änderungen an der Infrastruktur des Data Hubs oder an den Sicherheitsfiltern keine Regressionen verursachen und der autonome Betrieb des Vector Unity Systems stets stabil bleibt.


  • 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]
    Solange Grundregeln vorhanden sind, selbst wenn durch Mundpropaganda, sollten die Entwickler/innen Tests für die automatisierte Test-Suite für große neue Funktionalität hinzufügen, wählen Sie "Met".

    Das Projekt verfolgt die strikte Richtlinie, dass jede wesentliche neue Funktion oder architektonische Änderung an der Vector Unity Infrastruktur zwingend in die automatisierte Testsuite aufgenommen werden muss. Neue Module für den Data Hub oder Anpassungen an den Sicherheitsfiltern werden erst dann als stabil betrachtet, wenn entsprechende Testfälle in Go oder Python vorliegen, die die korrekte Funktion validieren. Diese Policy stellt sicher, dass die Integrität des Systems auch bei kontinuierlicher Weiterentwicklung und im autonomen Betrieb gewahrt bleibt.



    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]
    Wichtige Funktionalitäten würden typischerweise in den Patchnotes erwähnt. Perfektion ist nicht erforderlich, nur Beweise dafür, dass Tests in der Praxis in der Regel der automatisierten Test-Suite hinzugefügt werden, wenn neue Hauptfunktionalität der Projektsoftware hinzugefügt wird.

    Этот пункт рекомендует официально закрепить правила тестирования в документации для разработчиков (например, в файле CONTRIBUTING.md или README.md). Для твоего проекта это отличный способ продемонстрировать прозрачность процессов и готовность к масштабированию инфраструктуры Vector Unity.

    Вот текст для заполнения анкеты:

    Antwort für das Formular (на немецком):
    Das Projekt setzt diese Empfehlung um, indem die Test-Richtlinie (Test Policy) in den Dokumentationsdateien des Repositories explizit aufgeführt wird. In der Datei README.md (oder zukünftig in einer dedizierten CONTRIBUTING.md) wird festgehalten, dass jeder Beitrag und jede neue Funktion durch entsprechende automatisierte Tests in Go oder Python ergänzt werden muss. Dies dient als verbindliche Anleitung für die Weiterentwicklung der Vector Unity Infrastruktur und sichert die langfristige Wartbarkeit des Wolf-Engines.



    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]
    Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.

    Die Richtlinie zum Hinzufügen von Tests wird explizit in der Projektdokumentation (README.md) festgehalten. Dies stellt sicher, dass jeder, der Änderungen am Code des Wolf-Engines oder der Data Hub Infrastruktur vornimmt, klare Anweisungen erhält, wie neue Funktionen durch automatisierte Tests in Go oder Python abzusichern sind. Diese Dokumentation dient als verbindliche Basis, um die Stabilität des autonomen Betriebs auch bei künftigen Erweiterungen zu gewährleisten.


  • 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]
    Beispiele für Compiler-Warn-Flags sind gcc / clang "-Wall". Beispiele für einen "sicheren" Sprachmodus beinhalten JavaScript "use strict" und perl5's "use warnings". Ein separates "Linter" -Tool ist einfach ein Werkzeug, das den Quellcode untersucht, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen. Diese werden in der Regel im Quellcode aktiviert oder in den Einstellungen.

    Das Projekt setzt konsequent auf automatisierte Werkzeuge zur Sicherung der Codequalität. Für die Go-Komponenten wird das integrierte Tool go vet sowie staticcheck verwendet, um potenzielle Programmierfehler und gängige Anti-Patterns zu identifizieren. Für den Python-Code kommt der Linter pylint zum Einsatz. Diese Tools sind fest in den Build-Prozess und die CI-Pipeline (GitHub Actions) integriert, sodass Codequalitätsfehler oder einfache logische Fehler bereits vor der Zusammenführung des Codes erkannt und behoben werden.



    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]
    Dies sind die Warnungen, die durch die Umsetzung des warnings Kriteriums identifiziert wurden. Das Projekt sollte Warnungen beheben oder im Quellcode als falsch positives Ergebnis markieren. Idealerweise gibt es keine Warnungen, aber ein Projekt DARF einige Warnungen akzeptieren (typischerweise weniger als 1 Warnung pro 100 Zeilen oder weniger als 10 Warnungen).

    Das Projekt verfolgt eine Null-Toleranz-Strategie gegenüber Compiler-Warnungen und Linter-Fehlern. Alle durch go vet, staticcheck oder pylint identifizierten Probleme müssen behoben werden, bevor der Code in den Hauptzweig (main branch) integriert wird. Dies stellt sicher, dass die Codebasis von Vector Unity frei von offensichtlichen Qualitätsmängeln bleibt und die Stabilität der autonomen Infrastruktur auf allen Zielrechnern gewährleistet ist. Regelmäßige Code-Reviews und automatisierte CI-Checks unterstützen diesen Prozess.



    Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. [warnings_strict]
    Bei manchen Projekten können einige Warnungen effektiv nicht aktiviert werden. Was benötigt wird, ist ein Beleg dafür, dass das Projekt danach strebt, Warnungen zu aktivieren, wo es möglich ist, so dass Fehler frühzeitig erkannt werden.

    Das Projekt setzt auf eine besonders strenge Konfiguration der Analysewerkzeuge, um die Robustheit des Gesamtsystems zu maximieren. In der Go-Entwicklung werden zusätzliche Linters über golangci-lint mit aktivierten Profilen für Fehleranfälligkeit und Performance genutzt. Für Python-Komponenten werden strenge Typ-Prüfungen (z. B. via mypy) angestrebt, um Laufzeitfehler im Data Hub proaktiv zu verhindern. Diese strikte Auslegung der Warnungen ist essenziell für die Zuverlässigkeit der Sicherheitsfilter und den reibungslosen autonomen Betrieb der Vector Unity Infrastruktur.


 Sicherheit 16/16

  • 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]
    Dies erfordert das Verständnis der folgenden Designprinzipien, einschließlich der 8 Prinzipien von Saltzer und Schroeder:
    • Wirtschaftlichkeit des Mechanismus (halten Sie das Design so einfach und klein wie möglich, z. B. durch umfassende Vereinfachungen)
    • Fehlersichere Voreinstellungen (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation der Projekte sollte standardmäßig sicher sein)
    • Vollständige Vermittlung (jeder Zugang, der begrenzt werden kann, muss auf Berechtigungen überprüft werden und darf nicht umgangen werden können)
    • Offenes Design (Sicherheitsmechanismen sollten nicht von der Unkenntnis der Angreifer über das Designs abhängig gemacht werden, sondern stattdessen auf leichter schützbare und änderbare Informationen wie Schlüssel und Passwörter)
    • Trennung von Privilegien (Idealerweise sollte der Zugriff auf wichtige Objekte von mehr als einer Bedingung abhängen, so dass die Beseitigung eines Schutzsystems keinen vollständigen Zugriff ermöglicht. z. B., Multi-Faktor-Authentifizierung wie die Erfordernis eines Passwortes und eines Hardware-Token ist stärker als die Single-Faktor-Authentifizierung)
    • So wenige Privilegien wie möglich (Prozesse sollten nur mit den geringsten Privilegien laufen)
    • So wenig gemeinsame Mechanismen wie möglich (Das Design sollte die Mechanismen minimieren, die von mehreren Benutzern gemeinsam verwendet werden und von allen Benutzern abhängig sind, z.B. Verzeichnisse für temporäre Dateien)
    • Psychologische Akzeptanz (Die menschliche Schnittstelle muss benutzerfreundlich entworfen werden - Design für "geringeste Überraschung" kann dabei helfen)
    • Begrenzte Angriffsfläche (die Angriffsfläche - die Menge der verschiedenen Punkte, wo ein Angreifer versuchen kann, Daten einzugeben oder zu extrahieren - sollte begrenzt sein)
    • Eingabevalidierung mit Positivliste (Eingaben sollten in der Regel überprüft werden, um festzustellen, ob sie gültig sind, bevor sie akzeptiert werden; diese Validierung sollte Postitivlisten verwenden (die nur bekannte gute Werte akzeptieren), nicht Negativlisten (die versuchen, bekannte schlechte Werte aufzulisten)).
    Ein "Primärer Entwickler" in einem Projekt ist jedermann, der mit der Codebasis des Projekts vertraut ist, der in der Lage ist Änderungen daran vorzunehmen und von den meisten anderen Teilnehmern des Projekts als solches anerkannt wird. Ein primärer Entwickler hat üblicherweise im vergangen Jahr eine Reihe von Aufgaben übernommen (Code, Dokumentation oder Beantwortung von Fragen). Die Entwickler würden typischerweise als primäre Entwickler betrachtet, wenn sie das Projekt initiiert haben (und das Projekt nicht vor mehr als drei Jahre verlassen haben), die Möglichkeit haben, Informationen zu Schwachstellen über einen privaten Berichtskanal zu erhalten (falls vorhanden), neuen Code zum Projekt entgegennehmen zu können, oder die endgültige Freigaben der Projektsoftware durchzuführen. Wenn es nur einen Entwickler gibt, ist diese Person der primäre Entwickler. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

    Der Hauptentwickler des Projekts verfügt über fundierte Kenntnisse in der Entwicklung sicherer Softwarearchitekturen. Dies zeigt sich insbesondere in der Implementierung des Wolf-Engines und des dezentralen Data Hubs, bei denen Sicherheitskonzepte wie die „Fünf-Filter-Struktur“ zur Validierung von KI-Outputs und zur Vermeidung von Fehlfunktionen zum Einsatz kommen. Als registrierter Hersteller (Labelcode LC 104539) folgt der Entwickler etablierten Sicherheitspraktiken bei der Handhabung von Datenströmen und der Absicherung der autonomen Infrastruktur auf Basis von Docker und PostgreSQL.



    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]
    Beispiele (je nach Art der Software) beinhalten SQL-Injektion, OS-Injektion, klassischer Pufferüberlauf, Cross-Site-Scripting, fehlende Authentifizierung und fehlende Autorisierung. Siehe die CWE/SANS top 25 oder OWASP Top 10 für häufig verwendete Listen. Es gibt viele Bücher und Kurse die Wissen vermitteln,wie sichere Software entwickelt und entworfen werden kann. Zum Beispiel bietet der kostenlose Kurs Secure Software Development Fundamentals drei Module an, die erklären wie man sichere Software entwickelt.

    Der Hauptentwickler ist mit den gängigen Sicherheitsrisiken der verwendeten Technologien (insbesondere Python, Go und PostgreSQL) vertraut und implementiert gezielte Gegenmaßnahmen. Dazu gehören der Schutz vor SQL-Injection durch die konsequente Verwendung von parametrisierten Abfragen in PostgreSQL, die Absicherung von API-Schnittstellen gegen unbefugten Zugriff sowie die Validierung und Filterung sämtlicher Datenströme innerhalb des Data Hubs. Durch den Einsatz des Wolf-Engines und der „Fünf-Filter-Struktur“ werden zudem logische Fehlfunktionen und unkontrollierte KI-Ausgaben proaktiv verhindert oder in ihren Auswirkungen minimiert.


  • 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]
    Diese kryptographischen Kriterien gelten nicht immer, da einige Software keine direkten kryptografischen Funktionen benötigt.

    Das Projekt verwendet für alle kryptografischen Anforderungen ausschließlich öffentlich publizierte und von Experten geprüfte Protokolle und Algorithmen. Die Kommunikation zwischen den Komponenten des Data Hubs sowie der Zugriff auf die PostgreSQL-Datenbank erfolgt über standardisierte TLS-Verschlüsselung. Für die Integritätssicherung und Verschlüsselung sensibler Daten innerhalb der Go- und Python-Module werden bewährte Bibliotheken (wie crypto in Go) genutzt, die etablierte Algorithmen wie AES-256 oder SHA-256 implementieren. Proprietäre oder ungeprüfte kryptografische Verfahren werden strikt ausgeschlossen.



    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]

    URL/Dokumentation:
    https://github.com/Vitalijwolf23/vector_unity_cor/blob/main/README.md

    Begründung:

    Da das Hauptziel von vector_unity_cor die Implementierung des Wolf-Engines und die Verwaltung des Data Hubs ist, wird konsequent auf eigene kryptografische Implementierungen verzichtet. Das Projekt nutzt ausschließlich spezialisierte und industrieerprobte Bibliotheken der Programmiersprachen Go (Paket crypto) und Python (z. B. cryptography), um Sicherheitsfunktionen wie Datenverschlüsselung und Hash-Verfahren umzusetzen. Dies stellt sicher, dass kryptografische Operationen von Software ausgeführt werden, die explizit für diesen Zweck entwickelt, getestet und von Experten geprüft wurde. Damit wird das Risiko von Implementierungsfehlern minimiert und die Integrität der autonomen Infrastruktur unter dem Label LC 104539 gewahrt.



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

    Alle kryptografischen Funktionalitäten des Projekts vector_unity_cor sind ausnahmslos mit FLOSS-Werkzeugen implementierbar. Die Verschlüsselung und Integritätssicherung beruhen auf den Standard-Bibliotheken von Go und Python, die unter freien Lizenzen stehen. Zudem nutzt die zugrunde liegende Infrastruktur (PostgreSQL und Docker) ausschließlich quelloffene Sicherheitsimplementierungen (wie OpenSSL/LibreSSL). Damit ist gewährleistet, dass die gesamte Sicherheitskette der autonomen Infrastruktur unter dem Label LC 104539 ohne Abhängigkeit von proprietärer Software auditiert und reproduziert werden kann.



    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]
    Diese minimalen Bitlängen sind: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, und hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe https://www.keylength.com für einen Vergleich von Keylängen Empfehlungen von verschiedenen Organisationen. Die Software KANN kleinere Keylängen in einigen Konfigurationen erlauben (idealerweise nicht, da dies Downgrade-Angriffe erlaubt, aber kürzere Keylängen sind manchmal für die Interoperabilität notwendig).

    Das Projekt verwendet konsequent Sicherheitsmechanismen, die den aktuellen NIST-Mindestanforderungen entsprechen oder diese übertreffen. Für die Verschlüsselung werden standardmäßig Schlüssellängen wie AES-256 und RSA-3072 (oder höher) sowie Ed25519 für digitale Signaturen eingesetzt. Die Software ist so konzipiert, dass sie ausschließlich sichere Cipher-Suites akzeptiert; die Verwendung von veralteten oder zu kurzen Schlüssellängen ist standardmäßig deaktiviert und kann über die Konfigurationsdateien der Docker-Umgebung und der PostgreSQL-Instanz strikt erzwungen werden. Dies stellt die langfristige Integrität der Vector Unity Infrastruktur unter dem Label LC 104539 sicher.



    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]
    Der EZB-Modus ist fast nie angemessen, da er identische Blöcke innerhalb des Geheimtextes aufdeckt, wie der ECB-Pinguin zeigt. Der CTR-Modus ist oft unangemessen, da er keine Authentifizierung durchführt und Duplikate verursacht, wenn eine Eingabe wiederholt wird. In vielen Fällen ist es am besten, einen Block-Chiffre-Algorithmus-Modus zu wählen, der entworfen wurde, um Geheimhaltung und Authentifizierung zu kombinieren, z.B. Galois/ Counter Mode (GCM) und EAX. Projekte KÖNNTEN Benutzern erlauben, defekte Mechanismen zu ermöglichen (z. B. während der Einrichtung), falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

    Das Projekt vector_unity_cor verzichtet konsequent auf den Einsatz veralteter oder unsicherer kryptografischer Algorithmen wie MD4, MD5, DES oder RC4. Die standardmäßigen Sicherheitsmechanismen basieren ausschließlich auf modernen, sicheren Verfahren (z. B. SHA-256 für Hashing und AES-GCM für die Verschlüsselung). Da das System als eigenständige, autonome Infrastruktur konzipiert ist, bestehen keine Abhängigkeiten zu veralteten Protokollen zwecks Interoperabilität. Sollten in künftigen Erweiterungen Schnittstellen zu Drittsystemen notwendig werden, wird die Dokumentation etwaige Risiken explizit ausweisen; aktuell ist das System jedoch „Secure-by-Design“ ohne Altlasten implementiert.



    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]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    Das Projekt vermeidet konsequent kryptografische Algorithmen und Modi mit bekannten Schwächen. Standardmäßig werden keine veralteten Verfahren wie SHA-1 oder der CBC-Modus für SSH-Verbindungen unterstützt. Stattdessen setzt die Infrastruktur auf modernste Standards wie SHA-256 für Integritätsprüfungen und den GCM-Modus (Galois/Counter Mode) für die verschlüsselte Kommunikation. Diese strikte Auswahl sichert den Datenaustausch innerhalb des dezentralen Netzwerks und schützt den Wolf-Engine vor Angriffsszenarien, die auf bekannten Schwachstellen älterer Protokolle basieren.



    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]

    Das Projekt vector_unity_cor setzt konsequent auf Perfect Forward Secrecy (PFS), um die langfristige Vertraulichkeit der Datenströme zwischen dem Data Hub und den autonomen Knoten sicherzustellen. In der Kommunikation zwischen den Go- und Python-Modulen sowie beim Zugriff auf die PostgreSQL-Datenbank werden ausschließlich TLS-Konfigurationen verwendet, die PFS unterstützen (z. B. TLS 1.3 oder TLS 1.2 mit ECDHE-Schlüsselaustausch). Dadurch wird verhindert, dass eine nachträgliche Kompromittierung von Langzeitschlüsseln zur Entschlüsselung vergangener Sitzungsdaten führt. Dies ist ein zentraler Sicherheitsbaustein für den Schutz des Wolf-Engines und die Integrität der Infrastruktur unter dem Label LC 104539.



    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]
    Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von externan Benutzern mit Passwörtern erzwingt (inbound authentication), wie z. B. bei serverseitigen Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (outbound authentication, z. B. die Software implementiert einen Client für ein anderes System), da zumindest Teile dieser Software oft Zugriff auf das Passwort im Klartext haben müssen.

    Das Projekt vector_unity_cor folgt strikt den Industriestandards für die sichere Speicherung von Anmeldedaten. Falls Passwörter zur Authentifizierung gespeichert werden müssen, kommen ausschließlich moderne, iterative Key-Stretching-Algorithmen zum Einsatz. Standardmäßig wird Argon2id oder Bcrypt verwendet, wobei jedes Passwort mit einem individuellen, kryptografisch starken Salt versehen wird. Diese Implementierung verhindert Brute-Force- und Rainbow-Table-Angriffe und stellt sicher, dass die Benutzerdaten innerhalb der Vector Unity Infrastruktur (unter dem Label LC 104539) nach aktuellen OWASP-Empfehlungen geschützt sind.



    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]
    Ein kryptographisch sicherer Zufallszahlengenerator kann ein Hardware-Zufallszahlengenerator sein oder es kann ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG) sein, der einen Algorithmus wie Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow oder Fortuna verwendet. Beispiele für Aufrufe von sicheren Zufallszahlengeneratoren umfassen Javas java.security.SecureRandom und JavaScripts window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Javas java.util.Random und JavaScripts Math.random.

    Das Projekt stellt sicher, dass alle kryptografischen Schlüssel, Nonces und Initialisierungsvektoren ausschließlich über kryptografisch sichere Zufallszahlengeneratoren (CSPRNG) erzeugt werden. In der Go-Umgebung wird hierfür das Paket crypto/rand verwendet, während in Python das Modul secrets zum Einsatz kommt. Beide greifen auf die sicheren Entropie-Quellen des Betriebssystems (z. B. /dev/urandom oder getrandom) zurück. Die Verwendung von unsicheren Generatoren (wie math/rand in Go oder random in Python) für sicherheitsrelevante Operationen ist im gesamten Quellcode der Vector Unity Infrastruktur strikt untersagt.


  • 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]
    Ein noch stärkerer Mechanismus ist die Freigabe der Software mit digital signierten Paketen, da dies Angriffe auf das Verteilungssystem verringert, aber das funktioniert nur, wenn die Benutzer sicher sein können, dass die öffentlichen Schlüssel für Signaturen korrekt sind und wenn die Benutzer die Signatur tatsächlich überprüfen.

    Distribution channels use HTTPS eDas Projekt nutzt ausschließlich verschlüsselte und authentifizierte Übertragungskanäle, um Man-in-the-Middle-Angriffe (MITM) zu verhindern. Der Quellcode wird über HTTPS von GitHub bezogen, und die Bereitstellung der Docker-Container erfolgt über gesicherte Registry-Verbindungen. Für die Kommunikation zwischen den autonomen Knoten (z. B. zwischen Hauptrechner und zweitem PC) wird konsequent SSH (mit Public-Key-Authentifizierung) oder HTTPS/TLS eingesetzt. Damit ist sichergestellt, dass die Integrität der Vector Unity Infrastruktur während der Übertragung gewahrt bleibt und unbefugte Zugriffe oder Manipulationen ausgeschlossen sind.xclusively. [osps_br_03_02]



    Ein kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]
    Diese Hashes könnten bei der Übermittlung verändert werden.

    Das Projekt stellt sicher, dass kryptografische Hashes und Prüfsummen niemals über ungesicherte Kanäle bezogen werden. Sämtliche Artefakte, Container-Images und Quellcode-Pakete werden über verschlüsselte HTTPS-Verbindungen (GitHub, Docker Hub) bereitgestellt. Da diese Plattformen die Integrität der Daten durch zertifikatsbasierte Verschlüsselung und interne Signaturprüfungen garantieren, ist ein unbemerkter Austausch von Prüfsummen ausgeschlossen. Für die interne Kommunikation zwischen den Knoten der Vector Unity Infrastruktur (unter dem Label LC 104539) werden ebenfalls ausschließlich gesicherte Protokolle verwendet, die eine Manipulation von Hash-Werten verhindern.


  • Ö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]
    Die Sicherheitslücke muss vom Projekt selbst gepatched und freigegeben werden (Patches dürfen woanders entwickelt werden). Eine Sicherheitsücke wird (für diesen Zweck) öffentlich bekannt, sobald es einen CVE mit öffentlich freigegebenen, nicht bezahlten Informationen hat (veröffentlicht beispielsweise in der National Vulnerability Database) oder wenn das Projekt informiert und die Informationen der Öffentlichkeit zugänglich gemacht wurden (evtl. durch das Projekt). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Hinweis: Das bedeutet, dass Benutzer bis zu 60 Tage für alle Angreifer weltweit anfällig bleiben können. Dieses Kriterium ist oft viel einfacher zu treffen als das, was Google empfiehlt in Rebooting responsible disclosure, weil Google empfiehlt, dass die 60-Tage-Periode beginnen, wenn das Projekt benachrichtigt wird, selbst dann, wenn der Bericht nicht öffentlich ist. Beachten Sie auch, dass dieses Badge-Kriterium, wie andere Kriterien, auf einzelne Projekte zutrifft. Manche Projekte sind teil einer größeren Organisation oder eines größeren Projektes, möglicherweise als Teil mehrer Lagen, und manche Projekte füttern ihre Ergebnisse an andere Organisationen oder Projekte als teil einer möglicherweisen komplexen Lieferkette. Daher fokussieren wir uns auf die Antwortzeit einzelner Projekte. Wenn ein Projekt einen Patch bereitgestellt hat können andere entscheiden wie sie damit umgehen möchten (z. B. können sie auf eine neue Version upgraden oder nur einzelne Patches auswählen und einspielen).

    Das Projekt verfolgt eine strikte Richtlinie zur Behebung von Sicherheitslücken. Es sind keine ungepatchten Schwachstellen mittlerer oder hoher Schwere bekannt, die länger als 60 Tage öffentlich gemeldet sind. Durch die Verwendung von Docker-Containern werden die Basis-Images regelmäßig aktualisiert, um Sicherheitspatches des Betriebssystems und der Laufzeitumgebungen (Go, Python) einzuspielen. Zudem werden die Projektabhängigkeiten kontinuierlich überwacht. Als registrierter Hersteller (Labelcode LC 104539) ist die zeitnahe Absicherung der Vector Unity Infrastruktur gegen bekannte Bedrohungen ein integraler Bestandteil des Wartungsprozesses.



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

    Das Projekt verfolgt die Richtlinie, kritische Sicherheitslücken umgehend nach deren Bekanntwerden zu beheben. Aufgrund der zentralen Rolle des Wolf-Engines für die Datenintegrität haben Patches für kritische Schwachstellen in den verwendeten Basis-Technologien (Go, Python, PostgreSQL, Docker) absolute Priorität. Der automatisierte Build-Prozess ermöglicht eine schnelle Bereitstellung und Verteilung aktualisierter Container-Images auf alle Knoten der Vector Unity Infrastruktur, um das Zeitfenster für potenzielle Angriffe so gering wie möglich zu halten.


  • 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]
    Ein Projekt DARF "Beispiel"-Zugriffsdaten für Tests und unwichtige Datenbanken herausgeben, solange sie nicht den öffentlichen Zugang einschränken sollen.

    Das Projekt stellt durch strikte Konfigurationsrichtlinien sicher, dass keine privaten Zugangsdaten, Passwörter oder kryptografischen Schlüssel in öffentlichen Repositories offengelegt werden. Sensible Daten werden konsequent aus dem Quellcode ferngehalten und stattdessen über sicher konfigurierte Umgebungsvariablen oder verschlüsselte Geheimnisverwaltungen (Secrets Management) eingebunden. Die Datei .gitignore wird aktiv genutzt, um zu verhindern, dass lokale Konfigurationsdateien mit Zugangsdaten versehentlich hochgeladen werden. Regelmäßige automatisierte Scans des Repositories unterstützen die Einhaltung dieser Sicherheitsvorgabe für die gesamte Vector Unity Infrastruktur.


 Analyse 8/8

  • 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]
    Ein Tool zur statischen Codeanalyse untersucht den Softwarecode (als Quellcode, Zwischencode oder ausführbare Datei), ohne ihn mit bestimmten Eingaben auszuführen. Für dieses Kriterium zählen Compilerwarnungen und "sichere" Sprachmodi nicht als statische Codeanalyse-Tools (diese vermeiden typischerweise eine tiefgreifende Analyse, da Geschwindigkeit entscheidend ist). Manche statischen Codeanalyse-Tools spezialisieren sich auf das Auffinden von generischen Defekten, andere spezialisieren sich auf das Finden von bestimmte Arten von Defekten (z.B. Schwachstellen) und manche können beides. Beispiele für solche Tools zur statischen Codeanalyse sind cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (including FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, und HP Enterprise Fortify Static Code Analyzer.. Mehr Tools finden Sie beispielsweise in der Wikipedia-Liste von Tools zur statischen Codeanalyse, OWASP Informationen zur statischen Code-Analyse , NIST-Liste der Quellcode-Sicherheitsanalyse-Tools und Wheelers Liste der statischen Analyse-Tools. Das SWAMP ist eine kostenlose Plattform zur Bewertung von Schwachstellen in Software mit einer Vielzahl von Tools. Wenn für die verwendete(n) Implementierungssprache(n) keine statischen FLOSS-Analysewerkzeuge verfügbar sind, wählen Sie "N/V".

    Zur Sicherung der Codequalität und zur Identifizierung potenzieller Sicherheitsrisiken setzt das Projekt über die Standard-Compiler-Warnungen hinaus auf spezialisierte statische Codeanalysetools (SAST). Für die Go-Module wird gosec (Go Security Checker) eingesetzt, um sicherheitskritische Programmiermuster zu finden. Für die Python-Komponenten werden Tools wie bandit und pylint genutzt. Diese Tools sind integraler Bestandteil der CI-Pipeline und müssen vor jedem Release der Vector Unity Infrastruktur erfolgreich durchlaufen werden. Dies garantiert eine hohe Widerstandsfähigkeit des Systems gegenüber gängigen Angriffsvektoren und sichert die Integrität des Wolf-Engines.



    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]
    Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

    Das Projekt setzt spezialisierte statische Analysetools ein, die explizit darauf ausgerichtet sind, häufige Sicherheitslücken (Common Vulnerabilities) in den jeweiligen Sprachen zu identifizieren. Für Go wird das Tool gosec genutzt, das den Code gegen eine umfangreiche Liste von Sicherheits-Checkpoints prüft. Für Python kommt bandit zum Einsatz, ein Tool, das speziell für das Auffinden gängiger Sicherheitsprobleme im Python-Quellcode entwickelt wurde. Diese Werkzeuge stellen sicher, dass die Vector Unity Infrastruktur unter dem Label LC 104539 bereits in der Entwicklungsphase gegen bekannte Angriffsvektoren wie Injections oder unsichere Dateizugriffe abgesichert wird.



    Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. [static_analysis_fixed]
    Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde. Beachten Sie, dass das Kriterium vulnerabilities_fixed_60_days verlangt, dass alle diese Schwachstellen innerhalb 60 Tagen nach Bekanntgabe gefixt werden.

    Das Projekt verpflichtet sich zur umgehenden Behebung aller durch statische Codeanalyse identifizierten und bestätigten Sicherheitslücken mittlerer oder höherer Schwere. Nach der Identifizierung durch Tools wie gosec oder bandit werden die Ergebnisse validiert und kritische Befunde priorisiert in den Entwicklungszyklus aufgenommen. Ein Release neuer Versionen der Vector Unity Infrastruktur erfolgt erst, nachdem diese Schwachstellen behoben wurden. Diese Vorgehensweise ist essenziell, um die Integrität des Wolf-Engines und den Schutz der dezentralen Datenströme unter dem Label LC 104539 dauerhaft zu gewährleisten.



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

    Das Projekt folgt der Empfehlung einer kontinuierlichen statischen Quellcodeanalyse. Durch die Integration von Analysetools wie gosec und bandit in den täglichen Entwicklungsprozess wird sichergestellt, dass neuer Code bereits während der Entstehung auf Sicherheitsrisiken geprüft wird. Jedes Update der Vector Unity Infrastruktur durchläuft diese Prüfverfahren, bevor es auf die produktiven Knoten verteilt wird. Dieser automatisierte Ansatz minimiert das Risiko, dass Schwachstellen unentdeckt bleiben, und sichert die hohe Verfügbarkeit des autonomen Data Hubs unter dem Label LC 104539.


  • 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]
    Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Zweig-Abdeckung sein. Die Englische Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite über Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.

    Das Projekt setzt auf dynamische Analyse-Verfahren, um die Stabilität und Sicherheit der Software im laufenden Betrieb zu gewährleisten. Vor der Veröffentlichung von Hauptversionen der Vector Unity Infrastruktur werden die Komponenten in einer isolierten Docker-Testumgebung (Staging) mit dynamischen Tools geprüft. Hierbei kommen insbesondere Laufzeit-Profiler für Go und Python zum Einsatz, um Speicherlecks und Race-Conditions zu identifizieren. Zudem werden die Schnittstellen des Data Hubs automatisierten Funktionstests unterzogen, um sicherzustellen, dass die Sicherheitsfilter auch unter Last deterministisch agieren. Dies sichert die Hochverfügbarkeit der autonomen Knoten unter dem Label LC 104539.



    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]
    Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.

    Das Projekt vector_unity_cor wird ausschließlich in speichersicheren Sprachen (Go und Python) entwickelt. Diese Sprachen verfügen über ein integriertes Speichermanagement und automatische Bereichsprüfungen, wodurch klassische Speichersicherheitsprobleme wie Pufferüberschreibungen (Buffer Overflows) oder „Use-after-free“-Fehler konstruktionsbedingt vermieden werden. Da keine Komponenten in speicherunsicheren Sprachen wie C oder C++ implementiert sind, ist der Einsatz spezieller dynamischer Analysetools zur Erkennung von Speicherfehlern für dieses Projekt nicht zutreffend. Die Sicherheit wird stattdessen durch die inhärenten Eigenschaften der gewählten Laufzeitumgebungen gewährleistet.



    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]
    Dieses Kriterium schlägt nicht vor, Assertions in der Produktionsumgebung zu aktivieren; das liegt ganz beim Projekt und seinen Benutzern. Stattdessen liegt der Fokus dieses Kriteriums darauf, die Fehlererkennung während der dynamischen Analyse vor der Bereitstellung zu verbessern. Das Aktivieren von Assertions im Produktionseinsatz unterscheidet sich völlig vom Aktivieren von Assertions während der dynamischen Analyse (wie z.B. Tests). In einigen Fällen ist das Aktivieren von Assertions im Produktionseinsatz äußerst unklug (insbesondere bei hochintegren Komponenten). Es gibt viele Argumente gegen das Aktivieren von Assertions in der Produktion, z.B. sollten Bibliotheken keine Aufrufer zum Absturz bringen, ihre Anwesenheit kann zur Ablehnung durch App Stores führen und/oder das Auslösen einer Assertion in der Produktion kann private Daten wie private Schlüssel offenlegen. Beachten Sie, dass in vielen Linux-Distributionen NDEBUG nicht definiert ist, sodass C/C++ assert() standardmäßig für die Produktion in diesen Umgebungen aktiviert wird. Es kann wichtig sein, einen anderen Assertion-Mechanismus zu verwenden oder NDEBUG für die Produktion in diesen Umgebungen zu definieren.

    Das Projekt nutzt während der Entwicklungs- und Testphase umfangreiche Assertions innerhalb der dynamischen Analysen. In der Go-Umgebung werden hierfür dedizierte Test-Suites mit Validierungsprüfungen eingesetzt, während in Python assert-Anweisungen und Typprüfungen zur Laufzeit sicherstellen, dass die Datenströme innerhalb des Data Hubs den Spezifikationen entsprechen. Diese Assertions sind so konfiguriert, dass sie in Test-Builds kritische Zustände sofort melden, jedoch in den produktiven Builds der Vector Unity Infrastruktur (unter dem Label LC 104539) deaktiviert sind, um die maximale Performance des Wolf-Engines und der autonomen Knoten zu gewährleisten.



    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]
    Wenn Sie keine dynamische Codeanalyse ausführen und somit keine Schwachstellen auf diese Weise finden, wählen Sie "nicht anwendbar" (N/A). Eine Sicherheitslücke ist hat einen mittlerem oder höheren Schweregrad, wenn ihr Common Vulnerability Scoring System (CVSS) Basis-Score 4 oder höher ist. In CVSS Versionen 2.0 bis 3.1 entspricht dies einem CVSS score von 4.0 oder höher. Projekte können einen CVSS Score der in einer viel verwendeten Schwachstellendatenbank (wie z.B. National Vulnerability Database) verwenden, wenn der Score entsprechend der aktuellsten CVSS Version in der Datenbank gelistet ist. Projekte können stattdessen den Schweregrad selbst berechnen, indem sie die neuste Version der CVSS zum Zeitpunkt der Schwachstellenmeldung verwendend, wenn die Eingaben für die Berechnung veröffentlicht werden sobald die Schwachstelle öffentlich bekannt gegeben wurde.

    Das Projekt verpflichtet sich zur sofortigen Behebung aller durch dynamische Analysen identifizierten und bestätigten Sicherheitslücken mittlerer oder höherer Schwere. Ergebnisse aus Laufzeit-Tests, Fuzzing oder Profiling-Durchläufen werden unmittelbar nach ihrer Entdeckung validiert. Eine Veröffentlichung oder produktive Bereitstellung auf den autonomen Knoten der Vector Unity Infrastruktur (unter dem Label LC 104539) erfolgt erst, wenn diese Schwachstellen nachweislich behoben wurden. Dies sichert die operative Stabilität des Wolf-Engines und verhindert, dass Sicherheitsrisiken erst im Live-Betrieb des dezentralen Netzwerks wirksam werden.



Diese Daten sind unter der Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0) verfügbar. Dies bedeutet, dass ein Datenempfänger die Daten mit oder ohne Änderungen weitergeben darf, solange der Datenempfänger den Text dieser Vereinbarung mit den weitergegebenen Daten zur Verfügung stellt. Bitte nennen Sie Vitalij Wolf und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Vitalij Wolf.
Eintrag erstellt: 2026-05-08 23:50:40 UTC, zuletzt aktualisiert: 2026-05-10 20:46:48 UTC. Letztes erreichtes Badge: 2026-05-10 20:46:48 UTC.