.github

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: Baseline-Badge-Level für Projekt 14058 ist baseline-2 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/14058/baseline)](https://www.bestpractices.dev/projects/14058)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/14058"><img src="https://www.bestpractices.dev/projects/14058/baseline"></a>


Dies sind die Baseline Niveau 1 Kriterien. Dies sind Kriterienversion v2026.02.19.

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

        

 Grundlagen

  • Allgemein

    Hinweis: Andere Projekte können den selben Namen benutzen.

    Shared workflows, community health files and org profile for Monumental Archive

    Bitte verwenden Sie das SPDX-License-Expression-Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)". Geben sie nicht die einfachen oder doppelten Anführungszeichen mit an.
    Wenn es mehr als eine Programmiersprache gibt, listen Sie sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortieren Sie sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z. B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT-Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.

 Steuerelemente 24/24 ●

  • Steuerelemente


    Genug für ein Badge!

    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.

    Two-factor authentication is required organisation-wide: GitHub reports two_factor_requirement_enabled for the monumental-archive organisation, covering repository write access and private vulnerability reports alike.


    Genug für ein Badge!

    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.

    Collaborator permissions are assigned explicitly, never inherited by default. The repository baseline script sets the default repository permission to the lowest privilege and review routing goes through CODEOWNERS to the owners team; the settings are code, applied and drift-checked by settings/repo-baseline.sh. https://github.com/monumental-archive/.github/tree/main/settings


    Genug für ein Badge!

    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.

    An organisation-level ruleset blocks direct pushes to main: every change must arrive as a pull request and pass required status checks. The rules and their rationale are recorded in docs/rulesets.md and the Monday audit re-checks them for drift. https://github.com/monumental-archive/.github/blob/main/docs/rulesets.md


    Genug für ein Badge!

    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.

    The organisation ruleset restricts branch deletion on the primary branch, so deleting main is refused rather than confirmed away. Recorded in docs/rulesets.md. https://github.com/monumental-archive/.github/blob/main/docs/rulesets.md


    Genug für ein Badge!

    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]
    CI/CD-Pipelines sollten alle Metadaten-Eingaben, die nicht vertrauenswürdigen Quellen entsprechen, bereinigen (in Anführungszeichen setzen, escapen oder bei erwarteten Werten beenden). Dazu gehören Daten wie Branch-Namen, Commit-Nachrichten, Tags, Titel von Pull Requests und Autoreninformationen.

    Untrusted workflow metadata is validated before use: the shared workflows accept inputs against allowlists (the artifact classes: set, the pinned publish stub shape checked by lint:release-stub), and zizmor fails the gate on template-injection patterns where untrusted context would reach a shell.


    Genug für ein Badge!

    Wenn eine CI/CD-Pipeline mit nicht vertrauenswürdigen Code-Snapshots arbeitet, MUSS sie den Zugriff auf privilegierte CI/CD-Anmeldeinformationen und -Ressourcen verhindern. [OSPS-BR-01.03]
    CI/CD-Pipelines sollten nicht vertrauenswürdige Code-Snapshots von privilegierten Anmeldeinformationen und Ressourcen isolieren. Insbesondere sollten Projekte sorgfältig darauf achten, dass Workflows, die Code vor der Überprüfung durch einen Mitarbeiter erstellen oder ausführen, keinen Zugriff auf CI/CD-Anmeldeinformationen haben.

    This is the project's central architectural rule, not an incidental setting: no workflow that runs caller-supplied code may declare id-token: write. lint:capability-boundary enforces it in the gate and fails the build if a workflow_call workflow ever acquires the privileged identity, so a certificate bearing this repository's identity can never be minted by a job executing a caller's code.


    Genug für ein Badge!

    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.

    Every official channel is HTTPS: the repository, releases, documentation and issue tracker are all served by GitHub over TLS, and no plaintext URI appears in the tree.


    Genug für ein Badge!

    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.

    Distribution is over HTTPS and authenticated beyond transport: releases carry Sigstore evidence bundles and GitHub artifact attestations, and every consumed tool is pinned with per-platform checksums in mise.lock, so a substituted artifact fails verification rather than merely a certificate check.


    Genug für ein Badge!

    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.

    Secret scanning with push protection is enforced by the organisation security configuration, so an unencrypted credential is blocked at push time; trivy's secret rules also run in the gate. The architecture removes most of the risk at source: publishing is keyless via OIDC and trusted publishing, so there are few long-lived secrets to leak.


    Genug für ein Badge!

    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.

    README.md documents basic usage for consumers (adopt the gate in about six lines, copy scaffold/, run mise run ci), and docs/runbook.md is the full operating manual for wiring a repository in and for recovery. https://github.com/monumental-archive/.github/blob/main/docs/runbook.md


    Genug für ein Badge!

    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.

    SUPPORT.md and the repository's issue forms document how to report a defect, and SECURITY.md documents the separate private path for vulnerabilities. https://github.com/monumental-archive/.github/blob/main/SUPPORT.md


    Genug für ein Badge!

    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 Issues and pull requests are open for public discussion of proposed changes and usage obstacles; both are searchable and individually addressable by URL. https://github.com/monumental-archive/.github/issues


    Genug für ein Badge!

    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.

    CONTRIBUTING.md explains the contribution process: open an issue first for anything large, pull requests for small self-contained fixes, Conventional Commits, DCO sign-off, a green mise run ci, squash merge. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md


    Genug für ein Badge!

    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.

    0BSD — OSI-approved and FSF-free. https://github.com/monumental-archive/.github/blob/main/LICENSE


    Genug für ein Badge!

    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.

    The released assets carry the same 0BSD licence as the source; there is no separate licence for releases. https://github.com/monumental-archive/.github/blob/main/LICENSE


    Genug für ein Badge!

    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.

    LICENSE at the repository root and the full text in LICENSES/0BSD.txt, the REUSE-standard location. api.reuse.software independently reports the project compliant. https://github.com/monumental-archive/.github/blob/main/LICENSE


    Genug für ein Badge!

    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.

    Released assets ship from this repository, which carries LICENSE at its root and LICENSES/0BSD.txt alongside, with per-file attribution recorded in REUSE.toml. https://github.com/monumental-archive/.github/blob/main/LICENSE


    Genug für ein Badge!

    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.

    Publicly readable at a static URL. https://github.com/monumental-archive/.github


    Genug für ein Badge!

    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.

    Git records what changed, who changed it and when, for every revision, and the history is public. Beyond that, each revision carries a signed source-provenance attestation, so the record is independently verifiable rather than merely readable.


    Genug für ein Badge!

    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.

    mise/config.toml lists every direct tool dependency at an exact version, and mise.lock records per-platform checksums for each. Renovate reads the same file natively. https://github.com/monumental-archive/.github/blob/main/mise/config.toml


    Genug für ein Badge!

    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.

    The organisation's repositories and their status are documented rather than assumed: docs/migration-playbook.md records which codebases join the governance and how, and the scheduled audit enumerates the live repository population from the GitHub API rather than from a hand-kept list. https://github.com/monumental-archive/.github/blob/main/docs/migration-playbook.md


    Genug für ein Badge!

    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.

    No generated executable artifacts are committed. The repository contains shell tasks, workflow YAML, configuration and documentation; tools arrive at runtime through mise from pinned, checksummed downloads rather than being vendored.


    Genug für ein Badge!

    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.

    No unreviewable binary artifacts are committed — every tracked file is text and reviewable in a diff.


    Genug für ein Badge!

    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.

    SECURITY.md names the security contact and the reporting channel: private vulnerability reporting through the repository's Security tab, with a 14-day acknowledgement commitment. https://github.com/monumental-archive/.github/blob/main/SECURITY.md



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 Carl Allen und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Carl Allen.
Eintrag erstellt: 2026-08-13 07:47:41 UTC, zuletzt aktualisiert: 2026-08-13 19:08:33 UTC. Letztes erreichtes Badge: 2026-08-13 08:01:08 UTC.