Kriteriendiskussion

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 aufrechterhalten 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 dabei helfen kann, ansonsten schwer zu findende technische Schwachstellen zu finden, als auch Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Organisationen aufzubauen.

Diese Seite diskutiert die Best Practices für Free/Libre and Open Source Software (FLOSS) Projekte, die für den Best Practices Badge der Open Source Security Foundation (OpenSSF) entwickelt wurden. Projekte, die diese Best Practices befolgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie das relevante Badge erreicht haben. Projekte können dies kostenlos tun, indem sie eine Webanwendung (BadgeApp) verwenden, um zu erklären, wie sie diese Praktiken und deren detaillierte Kriterien erfüllen.

Diese Best Practices wurden erstellt, um:

1. Projekte zu ermutigen, Best Practices zu befolgen,
2. neuen Projekten zu helfen, herauszufinden, was diese Praktiken sind, und
3. Benutzern dabei zu helfen, zu wissen, welche Projekte Best Practices befolgen (damit Benutzer solche Projekte bevorzugen können).

Die Redewendung "Best Practices" bedeutet "ein Verfahren oder eine Reihe von Verfahren, die innerhalb einer Organisation, Branche usw. bevorzugt oder als Standard angesehen werden" (Quelle: Dictionary.com). Diese Kriterien sind das, was wir glauben, dass in der breiteren FLOSS-Community weithin "bevorzugt oder als Standard angesehen" wird.

Weitere Informationen darüber, wie diese Kriterien entwickelt wurden, finden Sie auf der OpenSSF Best Practices Badge GitHub-Seite.

Sie können auch die vollständigen Kriterien sehen.

Kriterienstruktur

Die Best Practices Kriterien sind in drei Stufen unterteilt:

• Passing konzentriert sich auf Best Practices, die gut geführte FLOSS-Projekte normalerweise bereits befolgen. Das Passing-Badge zu erhalten, ist eine Leistung; zu jedem Zeitpunkt erreichen nur etwa 10% der Projekte, die ein Badge anstreben, die Passing-Stufe.
• Silver ist eine strengere Gruppe von Kriterien als Passing, wird aber erwartet, dass sie von kleinen und Einzel-Organisations-Projekten erreichbar ist.
• Gold ist noch strenger als Silver und umfasst Kriterien, die für kleine oder Einzel-Organisations-Projekte nicht erreichbar sind.

Jedes Kriterium hat einen Kurznamen, der als hochgestellter Text in eckigen Klammern nach dem Kriterientext angezeigt wird.

Beziehung zu anderen Projekten

Die Linux Foundation sponsert auch das OpenChain-Projekt, das Kriterien für ein "qualitativ hochwertiges Free and Open Source Software (FOSS) Compliance-Programm" identifiziert. OpenChain konzentriert sich darauf, wie Organisationen FLOSS am besten nutzen und zu FLOSS-Projekten beitragen können, während sich das OpenSSF Best Practices Badge auf die FLOSS-Projekte selbst konzentriert. Das OpenSSF Best Practices Badge und OpenChain arbeiten zusammen, um FLOSS und die Nutzung von FLOSS zu verbessern.

Kriterienautomatisierung

In einigen Fällen testen und füllen wir automatisch Informationen aus, wenn das Projekt Standardkonventionen folgt und auf einer Seite (z.B. GitHub) mit anständiger API-Unterstützung gehostet wird.

Wir beabsichtigen, diese Automatisierung in Zukunft zu verbessern. Verbesserungen der Automatisierung sind willkommen!

Wir haben jedoch absichtlich Priorität auf "was wichtig ist" gelegt, auch wenn es nicht kostengünstig automatisiert werden kann. Wir lieben automatisierte Messungen, aber nicht alles Wichtige ist automatisierbar oder kann kostengünstig automatisiert werden.

Änderungen im Laufe der Zeit

Wir erwarten, dass diese Praktiken und ihre detaillierten Kriterien im Laufe der Zeit aktualisiert werden. Wir planen, neue Kriterien hinzuzufügen, aber sie als "zukünftige" Kriterien zu kennzeichnen, sodass Projekte diese Informationen hinzufügen und ihr Badge behalten können.

Feedback ist sehr willkommen über die GitHub-Website als Issues oder Pull-Requests. Es gibt auch eine Mailingliste für allgemeine Diskussionen.

Schlüsselwörter

Die Schlüsselwörter "MUSS", "DARF NICHT", "SOLLTE", "SOLLTE NICHT" und "DARF" in diesem Dokument sind wie in RFC 2119 beschrieben zu interpretieren. Der zusätzliche Begriff EMPFOHLEN wird hinzugefügt. Zusammengefasst haben diese Schlüsselwörter die folgenden Bedeutungen:

• Der Begriff MUSS ist eine absolute Anforderung, und DARF NICHT ist ein absolutes Verbot.
• Der Begriff SOLLTE weist auf ein Kriterium hin, das normalerweise erforderlich ist, aber es können gültige Gründe unter bestimmten Umständen bestehen, es zu ignorieren. Allerdings müssen die vollständigen Auswirkungen verstanden und sorgfältig abgewogen werden, bevor eine andere Vorgehensweise gewählt wird.
• Der Begriff EMPFOHLEN wird anstelle von SOLLTE verwendet, wenn das Kriterium berücksichtigt werden muss, aber die gültigen Gründe, dies nicht zu tun, noch häufiger sind als bei SOLLTE.
• Der Begriff DARF bietet eine Möglichkeit, wie etwas getan werden kann, z.B. um klarzustellen, dass die beschriebene Implementierung akzeptabel ist.

Oft wird ein Kriterium als etwas angegeben, das getan werden SOLLTE oder EMPFOHLEN wird, weil es schwierig zu implementieren sein kann oder die Kosten dafür hoch sein können.

Ein Badge erreichen

Um ein Badge zu erhalten, müssen alle MUSS- und DARF NICHT-Kriterien erfüllt sein, alle SOLLTE-Kriterien müssen entweder erfüllt ODER nicht erfüllt mit Begründung sein, und alle EMPFOHLEN-Kriterien müssen berücksichtigt werden (sie müssen als erfüllt oder nicht erfüllt bewertet werden, aber eine Begründung ist nicht erforderlich, sofern nicht anders angegeben). Eine Antwort von N/A ("nicht zutreffend"), wo erlaubt, wird als erfüllt betrachtet. In einigen Fällen, insbesondere bei den höheren Stufen, können eine Begründung und/oder eine URL erforderlich sein.

Einige Kriterien haben spezielle Kennzeichnungen, die dies beeinflussen:

• {N/A erlaubt} - "N/A" ("Nicht zutreffend") ist erlaubt.
• {N/A Begründung} - "N/A" ("Nicht zutreffend") ist erlaubt und erfordert eine Begründung.
• {Erfüllt Begründung} - "Erfüllt" erfordert eine Begründung.
• {Erfüllt URL} - "Erfüllt" erfordert eine Begründung mit einer URL.
• {Zukünftig} - die Antwort auf dieses Kriterium hat derzeit keine Auswirkung, kann aber in Zukunft erforderlich sein.

Ein Projekt muss die vorherige Stufe erreichen, um die nächste Stufe zu erreichen. In einigen Fällen werden SOLLTE-Kriterien bei höheren Badge-Stufen zu MUSS, und einige EMPFOHLEN-Kriterien bei niedrigeren Stufen werden bei höheren Badge-Stufen zu SOLLTE oder MUSS. Die höheren Stufen erfordern auch mehr Begründung, weil wir möchten, dass andere verstehen, wie die Kriterien erfüllt werden.

Die (vielen) kryptografischen Kriterien gelten nicht immer, da einige Software nicht direkt kryptografische Fähigkeiten verwenden muss. Geben Sie in diesen Fällen N/A an.

Es gibt ein implizites Passing-Kriterium - jedes Projekt MUSS eine öffentliche Website mit einer stabilen URL haben. Dies ist erforderlich, um überhaupt einen Badge-Eintrag zu erstellen.

Terminologie

Wenn Sie mit Softwareentwicklung oder dem Betreiben eines FLOSS-Projekts nicht vertraut sind, können Materialien wie Producing Open Source Software von Karl Fogel für Sie hilfreich sein.

Hier sind einige wichtige Begriffe:

• Ein Projekt ist eine aktive Einheit, die Projektmitglied(er) hat und Projektergebnis(se) hervorbringt. Seine Mitglieder nutzen Projektseiten, um die Ergebnisse zu koordinieren und zu verbreiten. Ein Projekt muss keine formale juristische Person sein.
• Projekt-Mitglieder sind die Gruppe von einer oder mehreren Personen oder Unternehmen, die zusammenarbeiten, um Projektergebnisse zu erzielen. Einige FLOSS-Projekte können verschiedene Arten von Mitgliedern mit unterschiedlichen Rollen haben, aber das liegt außerhalb unseres Bereichs.
• Projekt-Ergebnisse sind das, was die Projektmitglieder zusammenarbeiten, um als ihr Endziel zu produzieren. Normalerweise ist dies Software, aber Projektergebnisse können auch andere Dinge beinhalten. Kriterien, die sich auf "vom Projekt produzierte Software" beziehen, beziehen sich auf Projektergebnisse.
• Projekt-Seiten sind die Seiten, die der Unterstützung der Entwicklung und Verbreitung von Projektergebnissen gewidmet sind, und umfassen die Projektwebsite, das Repository und gegebenenfalls die Download-Seiten (siehe sites_https).
• Die Projekt-Website, auch Projekt-Homepage genannt, ist die Hauptseite im World Wide Web (WWW), die ein neuer Benutzer typischerweise besuchen würde, um Informationen über das Projekt zu sehen; sie kann mit der Repository-Seite des Projekts identisch sein (dies ist oft auf GitHub der Fall).
• Das Projekt-Repository verwaltet und speichert die Projektergebnisse und die Revisionshistorie der Projektergebnisse. Dies wird auch als Projekt-Quell-Repository bezeichnet, da wir nur die Verwaltung und Speicherung der editierbaren Versionen verlangen, nicht der automatisch generierten Ergebnisse (in vielen Fällen werden generierte Ergebnisse nicht in einem Repository gespeichert).
• Ein Projekt-Sicherheitsmechanismus ist ein Sicherheitsmechanismus, der von der gelieferten Software des Projekts bereitgestellt wird.

Nicht-Kriterien

Die Kriterien:

• erfordern keine spezifische Technologie, kein bestimmtes Produkt oder keinen bestimmten Dienst. Zum Beispiel erfordern sie nicht git, GitHub oder GitLab. Die Kriterien bieten jedoch Anleitungen und Hilfe für häufige Fälle, da diese Informationen Menschen helfen können, die Kriterien zu verstehen und zu erfüllen. Es gibt einige spezielle Automatisierungen für Projekte, die git oder GitHub verwenden, um Benutzern in diesen häufigen Fällen zu helfen, aber sie sind nicht erforderlich. Auf diese Weise können Projekte schnell zu neuen Tools und Fähigkeiten wechseln, sobald diese verfügbar werden. Als Ausnahmen erfordern die Kriterien eine Projekt-Webseite und TLS.
• erfordern oder verbieten keine bestimmte Programmiersprache. Sie erfordern jedoch, dass für bestimmte Arten von Programmiersprachen zusätzliche Maßnahmen ergriffen werden, aber das ist etwas anderes.
• erfordern niemals die Verwendung proprietärer Software, proprietärer Dienste oder proprietärer Technologien, da viele Freie-Software-Entwickler solche Kriterien ablehnen würden. Projekte dürfen sie verwenden und von ihnen abhängen.
• erfordern keine aktive Entwicklung oder Benutzerdiskussion innerhalb eines Projekts. Einige hochreife Projekte ändern sich selten und haben daher möglicherweise wenig Aktivität. Die Kriterien erfordern jedoch, dass das Projekt reaktionsfähig ist, wenn dem Projekt Schwachstellen gemeldet werden.
• erfordern keine Gebühren, um ein Badge zu erhalten.
• erfordern nicht, dass alle Kriterien auf einmal implementiert werden; die meisten Projekte implementieren sie im Laufe der Zeit.

Die Passing-Stufe beinhaltet keine Kriterien, die für ein Ein-Personen-Projekt unpraktisch wären, z.B. etwas, das einen erheblichen Geldbetrag erfordert. Viele FLOSS-Projekte sind klein, und wir wollen sie nicht benachteiligen.

Ein Projekt identifizieren

Unsere Anwendung gibt jedem Projekteintrag eine eindeutige ID, aber das hilft Leuten, die nach dem Projekt suchen, nicht. Für unsere Zwecke ist der eigentliche Name eines Projekts die URL für sein Repository, und wo dies nicht verfügbar ist, die URL der Projekt-"Startseite". Wir begrenzen Änderungen an der Repository-URL, um Unsinn zu verhindern. Projekte haben normalerweise einen von Menschen lesbaren Namen, aber diese Namen sind nicht eindeutig genug.

Warum haben wir Kriterien?

Das Papier Open Badges für Bildung: was sind die Auswirkungen an der Schnittstelle von offenen Systemen und Badging? identifiziert drei allgemeine Gründe für Badge-Systeme (alle sind hierfür gültig):

1. Badges als Motivator von Verhalten. Wir hoffen, dass wir durch die Identifizierung von Best Practices Projekte ermutigen werden, diese Best Practices umzusetzen, wenn sie dies noch nicht tun.
2. Badges als pädagogisches Werkzeug. Einige Projekte sind sich möglicherweise einiger Best Practices, die von anderen angewendet werden, nicht bewusst, oder wie sie praktisch angewendet werden können. Der Badge wird ihnen helfen, sich dieser bewusst zu werden und Wege zu ihrer Umsetzung zu finden.
3. Badges als Kennzeichen oder Nachweis. Potenzielle Benutzer möchten Projekte verwenden, die Best Practices anwenden, um konsequent gute Ergebnisse zu erzielen; Badges machen es für Projekte einfach zu signalisieren, dass sie Best Practices folgen, und machen es für Benutzer einfach zu sehen, welche Projekte dies tun.

Warum Selbstzertifizierung?

Wir haben uns für die Verwendung von Selbstzertifizierung entschieden, da dies es einer großen Anzahl von Projekten (sogar kleinen) ermöglicht, teilzunehmen. Es gibt Millionen von FLOSS-Projekten, und das Bezahlen Dritter, um jedes einzelne unabhängig zu bewerten, skaliert nicht. Es besteht das Risiko, dass Projekte falsche Behauptungen aufstellen, aber wir denken, das Risiko ist gering, Benutzer können die Behauptungen selbst überprüfen, und falsche Behauptungen können überschrieben werden. Wir verwenden auch Automatisierung, um falsche Behauptungen zu überschreiben, wo wir von den Ergebnissen überzeugt sein können.