FLOSS Best Practices Kriterien (Gold Level)

Dies sind Best Practices für Free/Libre und Open Source Software (FLOSS) Projekte, um den Open Source Security Foundation (OpenSSF) Best Practices Badge Level "Gold" zu erreichen. Sie können diese Liste nur mit den Kriterien oder mit zusätzlichen Informationen anschauen. Es sind auch die Kriterien für alle Badge Level verfügbar.

Siehe die Kriterien Diskussion für weitere Informationen zu diesen Kriterien.

Gold

Grundlagen

Voraussetzungen

• Das Projekt MUSS ein Silber-Siegel erreichen. ^{[achieve_silver]}

Projektüberwachung

• Das Projekt MUSS einen "Busfaktor" von 2 oder mehr haben. {URL erfüllt} ^[bus_factor]
• Das Projekt MUSS mindestens zwei unabhängige bedeutende Entwickler haben. {URL erfüllt} ^{[contributors_unassociated]}

  Details:

  Die Mitwirkenden sind assoziiert, wenn sie von der gleichen Organisation (als Angestellter oder Auftragnehmer) bezahlt werden und die Organisation von den Ergebnissen des Projekts profitieren wird. Finanzielle Zuschüsse aus derselben Organisation zählen nicht, wenn sie durch andere Organisationen gehen (z.B. werden wissenschaftliche Zuschüsse, die an verschiedene Organisationen von einer gemeinsamen Regierung oder NGO-Quelle gezahlt werden, nicht dazu führen, dass die Mitwirkenden assoziiert werden). Jemand ist ein/e wichtige/r Mitwirkende/r, wenn sie/er im vergangenen Jahr nicht-triviale Beiträge zum Projekt geleistet hat. Beispiele für gute Indikatoren für einen bedeutenden Mitwirkenden sind: mindestens 1.000 Zeilen Code geschrieben, 50 Commits erarbeitet oder mindestens 20 Seiten zur Dokumentation beigetragen.

Andere

• Das Projekt MUSS eine Copyright-Erklärung in jeder Quelldatei enthalten, die den Urheberrechtsinhaber identifiziert (z. B. den [Projektnamen] oder die Contributors). {Begründung erfüllt} ^{[copyright_per_file]}

  Details:

  Dies DARF getan werden, indem man Folgendes innerhalb eines Kommentars relativ am Anfangs jeder Datei einfügt: Copyright the [project name] contributors.". Siehe "Copyright Notices in Open Source Software Projects" by Steve Winslow.

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

  Details:

  Dies DARF auch durch die Einbeziehung einer Erklärung in natürlicher Sprache geschehen, die die Lizenz kennzeichnet. Das Projekt DARF auch eine stabile URL enthalten, die auf den Lizenztext oder den vollständigen Lizenztext hinweist. Beachten Sie, dass das Kriterium license_location die Projektlizenz an einem Standardstandort benötigt. Weitere Informationen zu SPDX-Lizenzausdrücken finden Sie unter SPDX-Tutorial . Beachten Sie die Beziehung zu copyright_per_file , deren Inhalt typischerweise den Lizenzinformationen vorausgeht.

Verbesserungs-/Nacharbeits-Kontrolle

Öffentliches Versionskontroll-Source-Repository

• Das Source-Repository des Projekts MUSS eine geläufige, verteilte Versionskontrollsoftware (z. B. git oder mercurial) verwenden. {Begründung erfüllt} ^{[repo_distributed]}
• Das Projekt MUSS eindeutig kleine Aufgaben identifizieren, die von neuen oder gelegentlichen Mitwirkenden durchgeführt werden können. {URL erfüllt} ^{[small_tasks]}

  Details:

  Diese Identifizierung erfolgt in der Regel durch die Markierung ausgewählter Ausgaben in einem Issue-Tracker mit einem oder mehreren Tags, die das Projekt für den Zweck verwendet, z.B. up-for-Grabs , First-Timers-only , "Small fix", Microtask oder IdealFirstBug. Diese neuen Aufgaben müssen nicht das Hinzufügen von Funktionalität beinhalten. Sie können die Dokumentation verbessern, Testfälle hinzufügen oder irgendetwas anderes, das das Projekt unterstützt und den Mitwirkenden hilft mehr über das Projekt zu verstehen.

• Das Projekt MUSS eine Zwei-Faktor-Authentifizierung (2FA) für Entwickler haben, um ein zentrales Repository zu wechseln oder auf sensible Daten zugreifen zu können (z. B. private Schwachstellen-Berichte). Dieser 2FA-Mechanismus DARF Mechanismen ohne kryptographische Mechanismen wie SMS verwenden, obwohl dies nicht empfohlen wird. {Begründung erfüllt} ^{[require_2FA]}
• Die Zwei-Faktor-Authentifizierung des Projekts (2FA) SOLLTE Kryptographie-Mechanismen verwenden, um Identitätswechsel zu verhindern. Short-Message-Service-/SMS-basierte 2FAs allein erfüllen dieses Kriterium nicht, da sie nicht verschlüsselt sind. {Begründung erfüllt} ^[secure_2FA]

  Details:

  Ein 2FA-Mechanismus, der dieses Kriterium erfüllt, wäre eine Time-Based-One-Time-Password-/TOTP-Anwendung, die automatisch einen Authentifizierungscode generiert, der sich nach einer gewissen Zeit ändert. Beachten Sie, dass GitHub TOTP unterstützt.

Qualität

Programmierstil

• Das Projekt MUSS seine Code-Review-Anforderungen dokumentieren, einschließlich, wie Code-Überprüfung durchgeführt wird, was überprüft werden muss und was erforderlich ist, um akzeptabel zu sein. {N/A Begründung} {URL erfüllt} ^{[code_review_standards]}

  Details:

  Siehe auch two_person_review und contribution_requirements.

• Das Projekt MUSS mindestens 50% aller vorgeschlagenen Änderungen vor dem Release durch eine andere Person als den Autor überprüfen, um festzustellen, ob es sich um eine sinnvolle Änderung handelt und frei von bekannten Problemen ist, die gegen die Freigabe der Änderung sprechen würden {Begründung erfüllt} ^{[two_person_review]}

Produktivsystem

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

  Details:

  Eine reproduzierbares Build bedeutet, dass mehrere Parteien den Prozess der Generierung von Informationen aus Quelldateien unabhängig voneinander wiederholen und genau das gleiche Bit-für-Bit-Ergebnis erhalten können. In manchen Fällen kann dies dadurch gelöst werden, dass man eine Sortierreihenfolge erzwingt. JavaScript-Entwickler können erwägen npm shrinkwrap und webpack OccurenceOrderPlugin zu verwenden. GCC und clang Benutzer könnten die Option -frandom-seed nützlich finden. Die Buildumgebung (einschließlich des Toolsets) kann oft für externe Teilnehmer definiert werden, indem der kryptografische Hash eines bestimmten Containers oder einer virtuellen Maschine angegeben wird, die sie für das Kompilieren verwenden können. Das Reproducible Builds Projekt hat eine Dokumentation, wie dies erreicht werden kann.

Automatisierte Test-Suite

• Eine Test-Suite MUSS in einer standardisierten Weise für diese Programmiersprache anrufbar sein. {URL erfüllt} ^{[test_invocation]}
• Das Projekt MUSS eine kontinuierliche Integration implementieren, bei der neue oder geänderte Codes häufig in ein zentrales Code-Repository integriert werden und automatisierte Tests auf dem Ergebnis durchgeführt werden. {URL erfüllt} ^{[test_continuous_integration]}

  Details:

  In den meisten Fällen bedeutet dies, dass jeder Entwickler, der Vollzeit auf dem Projekt arbeitet, mindestens täglich integriert.

• Das Projekt MUSS automatisierte FLOSS-Test-Suite(n) einsetzen, die mindestens 90% der Befehle abdecken, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Programmiersprache messen kann. {N/A Begründung} {Begründung erfüllt} ^{[test_statement_coverage90]}
• Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) mit mindestens 80% Zweig-Abdeckung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache messen kann. {N/A Begründung} {Begründung erfüllt} ^{[test_branch_coverage80]}

Sicherheit

Verwende grundlegend gute kryptographische Praktiken

• Die vom Projekt produzierte Software MUSS sichere Protokolle für alle Netzwerkkommunikationen unterstützen , wie SSHv2 oder höher, TLS1.2 oder höher (HTTPS), IPsec, SFTP und SNMPv3. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder früher, und SSHv1 MÜSSEN standardmäßig deaktiviert werden und nur aktiviert werden, wenn der/die Benutzer/in es speziell konfiguriert. Wenn die vom Projekt produzierte Software keine Netzwerkkommunikation verwendet, wählen Sie "nicht anwendbar" (N/A). {N/A erlaubt} {Begründung erfüllt} ^{[crypto_used_network]}
• Die Projektsoftware MUSS, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). {N/A erlaubt} {Begründung erfüllt} ^{[crypto_tls12]}

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

• Die Projekt-Website, das Repository (wenn über das Internet zugänglich) und die heruntergelandenen Seiten (falls separat) MÜSSEN Key-Hardening-Headers mit nichtpermeablen Werten enthalten. {URL erfüllt} ^{[hardened_site]}

  Details:

  Beachten Sie, dass GitHub und GitLab bekannt bekannterweise dies erfüllen. Websites wie https://securityheaders.io/ können dies schnell überprüfen. Die wichtigsten Key-Hardening-Header sind: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. Komplett statische websiten die keine Möglichkeit für das anmelden auf der webseite erlauben können vermutlich mit geringer Gefahr einige Hardening-Headers weglassen; es gibt jedoch keine verlässliche Methode solche Seiten zu identifizieren und deshalb erfordern wir diese Headers auch auf voll statischen Webseiten.

Andere Sicherheitsissues

• Das Projekt MUSS innerhalb der letzten 5 Jahre eine Sicherheitsüberprüfung durchgeführt haben. Diese Überprüfung muss die Sicherheitsanforderungen und die Sicherheitsgrenze berücksichtigen. {Begründung erfüllt} ^{[security_review]}

  Details:

  Dies DARF durch die Projektmitglieder und/oder eine unabhängige Bewertung geschehen. Diese Bewertung kann durch statische und dynamische Analyse-Tools unterstützt werden, aber es muss auch eine menschliche Überprüfung sein, um Probleme zu identifizieren (insbesondere im Design), die Werkzeuge nicht erkennen können.

• Härtungsmechanismen müssen in der Projektsoftware verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. {N/A Begründung} {URL erfüllt} ^[hardening]

Analyse

Dynamische Codeanalyse

• Das Projekt MUSS mindestens ein dynamisches Analyse-Tool auf jeden kommenden Hauptproduktionsrelease der Software, die durch das Projekt vor seiner Freigabe produziert wird, anwenden. {N/A Begründung} {Begründung erfüllt} ^{[dynamic_analysis]}
• Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. {N/A Begründung} {Begründung erfüllt} ^{[dynamic_analysis_enable_assertions]}