model-switchboard

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 12820 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/12820/badge)](https://www.bestpractices.dev/projects/12820)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/12820"><img src="https://www.bestpractices.dev/projects/12820/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.

    A session-aware control layer that routes coding turns to an appropriate model profile before execution.

    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.

  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

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

    The project uses its GitHub repository as the project website. It provides how to obtain the software (repo and npm package), how to provide feedback (GitHub Issues for bug reports and enhancements), and how to contribute (CONTRIBUTING.md with PR process and contribution requirements).


    Genug für ein Badge!

    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]

    Obtain the software:
    https://github.com/hannasdev/model-switchboard
    https://www.npmjs.com/package/model-switchboard
    Provide feedback (bugs/enhancements):
    https://github.com/hannasdev/model-switchboard/issues
    Contribute:
    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    Genug für ein Badge!

    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://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    Genug für ein Badge!

    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]

    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


  • FLOSS-Lizenz


    Genug für ein Badge!

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


    Genug für ein Badge!

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


    Genug für ein Badge!

    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/hannasdev/model-switchboard/blob/main/LICENSE.


  • Dokumentation


    Genug für ein Badge!

    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.

    Some documentation basics file contents found.


    Genug für ein Badge!

    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.

    https://github.com/hannasdev/model-switchboard/blob/main/docs/CLI-REFERENCE.md


  • Andere


    Genug für ein Badge!

    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.


    Genug für ein Badge!

    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.
    https://github.com/hannasdev/model-switchboard/blob/main/docs/CLI-REFERENCE.md


    Genug für ein Badge!

    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.

    All documentation is available in English.
    Examples: https://github.com/hannasdev/model-switchboard/blob/main/LICENSE, https://github.com/hannasdev/model-switchboard/blob/main/docs/CLI-REFERENCE.md, https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    Genug für ein Badge!

    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.

    How this is satisfied:

    Regular recent releases are published, which indicates active upkeep and user-facing updates.
    https://github.com/hannasdev/model-switchboard/releases
    https://github.com/hannasdev/model-switchboard/blob/main/CHANGELOG.md
    Recent commit activity is visible on the default branch, showing the codebase is actively updated.
    https://github.com/hannasdev/model-switchboard/commits/main
    CI is configured and running on pushes/PRs, which is a strong maintenance signal (changes are continuously validated).
    https://github.com/hannasdev/model-switchboard/actions/workflows/ci.yml
    https://github.com/hannasdev/model-switchboard/actions
    Security handling is documented and current, with a defined vulnerability-report process.
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


 Verbesserungs-/Nacharbeits-Kontrolle 9/9 ●

  • Öffentliches Versionskontroll-Source-Repository


    Genug für ein Badge!

    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.


    Genug für ein Badge!

    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.


    Genug für ein Badge!

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

    Why this criterion is satisfied:

    The repository uses pull requests with branch-based development, so changes are reviewed in interim form before release tags are created.
    The commit history on main shows many non-release commits and merged PR commits between release commits.
    Releases are generated from already-reviewed source history, not as isolated final-only drops.

    PR list (interim review artifacts): https://github.com/hannasdev/model-switchboard/pulls?q=is%3Apr+is%3Aclosed
    Main commit history (interim commits between releases): https://github.com/hannasdev/model-switchboard/commits/main
    Tags/releases (final outputs derived from reviewed history): https://github.com/hannasdev/model-switchboard/releases


    Genug für ein Badge!

    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.

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


  • Einzigartige Versionsnummerierung


    Genug für ein Badge!

    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.

    The project uses SemVer in package metadata, with a single version value per release.
    Each release is tagged with a unique Git tag in vX.Y.Z format.
    GitHub Releases are created per tag, so each user-facing release has a unique identifier.
    Evidence URLs:

    Version in package metadata: https://github.com/hannasdev/model-switchboard/blob/main/package.json
    Unique release tags: https://github.com/hannasdev/model-switchboard/tags
    User-facing releases: https://github.com/hannasdev/model-switchboard/releases


    Genug für ein Badge!

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

    Genug für ein Badge!

    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]

    We use Semantic Versioning style identifiers (major.minor.patch) in releases.
    Our Git tags follow vX.Y.Z.
    The package version tracks the same SemVer format.
    Evidence URLs:
    https://github.com/hannasdev/model-switchboard/tags
    https://github.com/hannasdev/model-switchboard/releases
    https://github.com/hannasdev/model-switchboard/blob/main/package.json


  • Versionshinweise


    Genug für ein Badge!

    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.

    Non-trivial release notes file in repository: https://github.com/hannasdev/model-switchboard/blob/main/CHANGELOG.md.


    Genug für ein Badge!

    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.

    N/A. While the project provides release notes, no releases to date have fixed a publicly known run-time vulnerability in the project itself that had a CVE (or similar identifier) assigned at the time of release. If such a case occurs, we will explicitly list the CVE(s) in the corresponding release notes.

    https://github.com/hannasdev/model-switchboard/releases


 Berichterstattung 8/8 ●

  • Bug-Report-Prozess


    Genug für ein Badge!

    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]

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md. [osps_do_02_01]


    Genug für ein Badge!

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

    The project uses GitHub Issues as its issue tracker for individual bug reports and enhancement requests.
    https://github.com/hannasdev/model-switchboard/issues


    Genug für ein Badge!

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

    In the applicable 2–12 month window, there were no submitted bug reports in this repository, so there were no unacknowledged bug reports. The project’s issue tracker is public and monitored at the URL provided.
    https://github.com/hannasdev/model-switchboard/issues


    Genug für ein Badge!

    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.

    In the applicable 2–12 month window, there were no enhancement requests submitted in the issue tracker, so there were no unanswered enhancement requests. The project issue tracker is public and monitored at the URL provided.
    https://github.com/hannasdev/model-switchboard/issues


    Genug für ein Badge!

    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 project uses GitHub Issues as a publicly available, searchable archive of reports and responses, with permanent URLs for each thread.
    https://github.com/hannasdev/model-switchboard/issues


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    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.

    The project publishes its vulnerability reporting process in SECURITY.md on the project site, including private reporting instructions via GitHub Security Advisories and the disclosure process.
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


    Genug für ein Badge!

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

    The project supports private vulnerability reporting and documents how to do so in SECURITY.md, including a direct link to create a private GitHub Security Advisory draft.
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


    Genug für ein Badge!

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

    N/A. In the last 6 months, the project has not had publicly recorded vulnerability reports requiring an initial response-time measurement. If reports are received, our policy target is initial acknowledgment within 14 days.
    Evidence URL:
    https://github.com/hannasdev/model-switchboard/security/advisories
    https://github.com/hannasdev/model-switchboard/blob/main/SECURITY.md


 Qualität 13/13 ●

  • Produktivsystem


    Genug für ein Badge!

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

    N/A. The project does not require a separate build step to use; it is distributed as runnable Node.js source. Users can run it directly after installing dependencies.
    https://github.com/hannasdev/model-switchboard/blob/main/package.json
    https://github.com/hannasdev/model-switchboard/blob/main/README.md


    Genug für ein Badge!

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

    N/A. The project does not require a separate build step for use, so build-tool selection is not applicable.


    Genug für ein Badge!

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

    N/A. The project does not require a separate build step for use; it is distributed as runnable source.


  • Automatisierte Test-Suite


    Genug für ein Badge!

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

    The project uses an automated FLOSS test suite in the public repository and documents how to run it (npm test). Tests are also executed automatically in public CI on pushes and pull requests.
    Test command definition: https://github.com/hannasdev/model-switchboard/blob/main/package.json
    Public test suite files: https://github.com/hannasdev/model-switchboard/tree/main/test
    CI workflow running tests: https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml
    User-facing test invocation in docs: https://github.com/hannasdev/model-switchboard/blob/main/README.md


    Genug für ein Badge!

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

    The test suite is invocable in the standard Node.js ecosystem way using npm test, as documented in package.json and project documentation.
    https://github.com/hannasdev/model-switchboard/blob/main/package.json
    https://github.com/hannasdev/model-switchboard/blob/main/README.md


    Genug für ein Badge!

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

    The project maintains broad functional automated tests across core modules (routing, adapters, workflow, CLI, session continuity, and fuzzing), which provides substantial coverage of behavior and inputs. We continuously expand tests as new functionality is added.
    https://github.com/hannasdev/model-switchboard/tree/main/test
    https://github.com/hannasdev/model-switchboard/blob/main/package.json
    https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml


    Genug für ein Badge!

    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]

    The project implements continuous integration using GitHub Actions. On pull requests and pushes to main, CI runs automated checks including the test suite, ensuring new and changed code is continuously validated.
    https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml
    https://github.com/hannasdev/model-switchboard/actions


  • Neue Funktionalitätsüberprüfung


    Genug für ein Badge!

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

    The project has a documented policy that major new functionality must include corresponding automated tests (and bug fixes should include tests as well). This policy is defined in CONTRIBUTING and enforced through CI test execution.
    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md


    Genug für ein Badge!

    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.

    Recent major feature PRs include test additions in the same change set. For example, PR #24 (multi-surface advisory routing) and PR #19 (explainability and attribution) both added new source files alongside corresponding tests, demonstrating adherence to the test policy.
    https://github.com/hannasdev/model-switchboard/pull/24/files
    https://github.com/hannasdev/model-switchboard/pull/19/files


    Genug für ein Badge!

    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.

    The test policy is documented in CONTRIBUTING.md under 'Test Policy', which is the instructions contributors follow when proposing changes via pull requests.
    https://github.com/hannasdev/model-switchboard/blob/main/CONTRIBUTING.md#test-policy


  • Warnhinweise


    Genug für ein Badge!

    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.

    The project uses ESLint (a FLOSS linter) with eslint-plugin-security to check for code quality errors and common security vulnerabilities. Linting runs automatically in CI on every push and pull request via npm run lint.
    https://github.com/hannasdev/model-switchboard/blob/main/eslint.config.js
    https://github.com/hannasdev/model-switchboard/blob/main/.github/workflows/ci.yml
    https://github.com/hannasdev/model-switchboard/blob/main/package.json


    Genug für ein Badge!

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

    All ESLint warnings have been addressed. Dynamic filesystem path warnings (detect-non-literal-fs-filename) are suppressed with a scoped config override and documented justification (paths are centrally managed and validated at the application boundary). The one no-process-exit occurrence is suppressed inline with justification at the top-level CLI entry point.
    https://github.com/hannasdev/model-switchboard/blob/main/eslint.config.js
    https://github.com/hannasdev/model-switchboard/actions (lint step shows clean)


    Genug für ein Badge!

    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.

    The project is maximally strict with ESLint warnings where practical. Security rules are enabled at error level, all real warnings have been addressed, and the two false-positive rule suppressions are scoped narrowly with documented justification. The lint run currently produces zero warnings.
    https://github.com/hannasdev/model-switchboard/blob/main/eslint.config.js
    https://github.com/hannasdev/model-switchboard/actions


 Sicherheit 16/16 ●

 Analyse 8/8 ●


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 Hanna und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Hanna.
Eintrag erstellt: 2026-05-12 16:00:02 UTC, zuletzt aktualisiert: 2026-05-12 19:34:38 UTC. Letztes erreichtes Badge: 2026-05-12 18:40:46 UTC.