FLOSS Best Practices Kriterien (Alle Level)

Dies sind die Best Practices für Free/Libre und Open Source Software (FLOSS) Projekte, um die Best Practices Badges der Open Source Security Foundation (OpenSSF) der Level Passing, Silber und Gold zu erhalten. Sie können diese Liste nur mit den Kriterien oder mit zusätzlichen Informationen anschauen. Sie können auch nur die Kriterien für die Level Passing, Silber und Gold, sowie Kriterien Statistiken anschauen.

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

Passing

Grundlagen

Grundlegende Informationen auf der Projektwebseite

  • Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]
  • 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 erfüllt} [contribution]
  • 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 erfüllt} [contribution_requirements]

FLOSS-Lizenz

  • Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]
  • 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]
  • Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. {URL erfüllt} [license_location]

Dokumentation

  • Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. {N/A Begründung} [documentation_basics]
  • Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. {N/A Begründung} [documentation_interface]

Andere

  • Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]
  • Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]
  • 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]
  • The project MUST be maintained. [maintained]

Verbesserungs-/Nacharbeits-Kontrolle

Öffentliches Versionskontroll-Source-Repository

  • Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]
  • Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]
  • 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]
  • Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]

Einzigartige Versionsnummerierung

  • Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]
  • Es ist EMPFHOLEN, dass ein Semantic Versioning (SemVer) oder Calendar Versioning (CalVer) Versionsnummerierungsformat für Releases verwendet wird. Es ist EMPFHOLEN, dass Anwender des CalVer Formates auch die Micro Ebene mit angeben. [version_semver]
  • Es wird erwartet, dass Projekte jedes Release innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jedes Release mit git-Tags identifizieren. [version_tags]

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

Berichterstattung

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 erfüllt} [report_process]
  • Das Projekt SOLLTE einen Issue-Tracker für die Nachverfolgung einzelner Issues verwenden. [report_tracker]
  • Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]
  • Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]
  • Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. {URL erfüllt} [report_archive]

Anfälligkeits-Prozessbericht

  • Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. {URL erfüllt} [vulnerability_report_process]
  • Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. {N/A erlaubt} {URL erfüllt} [vulnerability_report_private]
  • Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. {N/A erlaubt} [vulnerability_report_response]

Qualität

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. {N/A erlaubt} [build]
  • Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompilieren von Software benutzt wird. {N/A erlaubt} [build_common_tools]
  • Das Projekt SOLLTE allein mit FLOSS-Werkzeugen gebaut werden können. {N/A erlaubt} [build_floss_tools]

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]
  • Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]
  • Es wird erwartet, dass die Test-Suite die meisten (oder idealerweise alle) Code-Zweige, Eingabefelder und Funktionalitäten abdeckt. [test_most]
  • 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]

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]
  • 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]
  • Es wird erwartet, dass diese Richtlinien zum Hinzufügen von Tests (siehe test_policy ) in den Anweisungen für Änderungsvorschläge dokumentiert werden. [tests_documented_added]

Warnhinweise

  • Das Projekt MUSS einen oder mehrere Compiler-Warn-Flags, einen "sicheren" Sprachmodus oder ein separates "Linter" -Tool verwenden, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium implementieren kann in der gewählten sprache {N/A erlaubt} [warnings]
  • Das Projekt MUSS auf Warnungen reagieren. {N/A erlaubt} [warnings_fixed]
  • Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. {N/A erlaubt} [warnings_strict]

Sicherheit

Wissen über sichere Entwicklungspraktiken

  • Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß, wie man sichere Software entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]
  • Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]

Verwende grundlegend gute kryptographische Praktiken

  • 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). {N/A erlaubt} [crypto_published]
  • Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. {N/A erlaubt} [crypto_call]
  • Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. {N/A erlaubt} [crypto_floss]
  • Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. {N/A erlaubt} [crypto_keylength]
  • Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software DÜRFEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereitzustellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch ein Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. {N/A erlaubt} [crypto_working]
  • 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). {N/A erlaubt} [crypto_weaknesses]
  • 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. {N/A erlaubt} [crypto_pfs]
  • 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). {N/A erlaubt} [crypto_password_storage]
  • 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. {N/A erlaubt} [crypto_random]

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 kryptographischer Hash (z.B. sha1sum) DARF NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]

Öffentlich bekannte Schwachstellen wurden behoben

  • Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höherer Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]
  • Projekte SOLLTEN alle kritischen Schwachstellen schnell beheben, nachdem sie gemeldet wurden. [vulnerabilities_critical_fixed]

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]

Analyse

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. {N/A Begründung} {Begründung erfüllt} [static_analysis]
  • 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. {N/A erlaubt} [static_analysis_common_vulnerabilities]
  • Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. {N/A erlaubt} [static_analysis_fixed]
  • Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. {N/A erlaubt} [static_analysis_often]

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]
  • 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). {N/A erlaubt} [dynamic_analysis_unsafe]
  • 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]
  • Alle mittel- und höhergradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. {N/A erlaubt} [dynamic_analysis_fixed]

Silber

Grundlagen

Voraussetzungen

Grundlegende Informationen auf der Projektwebseite

  • Die Informationen darüber, wie man mitwirken kann, MÜSSEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf einen erforderlichen Codierungsstandard) enthalten. {URL erfüllt} [contribution_requirements]

Projektüberwachung

  • Das Projekt SOLLTE einen rechtlichen Mechanismus haben, wo alle Entwickler von nicht-trivialen Beiträgen versichern, dass sie rechtlich ermächtigt sind, diese Beiträge zu machen. Der häufigste und leicht umsetzbare Ansatz, ist die Verwendung eines Developer Certificate of Origin (DCO) , wo Benutzer "signed-off-by" in ihren Commits und die Projektlinks zur DCO-Website hinzufügen. Allerdings DARF dies als Contributor License Agreement (CLA) oder als ein anderer rechtlicher Mechanismus implementiert werden. {URL erfüllt} [dco]
  • Das Projekt MUSS eindeutig sein Projekt-Governance-Modell (die Art, wie es Entscheidungen fällt, einschließlich der wichtigsten Rollen) definieren und dokumentieren. {URL erfüllt} [governance]
  • Das Projekt MUSS einen Code of Conduct etablieren und an einem üblichen Ort veröffentlichen. {URL erfüllt} [code_of_conduct]
  • Das Projekt MUSS klar und deutlich die Rollen- auf Aufgabenverteilung dokumentieren, inklusive einzelnen Tätigkeiten, die von den Rollenträgern ausgeführt werden müssen. Es MUSS eindeutig sein wer welche Rolle hat, auch wenn es in anderer Form dokumentiert ist. {URL erfüllt} [roles_responsibilities]
  • Das Projekt MUSS in der Lage sein, mit minimaler Unterbrechung fortzufahren, wenn eine beliebige Person nicht in der Lage ist oder stirbt. Insbesondere MUSS das Projekt in der Lage sein, Probleme zu lösen, vorgeschlagene Änderungen zu akzeptieren und Versionen der Software freizugeben, innerhalb einer Woche nach der Bestätigung, dass eine Person nicht mehr in der Lage ist oder gestorben ist. Dies DARF sichergestellt werden, indem man jemandem anderes notwendige Schlüssel, Passwörter und gesetzliche Rechte gibt, um das Projekt fortzusetzen. Einzelpersonen, die ein FLOSS-Projekt ausführen, DÜRFEN dies durch die Bereitstellung von Schlüsseln in einer Lockbox und einer Willenserklärung zur Bereitstellung von erforderlichen gesetzlichen Rechten (z. B. für DNS-Namen). {URL erfüllt} [access_continuity]
  • Das Projekt SOLLTE einen Bus-Faktor von 2 oder mehr haben. {URL erfüllt} [bus_factor]

Dokumentation

  • Das Projekt MUSS eine dokumentierte Roadmap, für mindestens das nächste Jahr haben, die beschreibt, was das Projekt beabsichtigt zu tun und nicht zu tun. {URL erfüllt} [documentation_roadmap]
  • Das Projekt MUSS in der Dokumentation die Architektur (alias High-Level-Design) der vom Projekt entwickelten Software bereitstellen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {URL erfüllt} [documentation_architecture]
  • Das Projekt MUSS dokumentieren, was der/die Benutzer/in in Bezug auf die Sicherheit der Projektsoftware (seine "Sicherheitsanforderungen") erwarten kann und nicht erwarten kann. {N/A erlaubt} {URL erfüllt} [documentation_security]
  • Das Projekt MUSS eine "Quickstart"-Anleitung für neue Benutzer/innen haben, um ihnen zu helfen, schnell mit der Software umgehen zu können. {N/A Begründung} {URL erfüllt} [documentation_quick_start]
  • Das Projekt MUSS sich bemühen, die Dokumentation mit der aktuellen Version der Projektergebnisse (einschließlich der vom Projekt produzierten Software) stehts zu aktualisieren. Jegliche bekannte Dokumentationsfehler, die es inkonsistent machen, MÜSSEN behoben werden. Wenn die Dokumentation in der Regel aktuell ist, aber fälschlicherweise einige ältere Informationen enthält, die nicht mehr wahr sind, behandeln Sie diese als Störung, dann verfolgen und beheben Sie diese wie üblich. {N/A Begründung} {Begründung erfüllt} [documentation_current]
  • Die Projekt-Repository-Titelseite und / oder Website MUSS alle Errungenschaften, die erreicht wurden, einschließlich dieses Best Practices Abzeichens, innerhalb von 48 Stunden nach der öffentlichen Anerkennung ausweisen und verlinken. {URL erfüllt} [documentation_achievements]

Zugänglichkeit und Internationalisierung

  • Das Projekt (beide Projektwebsite und Projektergebnisse) SOLLTE den bewährten Praktiken der Erreichbarkeit folgen, damit Personen mit Behinderungen noch an dem Projekt teilnehmen und die Projektergebnisse nutzen können, wo es vernünftig ist. {N/A Begründung} {Begründung erfüllt} [accessibility_best_practices]
  • Die Projektsoftware SOLLTE internationalisiert werden, um eine einfachen Zugang für die Kultur, Region oder Sprache der Zielgruppe zu ermöglichen. Wenn die Internationalisierung (i18n) nicht andzuwenden ist (z. B. die Software keine für Endbenutzer beabsichtigte Texte erzeugt und keinen menschlich lesbaren Text sortiert), wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {Begründung erfüllt} [internationalization]

Andere

  • Wenn die Projektseiten (Website, Repository und Download-URLs) Passwörter für die Authentifizierung von externen Benutzern speichern, 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). Wenn die Projektseiten hierfür keine Passwörter speichern, wählen Sie "nicht anwendbar" (N/A) aus. {N/A Begründung} {Begründung erfüllt} [sites_password_security]

Verbesserungs-/Nacharbeits-Kontrolle

Vorherige Versionen

  • Das Projekt MUSS die am häufigsten verwendeten älteren Versionen des Produkts beibehalten oder einen Upgrade-Pfad zu neueren Versionen bieten. Wenn der Upgrade-Pfad schwierig durchzuführen ist, muss das Projekt dokumentieren, wie das Upgrade durchgeführt werden kann (z. B. die Interfaces, die sich geändert haben, detaillierte Anleitung für die Aktualisierung des Upgrades). {N/A Begründung} {Begründung erfüllt} [maintenance_or_update]

Berichterstattung

Bug-Report-Prozess

  • Das Projekt MUSS ein Issue-Tracking-System zur Verwaltung einzelner Issues verwenden. {N/A Begründung} {Begründung erfüllt} [report_tracker]

Anfälligkeits-Prozessbericht

  • Das Projekt MUSS die Reporter/in von allen in den letzten 12 Monaten bekanntgegebenen Schwachstellenberichte aufführen, mit Ausnahme der Reporter, die Anonymität erbeten. Wurde in den letzten 12 Monaten keine Schwachstelle festgestellt, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {URL erfüllt} [vulnerability_report_credit]
  • Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. {URL erfüllt} [vulnerability_response_process]

Qualität

Programmierstil

  • Das Projekt MUSS die spezifischen Codierungsstilrichtlinien für die primären Programmierprachen, die es verwendet, einhalten, und erfordern, dass die Beiträge die Bedingungen generell erfüllen. {N/A Begründung} {URL erfüllt} [coding_standards]
  • Das Projekt MUSS automatisch dafür sorgen, dass die ausgewählten Stilrichtlinien eingehalten werden, wenn mindestens ein FLOSS-Tool vorhanden ist, welches das in der gewählten Programmiersprache tun kann. {N/A Begründung} {Begründung erfüllt} [coding_standards_enforced]

Produktivsystem

  • Build-Systeme für native Binärdateien MÜSSEN die relevanten Compiler- und Linker- (Umgebungs-) Variablen, die an sie übergeben werden (z.B. CC, CFLAGS, CXX, CXXFLAGS und LDFLAGS), respektieren und an Compiler- und Linker-Aufrufe weiterleiten. Ein Build-System DARF sie mit zusätzlichen Flags erweitern; Es DARF NICHT einfach die mitgelieferten Werte ersetzen. Wenn keine nativen Binärdateien erzeugt werden, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {Begründung erfüllt} [build_standard_variables]
  • Das Build- und Installationssystem SOLLTE Debugging-Informationen beibehalten, wenn sie in den entsprechenden Flags angefordert werden (z. B. "install -s" wird nicht verwendet). Wenn kein Build- oder Installationssystem vorhanden ist (z. B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). {N/A Begründung} {Begründung erfüllt} [build_preserve_debug]
  • Das Build-System für die Software, die durch das Projekt erzeugt wird, DARF NICHT rekursive Unterverzeichnisse aufbauen, wenn es Querverweise in den Unterverzeichnissen gibt. Wenn kein Build- oder Installationssystem vorhanden ist (z.B. typische JavaScript-Bibliotheken), wählen Sie "nicht anwendbar" (N / A). {N/A Begründung} {Begründung erfüllt} [build_non_recursive]
  • Das Projekt MUSS in der Lage sein, den Prozess der Generierung von Informationen aus Quelldateien zu wiederholen und genau das gleiche Bit-für-Bit-Ergebnis zu erhalten. Wenn kein Build auftritt (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} {Begründung erfüllt} [build_repeatable]

Installationssystem

  • Das Projekt MUSS eine Möglichkeit zur einfachen Installation und Deinstallation der Software haben, unter Benutzung einer häufig verwendeten Methode. {N/A Begründung} {Begründung erfüllt} [installation_common]
  • Das Installationssystem für den/die Endbenutzer/in MUSS Standardkonventionen zur Auswahl des Zielortes, in dem gebildete Artefakte zur Installationszeit geschrieben werden, folgen. Zum Beispiel, wenn es Dateien auf einem POSIX-System installiert, muss es die DESTDIR-Umgebungsvariable verwenden. Wenn es kein Installationssystem oder keine Standardkonvention gibt, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {Begründung erfüllt} [installation_standard_variables]
  • Das Projekt MUSS einen Weg für potenzielle Entwickler bereithalten, um schnell alle erforderlich Projektergebnisse und Support-Umgebungen zu installieren, um Änderungen vornehmen zu können, einschließlich der Tests und Test-Umgebung. Dies MUSS mit einer gängigen Methode durchgeführt werden können. {N/A Begründung} {Begründung erfüllt} [installation_development_quick]

Externe gepflegte Komponenten

  • Das Projekt MUSS externe Abhängigkeiten in computerlesbarer Form auflisten. {N/A Begründung} {URL erfüllt} [external_dependencies]
  • Projekte MÜSSEN ihre externen Abhängigkeiten (einschließlich Bequemlichkeitskopien) überwachen oder regelmäßig überprüfen, um bekannte Schwachstellen zu erkennen und ausnutzbare Schwachstellen zu beheben oder sie als unausweichlich zu verifizieren. {N/A Begründung} {Begründung erfüllt} [dependency_monitoring]
  • Das Projekt MUSS entweder:
    1. Es einfach machen, wiederverwendbare extern gepflegte Komponenten zu identifizieren und zu aktualisieren;oder
    2. Die Standardkomponenten des Systems oder der Programmiersprache verwenden.
    Dann, wenn eine Schwachstelle in einer wiederverwendeten Komponente gefunden wird, wird es einfach sein diese Komponente zu aktualisieren. {N/A Begründung} {Begründung erfüllt} [updateable_reused_components]
  • Das Projekt SOLLTE vermeiden veraltete oder obsolete Funktionen und APIs zu verwenden, für die FLOSS-Alternativen in der eingesetzten Technologie verfügbar sind (ihr "Technologie-Stack") und eine Supermajorität der Benutzer, die das Projekt unterstützt (so dass die Benutzer den Zugriff auf die Alternative haben ). {N/A Begründung} {Begründung erfüllt} [interfaces_current]

Automatisierte Test-Suite

  • Eine automatisierte Test-Suite MUSS bei jedem Check-In auf ein gemeinsames Repository für mindestens einen Zweig angewendet werden. Diese Test-Suite muss einen Bericht über Erfolg oder Misserfolg des Testes produzieren. {Begründung erfüllt} [automated_integration_testing]
  • Das Projekt MUSS Regressionstests zu einer automatisierten Test-Suite hinzufügen für mindestens 50% der, in den letzten sechs Monaten, gefixten Bugs. {N/A Begründung} {Begründung erfüllt} [regression_tests_added50]
  • Das Projekt MUSS automatisierte FLOSS-Test-Suite(s) haben, die mindestens 80% Aussage Berichterstattung haben, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache erfüllen kann. {N/A Begründung} {Begründung erfüllt} [test_statement_coverage80]

Neue Funktionalitätsüberprüfung

  • Das Projekt MUSS eine formale schriftliche Richtlinie dazu haben, wie wichtige neue Funktionalität hinzugefügt werden. Tests für die neue Funktionalität MÜSSEN zu einer automatisierten Test-Suite hinzugefügt werden. {N/A Begründung} {Begründung erfüllt} [test_policy_mandated]
  • Das Projekt MUSS in seinen dokumentierten Anweisungen für Änderungsvorschläge die Richtlinien enthalten, die Tests für große neue Funktionalität hinzugefügt werden sollen. {N/A Begründung} {Begründung erfüllt} [tests_documented_added]

Warnhinweise

  • Projekte MÜSSEN praktischerweise sehr streng mit Warnungen in der Projektsoftware sein. {N/A Begründung} {Begründung erfüllt} [warnings_strict]

Sicherheit

Wissen über sichere Entwicklungspraktiken

  • Das Projekt MUSS sichere Designprinzipien (von "know_secure_design"), soweit anwendbar, umsetzen. Wenn das Projekt keine Software produziert, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {Begründung erfüllt} [implement_secure_design]

Verwende grundlegend gute kryptographische Praktiken

  • Die Standard-Sicherheitsmechanismen innerhalb der Projektsoftware DÜRFEN NICHT von kryptographischen Algorithmen oder Modi mit bekannten schweren Mängeln abhängen (z.B. der SHA-1-Kryptographie-Hash-Algorithmus oder der CBC-Modus in SSH). {N/A erlaubt} {Begründung erfüllt} [crypto_weaknesses]
  • Das Projekt SOLLTE mehrere kryptographische Algorithmen unterstützen, so dass Benutzer schnell wechseln können, wenn eines defekt ist. Verbreitete symmetrische Schlüsselalgorithmen umfassen AES, Twofish und Serpent. Verbreitete kryptographische Hash-Algorithmus-Alternativen umfassen SHA-2 (einschließlich SHA-224, SHA-256, SHA-384 UND SHA-512) und SHA-3. {N/A erlaubt} {Begründung erfüllt} [crypto_algorithm_agility]
  • Das Projekt MUSS die Speicherung von Anmeldeinformationen (z.B. Passwörter und dynamische Token) und private kryptografische Schlüssel in Dateien, die von anderen Informationen getrennt sind (z.B. Konfigurationsdateien, Datenbanken und Protokolle), unterstützen und den Benutzern erlauben, sie ohne Code-Neukompilierung zu aktualisieren und zu ersetzen . Wenn das Projekt keine Anmeldeinformationen und private kryptographische Schlüssel verarbeitet, wählen Sie "nicht anwendbar" (N/A). {N/A erlaubt} {Begründung erfüllt} [crypto_credential_agility]
  • Die vom Projekt produzierte Software SOLLTE 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 SOLLTEN 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]
  • Wenn die Software, die durch das Projekt produziert wird, TLS unterstützt oder verwendet, SOLLTE sie mindestens TLS Version 1.2 verwenden. 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]
  • Die Software, die vom Projekt produziert wird, muss, wenn es TLS unterstützt, die TLS-Zertifikatsüberprüfung standardmäßig bei der Verwendung von TLS, einschließlich auf Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). {N/A erlaubt} {Begründung erfüllt} [crypto_certificate_verification]
  • Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, eine Zertifikatsüberprüfung durchführen, bevor HTTP-Header mit privaten Informationen (wie z.B. sichere Cookies) versendet werden. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). {N/A erlaubt} {Begründung erfüllt} [crypto_verification_private]

Sicheres Release

  • Das Projekt MUSS kryptographisch unterschriebene Releases der Projektergebnisse aufzeichnen, die für weit verbreitete Verwendung gedacht sind, und es MUSS ein dokumentierter Prozess sein, der den Benutzern/innen erklärt, wie sie die öffentlichen Signaturschlüssel erhalten und die Signatur(en) überprüfen können. Der private Schlüssel für diese Signatur(en) MUSS NICHT auf der Seite(n) verwendet werden, die öffentlich zugänglich sind. Wenn Releases nicht für eine weit verbreitete Verwendung bestimmt sind, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {Begründung erfüllt} [signed_releases]
  • Es wird empfohlen, dass in dem Versionskontrollsystem jeder wichtige Versions-Tag (ein Tag, der Teil eines Hauptrelease, eines kleineren Release, oder eines Fixes, öffentlich gemeldeten Schwachstellen, ist) kryptographisch signiert und verifizierbar ist, wie in Signed_releases. {Begründung erfüllt} [version_tags_signed]

Andere Sicherheitsissues

  • Die Projektergebnisse MÜSSEN alle Eingaben aus potenziell nicht vertrauenswürdigen Quellen überprüfen, um sicherzustellen, dass sie gültig sind (eine *Allowliste*) und ungültige Eingaben ablehnen, wenn überhaupt Einschränkungen für die Daten vorliegen. {N/A Begründung} {Begründung erfüllt} [input_validation]
  • Härtungsmechanismen SOLLTEN in der Software, die das Project entwickelt, verwendet werden, so dass Softwarefehler weniger wahrscheinlich zu Sicherheitslücken führen. {N/A Begründung} {Begründung erfüllt} [hardening]
  • Das Projekt MUSS einen "Assurance Case" bereithalten, der rechtfertigt, wie die Sicherheitsanforderungen erfüllt werden. Der Assurance Case muss Folgendes beinhalten: eine Beschreibung des Bedrohungsmodells, eine eindeutige Identifizierung von Vertrauensgrenzen, eine Beschreibung wie sichere Designprinzipien angewendet wurden, und eine Beschreibung wie die üblichen Implementierungssicherheitsschwächen beseitige wurden. {URL erfüllt} [assurance_case]

Analyse

Statische Codeanalyse

  • Das Projekt MUSS mindestens ein statisches Analyse-Tool mit Regeln oder Ansätzen verwenden, um nach bekannten Schwachstellen in der analysierten Sprache oder Umgebung zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium in der ausgewählten Sprache implementieren kann. {N/A Begründung} {Begründung erfüllt} [static_analysis_common_vulnerabilities]

Dynamische Codeanalyse

  • Wenn die Projektsoftware Software mit einer speicherunsicheren Sprache (z.B. C oder C ++) enthält, MUSS mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Applikationsscanner) routinemäßig in Kombination mit einem Mechanismus verwendet werden, welche Speichersicherheitsproblemen wie Puffer-Cach Überschreibe erkennen. Wenn das Projekt keine Software verwendet, die in einer speicherunsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). {N/A Begründung} {Begründung erfüllt} [dynamic_analysis_unsafe]

Gold

Grundlagen

Voraussetzungen

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]

Andere

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

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

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

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