bark

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:

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/7096/badge)](https://www.bestpractices.dev/projects/7096)

oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/7096"><img src="https://www.bestpractices.dev/projects/7096/badge"></a>

Dies sind die Kriterien das Level

. Sie können auch die Kriterien für die Level

oder

sehen.

Analyse 2/2 ●

Dynamische Codeanalyse

Criterion [dynamic_analysis]
Erfüllt

Unerfüllt

N/A

?

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

Automated test suite run on every check and push to GitHub with code coverage reported at https://app.codecov.io/github/merliseclyde/bark?displayType=tree with 96% coverage

Criterion [dynamic_analysis_enable_assertions]
Erfüllt

Unerfüllt

N/A

?

Das Projekt SOLLTE viele Laufzeit-Assertionen in der Projektsoftware enthalten und diese Assertionen während der dynamischen Analyse überprüfen. ^{[dynamic_analysis_enable_assertions]}
This criterion does not suggest enabling assertions during production; that is entirely up to the project and its users to decide. This criterion's focus is instead to improve fault detection during dynamic analysis before deployment. Enabling assertions in production use is completely different from enabling assertions during dynamic analysis (such as testing). In some cases enabling assertions in production use is extremely unwise (especially in high-integrity components). There are many arguments against enabling assertions in production, e.g., libraries should not crash callers, their presence may cause rejection by app stores, and/or activating an assertion in production may expose private data such as private keys. Beware that in many Linux distributions NDEBUG is not defined, so C/C++ assert() will by default be enabled for production in those environments. It may be important to use a different assertion mechanism or defining NDEBUG for production in those environments.

Automated test suite run on every check and push to GitHub with code coverage reported at https://app.codecov.io/github/merliseclyde/bark?displayType=tree

Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Open Source Security Foundation unter den Nutzungsbedingungen. Es ist allen erlaubt, die Daten zu teilen und anzupassen, müssen aber einen angemessene Hinweis auf den Urheber geben. Bitte geben Sie als Urheber Merlise Clyde und die OpenSSF Best Practices Badge Mitwirkenden an.

bark

Grundlagen 5/5 ●

Identifizierung

Voraussetzungen

Projektüberwachung

Andere

Verbesserungs-/Nacharbeits-Kontrolle 4/4 ●

Öffentliches Versionskontroll-Source-Repository

Qualität 7/7 ●

Programmierstil

Produktivsystem

Automatisierte Test-Suite

Sicherheit 5/5 ●

Verwende grundlegend gute kryptographische Praktiken

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

Andere Sicherheitsissues

Analyse 2/2 ●

Dynamische Codeanalyse