BadgeApp

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 Baseline-Badge-Status auf Ihrer Projektseite! Der Baseline-Badge-Status sieht so aus:

So betten Sie das Baseline-Badge ein:

Sie können Ihren Baseline-Badge-Status anzeigen, indem Sie Folgendes in Ihre Markdown-Datei einbetten:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/1/baseline)](https://www.bestpractices.dev/projects/1)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/1"><img src="https://www.bestpractices.dev/projects/1/baseline"></a>

Dies sind die Baseline Niveau 1 Kriterien.

Baseline Series: Baseline Niveau 1 Baseline Niveau 2 Baseline Niveau 3

Grundlagen

Identifizierung

Was ist der von Menschen lesbare Name des Projekts?
Hinweis: Andere Projekte können den selben Namen benutzen.

Was ist eine Kurzbeschreibung des Projektes?

BadgeApp is the web application that allows developers to provide information about their project and (hopefully) get an Open Source Security Foundation (OpenSSF) Best Practices badge. This project was originally known as the Core Infrastructure Initiative (CII) best practices badge project.

The Open Source Security Foundation (OpenSSF) is managed by The Linux Foundation. The OpenSSF Best Practices badge online application (aka the BadgeApp) enables developers to quickly determine whether they are following best practices and to receive a badge they can display on GitHub and other locations. The application and its criteria are an open source project to which developers can contribute.

You can see the program running, and use it to try to get a badge, by visiting: https://bestpractices.coreinfrastructure.org/

The BadgeApp is written in Ruby on Rails and Javascript.

See the development site on GitHub for more about how we secure this application.

Note that the BadgeApp gets its own badge!

Wie lautet die URL für das Projekt (vollständig)?
https://github.com/coreinfrastructure/best-practices-badge

Was ist die URL für das Versionskontroll-Repository (es kann mit der Projekt-URL identisch sein)?
https://github.com/coreinfrastructure/best-practices-badge

Steuerelemente 24/24 ●

Steuerelemente

Criterion [OSPS-AC-01.01]
Erfüllt

Unerfüllt

N/A

?

Wenn ein Benutzer versucht, eine sensible Ressource im autoritativen Repository des Projekts zu lesen oder zu ändern, MUSS das System vom Benutzer verlangen, einen Multi-Faktor-Authentifizierungsprozess abzuschließen. ^{[OSPS-AC-01.01]}
Erzwingen Sie Multi-Faktor-Authentifizierung für das Versionskontrollsystem des Projekts und verlangen Sie von Mitarbeitern, eine zweite Form der Authentifizierung bereitzustellen, wenn sie auf sensible Daten zugreifen oder Repository-Einstellungen ändern. Passkeys sind für diese Kontrolle akzeptabel.

The authoritative repository is hosted on GitHub, which requires multi-factor authentication to modify sensitive resources or to read sensitive resources like keys. GitHub allows anyone to read publicly available resources (such as the source code), and that's fine.

Criterion [OSPS-AC-02.01]
Erfüllt

Unerfüllt

N/A

?

Wenn ein neuer Mitarbeiter hinzugefügt wird, MUSS das Versionskontrollsystem eine manuelle Berechtigungszuweisung erfordern oder die Mitarbeiterberechtigungen standardmäßig auf die niedrigsten verfügbaren Privilegien beschränken. ^{[OSPS-AC-02.01]}
Die meisten öffentlichen Versionskontrollsysteme sind auf diese Weise konfiguriert. Stellen Sie sicher, dass das Versionskontrollsystem des Projekts Mitarbeitern beim Hinzufügen immer standardmäßig die niedrigsten verfügbaren Berechtigungen zuweist und zusätzliche Berechtigungen nur bei Bedarf gewährt.

New collaborators are only given lowest available privileges. We generally don't add many collaborators who can directly edit the software, but instead ask people to fork the repository and create pull requests from them, which gives them no privileges by default.

Criterion [OSPS-AC-03.01]
Erfüllt

Unerfüllt

N/A

?

Wenn ein direktes Commit auf den primären Branch des Projekts versucht wird, MUSS ein Durchsetzungsmechanismus verhindern, dass die Änderung angewendet wird. ^{[OSPS-AC-03.01]}
Wenn das VCS zentralisiert ist, setzen Sie Branch-Schutz auf den primären Branch im VCS des Projekts. Alternativ verwenden Sie einen dezentralisierten Ansatz, wie beim Linux-Kernel, wo Änderungen zuerst in einem anderen Repository vorgeschlagen werden und das Zusammenführen von Änderungen in das primäre Repository einen spezifischen separaten Akt erfordert.

Our main branch is protected (it's named main).

Criterion [OSPS-AC-03.02]
Erfüllt

Unerfüllt

N/A

?

Wenn versucht wird, den primären Branch des Projekts zu löschen, MUSS das Versionskontrollsystem dies als sensible Aktivität behandeln und eine explizite Bestätigung der Absicht erfordern. ^{[OSPS-AC-03.02]}
Setzen Sie Branch-Schutz auf den primären Branch im Versionskontrollsystem des Projekts, um das Löschen zu verhindern.

GitHub requires this.

Criterion [OSPS-BR-01.01]
Erfüllt

Unerfüllt

N/A

?

Wenn eine CI/CD-Pipeline einen Eingabeparameter akzeptiert, MUSS dieser Parameter vor der Verwendung in der Pipeline bereinigt und validiert werden. ^{[OSPS-BR-01.01]}

Other the branch name we don't use input parameters. See below in OSPS-BR-01.02 for branch names.

Criterion [OSPS-BR-01.02]
Erfüllt

Unerfüllt

N/A

?

Wenn eine CI/CD-Pipeline einen Branch-Namen in ihrer Funktionalität verwendet, MUSS dieser Namenswert vor der Verwendung in der Pipeline bereinigt und validiert werden. ^{[OSPS-BR-01.02]}

Branch names are checked before they are used if they are used. Note that the scorecard workflow doesn't use the branch name, so it doesn't check it easier (we can't add that check because the scorecard workflow is only allowed to do certain things).

Criterion [OSPS-BR-03.01]
Erfüllt

Unerfüllt

N/A

?

Wenn das Projekt eine URI als offiziellen Projektkanal auflistet, MUSS diese URI ausschließlich über verschlüsselte Kanäle bereitgestellt werden. ^{[OSPS-BR-03.01]}
Konfigurieren Sie die Websites und Versionskontrollsysteme des Projekts so, dass sie verschlüsselte Kanäle wie SSH oder HTTPS für die Datenübertragung verwenden. Stellen Sie sicher, dass alle Tools und Domains, die in der Projektdokumentation referenziert werden, nur über verschlüsselte Kanäle zugänglich sind.

https: is always used.

Criterion [OSPS-BR-03.02]
Erfüllt

Unerfüllt

N/A

?

Wenn das Projekt eine URI als offiziellen Vertriebskanal auflistet, MUSS diese URI ausschließlich über verschlüsselte Kanäle bereitgestellt werden. ^{[OSPS-BR-03.02]}
Konfigurieren Sie die Release-Pipeline des Projekts so, dass Daten nur von Websites, API-Antworten und anderen Diensten abgerufen werden, die verschlüsselte Kanäle wie SSH oder HTTPS für die Datenübertragung verwenden.

https: is always used.

Criterion [OSPS-BR-07.01]
Erfüllt

Unerfüllt

N/A

?

Das Projekt MUSS die unbeabsichtigte Speicherung unverschlüsselter sensibler Daten, wie Geheimnisse und Anmeldeinformationen, im Versionskontrollsystem verhindern. ^{[OSPS-BR-07.01]}
Konfigurieren Sie .gitignore oder Äquivalent, um Dateien auszuschließen, die sensible Informationen enthalten könnten. Verwenden Sie Pre-Commit-Hooks und automatisierte Scan-Tools, um die Einbeziehung sensibler Daten in Commits zu erkennen und zu verhindern.

We enable secret scanning to prevent this.

Criterion [OSPS-DO-01.01]
Erfüllt

Unerfüllt

N/A

?

Wenn das Projekt ein Release erstellt hat, MUSS die Projektdokumentation Benutzerhandbücher für alle grundlegenden Funktionen enthalten. ^{[OSPS-DO-01.01]}
Erstellen Sie Benutzerhandbücher oder Dokumentationen für alle grundlegenden Funktionen des Projekts, die erklären, wie das Projekt installiert, konfiguriert und verwendet wird. Wenn es bekannte gefährliche oder destruktive Aktionen gibt, fügen Sie gut sichtbare Warnungen hinzu.

The project doesn't create "releases" for many to download and install. Its primary purpose is to be a specific website's implementation. Therefore, it must be completely usable without any "user guides" for end users (who spend relatively little time on the site). We do have guides for setting up and running the site, primarily to enable others to install it so they can add features to it as proposals.

Criterion [OSPS-DO-02.01]
Erfüllt

Unerfüllt

N/A

?

Wenn das Projekt ein Release erstellt hat, MUSS die Projektdokumentation eine Anleitung zum Melden von Fehlern enthalten. ^{[OSPS-DO-02.01]}
Es wird empfohlen, dass Projekte ihren Standard-Issue-Tracker des VCS verwenden. Wenn eine externe Quelle verwendet wird, stellen Sie sicher, dass die Projektdokumentation und der Beitragsleitfaden klar und sichtbar erklären, wie das Meldesystem verwendet wird. Es wird empfohlen, dass die Projektdokumentation auch Erwartungen daran setzt, wie Fehler priorisiert und behoben werden.

See SECURITY.md for how to report defects.

Criterion [OSPS-GV-02.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS das Projekt einen oder mehrere Mechanismen für öffentliche Diskussionen über vorgeschlagene Änderungen und Nutzungshindernisse haben. ^{[OSPS-GV-02.01]}
Richten Sie einen oder mehrere Mechanismen für öffentliche Diskussionen innerhalb des Projekts ein, wie Mailinglisten, Instant Messaging oder Issue-Tracker, um offene Kommunikation und Feedback zu ermöglichen.

GitHub provides issues and pull requests. We also use a mailing list.

Criterion [OSPS-GV-03.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS die Projektdokumentation eine Erklärung des Beitragsprozesses enthalten. ^{[OSPS-GV-03.01]}
Erstellen Sie eine CONTRIBUTING.md oder ein CONTRIBUTING/ Verzeichnis, um den Beitragsprozess zu skizzieren, einschließlich der Schritte zum Einreichen von Änderungen und zur Interaktion mit den Projektbetreuern.

See CONTRIBUTING.md.

Criterion [OSPS-LE-02.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS die Lizenz für den Quellcode die OSI Open Source Definition oder die FSF Free Software Definition erfüllen. ^{[OSPS-LE-02.01]}
Fügen Sie eine LICENSE-Datei zum Repository des Projekts mit einer Lizenz hinzu, die eine genehmigte Lizenz der Open Source Initiative (OSI) oder eine freie Lizenz ist, wie sie von der Free Software Foundation (FSF) genehmigt wurde. Beispiele für solche Lizenzen sind MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL). Eine Veröffentlichung in die Public Domain erfüllt diese Kontrolle, wenn es keine anderen Belastungen wie Patente gibt.

We use the MIT license, which meets the OSI Open Source Definition and the Free Software Definition.

Criterion [OSPS-LE-02.02]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS die Lizenz für die veröffentlichten Software-Assets die OSI Open Source Definition oder die FSF Free Software Definition erfüllen. ^{[OSPS-LE-02.02]}
Wenn eine andere Lizenz mit veröffentlichten Software-Assets enthalten ist, stellen Sie sicher, dass es eine genehmigte Lizenz der Open Source Initiative (OSI) oder eine freie Lizenz ist, wie sie von der Free Software Foundation (FSF) genehmigt wurde. Beispiele für solche Lizenzen sind MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL). Beachten Sie, dass die Lizenz für die veröffentlichten Software-Assets von der des Quellcodes abweichen kann.

We use the MIT license, which meets the OSI Open Source Definition and the Free Software Definition.

Criterion [OSPS-LE-03.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS die Lizenz für den Quellcode in der LICENSE-Datei, COPYING-Datei oder im LICENSE/ Verzeichnis des entsprechenden Repositorys gepflegt werden. ^{[OSPS-LE-03.01]}
Fügen Sie die Quellcode-Lizenz des Projekts in die LICENSE-Datei, COPYING-Datei oder das LICENSE/ Verzeichnis des Projekts ein, um Sichtbarkeit und Klarheit über die Lizenzbedingungen zu schaffen. Der Dateiname KANN eine Erweiterung haben. Wenn das Projekt mehrere Repositorys hat, stellen Sie sicher, dass jedes Repository die Lizenzdatei enthält.

See file LICENSE for the source code.

Criterion [OSPS-LE-03.02]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS die Lizenz für die veröffentlichten Software-Assets im veröffentlichten Quellcode oder in einer LICENSE-Datei, COPYING-Datei oder einem LICENSE/ Verzeichnis neben den entsprechenden Release-Assets enthalten sein. ^{[OSPS-LE-03.02]}
Fügen Sie die Lizenz für die veröffentlichten Software-Assets des Projekts in den veröffentlichten Quellcode oder in eine LICENSE-Datei, COPYING-Datei oder ein LICENSE/ Verzeichnis neben den entsprechenden Release-Assets ein, um Sichtbarkeit und Klarheit über die Lizenzbedingungen zu schaffen. Der Dateiname KANN eine Erweiterung haben. Wenn das Projekt mehrere Repositorys hat, stellen Sie sicher, dass jedes Repository die Lizenzdatei enthält.

See file LICENSE for the source code.

Criterion [OSPS-QA-01.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS das Quellcode-Repository des Projekts unter einer statischen URL öffentlich lesbar sein. ^{[OSPS-QA-01.01]}
Verwenden Sie ein gängiges VCS wie GitHub, GitLab oder Bitbucket. Stellen Sie sicher, dass das Repository öffentlich lesbar ist. Vermeiden Sie Duplizierung oder Spiegelung von Repositorys, es sei denn, eine gut sichtbare Dokumentation verdeutlicht die primäre Quelle. Vermeiden Sie häufige Änderungen am Repository, die sich auf die Repository-URL auswirken würden. Stellen Sie sicher, dass das Repository öffentlich ist.

Criterion [OSPS-QA-01.02]
Erfüllt

Unerfüllt

N/A

?

Das Versionskontrollsystem MUSS eine öffentlich lesbare Aufzeichnung aller vorgenommenen Änderungen, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden, enthalten. ^{[OSPS-QA-01.02]}
Verwenden Sie ein gängiges VCS wie GitHub, GitLab oder Bitbucket, um eine öffentlich lesbare Commit-Historie zu pflegen. Vermeiden Sie das Zusammenfassen oder Umschreiben von Commits auf eine Weise, die den Autor von Commits verschleiern würde.

Criterion [OSPS-QA-02.01]
Erfüllt

Unerfüllt

N/A

?

Wenn das Paketverwaltungssystem dies unterstützt, MUSS das Quellcode-Repository eine Abhängigkeitsliste enthalten, die die direkten Sprachabhängigkeiten berücksichtigt. ^{[OSPS-QA-02.01]}
Dies kann in Form einer Paketverwaltungs- oder Sprachabhängigkeitsdatei erfolgen, die alle direkten Abhängigkeiten auflistet, wie package.json, Gemfile oder go.mod.

Criterion [OSPS-QA-04.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, MUSS die Projektdokumentation eine Liste aller Codebasen enthalten, die als Unterprojekte betrachtet werden. ^{[OSPS-QA-04.01]}
Dokumentieren Sie alle zusätzlichen Unterprojekt-Code-Repositorys, die vom Projekt produziert und in ein Release kompiliert werden. Diese Dokumentation sollte den Status und die Absicht der jeweiligen Codebasis enthalten.

Criterion [OSPS-QA-05.01]
Erfüllt

Unerfüllt

N/A

?

Während das Projekt aktiv ist, DARF das Versionskontrollsystem KEINE generierten ausführbaren Artefakte enthalten. ^{[OSPS-QA-05.01]}
Entfernen Sie generierte ausführbare Artefakte aus dem Versionskontrollsystem des Projekts. Es wird empfohlen, dass in jedem Szenario, in dem ein generiertes ausführbares Artefakt für einen Prozess wie Tests kritisch erscheint, es stattdessen zur Build-Zeit generiert oder separat gespeichert und während eines spezifischen gut dokumentierten Pipeline-Schritts abgerufen werden sollte.

Criterion [OSPS-QA-05.02]
Erfüllt

Unerfüllt

N/A

?

Während aktiv, DARF das Versionskontrollsystem KEINE nicht überprüfbaren Binärartefakte enthalten. ^{[OSPS-QA-05.02]}
Fügen Sie keine nicht überprüfbaren Binärartefakte zum Versionskontrollsystem des Projekts hinzu. Dies umfasst ausführbare Anwendungsbinärdateien, Bibliotheksdateien und ähnliche Artefakte. Dies schließt keine Assets wie Grafikbilder, Ton- oder Musikdateien und ähnliche Inhalte ein, die typischerweise in einem Binärformat gespeichert werden.

Criterion [OSPS-VM-02.01]
Erfüllt

Unerfüllt

N/A

?

Während aktiv, MUSS die Projektdokumentation Sicherheitskontakte enthalten. ^{[OSPS-VM-02.01]}
Erstellen Sie eine security.md (oder ähnlich benannte) Datei, die Sicherheitskontakte für das Projekt enthält.

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

BadgeApp

Grundlagen

Identifizierung

Steuerelemente 24/24 ●

Steuerelemente