kotiko

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 15259 ist baseline-1 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/15259/baseline)](https://www.bestpractices.dev/projects/15259)
oder indem Sie Folgendes in Ihr HTML einbetten:
<a href="https://www.bestpractices.dev/projects/15259"><img src="https://www.bestpractices.dev/projects/15259/baseline"></a>


Dies sind die Baseline Niveau 2 Kriterien. Dies sind Kriterienversion v2026.08.28.

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

        

 Grundlagen

  • Allgemein

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

    Learn languages while you browse: Kotiko swaps words on the pages you read for the words you're learning, in any language. Local-first browser extension with an optional self-hosted server.

    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 17/19 ●

  • Steuerelemente


    Genug für ein Badge!

    Wenn eine CI/CD-Aufgabe ohne angegebene Berechtigungen ausgeführt wird, MUSS das CI/CD-System die Berechtigungen der Aufgabe standardmäßig auf die niedrigsten in der Pipeline gewährten Berechtigungen setzen. [OSPS-AC-04.01]
    Konfigurieren Sie die Einstellungen des Projekts so, dass neuen Pipelines standardmäßig die niedrigsten verfügbaren Berechtigungen zugewiesen werden, wobei zusätzliche Berechtigungen nur bei Bedarf für bestimmte Aufgaben gewährt werden.

    The repository's and organization's default GITHUB_TOKEN permission is read-only, and every workflow also declares top-level permissions (contents: read, or none).


    Genug für ein Badge!

    Wenn ein offizieller Release erstellt wird, MUSS diesem Release eine eindeutige Versionskennung zugewiesen werden. [OSPS-BR-02.01]
    Weisen Sie jedem vom Projekt erstellten Release eine eindeutige Versionskennung zu und folgen Sie dabei einer konsistenten Namenskonvention oder einem Nummerierungsschema. Beispiele sind SemVer, CalVer oder Git-Commit-ID.

    Each release has its own SemVer version (0.1.0, 0.2.0, next 1.0.0), kept identical in the server, the extension manifest and the release manifest; CI fails if they differ. [version_unique]


    Genug für ein Badge!

    Wenn ein offizieller Release erstellt wird, MUSS dieser Release ein beschreibendes Protokoll funktionaler und sicherheitsrelevanter Änderungen enthalten. [OSPS-BR-04.01]
    Stellen Sie sicher, dass alle Releases ein beschreibendes Änderungsprotokoll enthalten. Es wird empfohlen sicherzustellen, dass das Änderungsprotokoll von Menschen lesbar ist und Details über Commit-Nachrichten hinaus enthält, wie z.B. Beschreibungen der Sicherheitsauswirkung oder Relevanz für verschiedene Anwendungsfälle. Um Maschinenlesbarkeit zu gewährleisten, platzieren Sie den Inhalt unter einer Markdown-Überschrift wie "## Changelog".

    Non-trivial release notes file in repository: https://github.com/ScriptKittyOS/kotiko/blob/main/CHANGELOG.md. [release_notes]


    Genug für ein Badge!

    Wenn eine Build- und Release-Pipeline Abhängigkeiten einbindet, MUSS sie standardisierte Tools verwenden, wo verfügbar. [OSPS-BR-05.01]
    Verwenden Sie ein gängiges Tool für Ihr Ökosystem, wie z.B. Paketmanager oder Abhängigkeits-Management-Tools, um Abhängigkeiten zur Build-Zeit einzubinden. Dies kann die Verwendung einer Abhängigkeitsdatei, Lock-Datei oder Manifest umfassen, um die erforderlichen Abhängigkeiten zu spezifizieren, die dann vom Build-System eingezogen werden.

    Dependencies are declared and locked in each ecosystem's standard files: server/mix.exs with server/mix.lock (Hex), package.json with package-lock.json (npm, development tools only; the extension ships no npm code), and site/package.json with its lock file for the docs site. External services are listed in docs/ARCHITECTURE.md section 6, and the release workflow attaches a CycloneDX SBOM of the server to each release. https://github.com/ScriptKittyOS/kotiko/blob/main/server/mix.exs [external_dependencies]


    Nicht genug für ein Badge.

    Wenn ein offizieller Release erstellt wird, MUSS dieser Release signiert sein oder in einem signierten Manifest erfasst werden, das die kryptographischen Hashes jedes Assets enthält. [OSPS-BR-06.01]
    Signieren Sie alle freigegebenen Software-Assets zur Build-Zeit mit einer kryptographischen Signatur oder Attestierungen, wie z.B. GPG- oder PGP-Signatur, Sigstore-Signaturen, SLSA-Provenance oder SLSA-VSAs. Fügen Sie die kryptographischen Hashes jedes Assets in eine signierte Manifest- oder Metadaten-Datei ein.

    No release has been published yet. The pipeline for the first one (v1.0.0) is in place: the release manager signs the tag with their own SSH or GPG key; the workflow refuses a tag not signed by a key listed in .github/allowed_signers on main, builds the zips reproducibly, and publishes them with SHA256SUMS, a CycloneDX SBOM and Sigstore build-provenance attestations (keyless, so no signing key is stored on GitHub). How users verify: https://github.com/ScriptKittyOS/kotiko/blob/main/docs/verify.md [signed_releases]


    Genug für ein Badge!

    Wenn das Projekt ein Release erstellt hat, MUSS die Projektdokumentation eine Beschreibung enthalten, wie das Projekt seine Abhängigkeiten auswählt, bezieht und verfolgt. [OSPS-DO-06.01]
    Es wird empfohlen, diese Informationen zusammen mit der technischen und Design-Dokumentation des Projekts auf einer öffentlich zugänglichen Ressource wie dem Quellcode-Repository, der Projektwebsite oder einem anderen Kanal zu veröffentlichen.

    docs/ARCHITECTURE.md section 6 lists the runtime services and libraries, how they are obtained (Hex and npm with committed lockfiles that pin exact versions; Actions pinned by SHA) and how they are tracked (weekly Dependabot updates for Mix, npm and Actions, mix hex.audit and mix deps.audit on every pull request, an SBOM with each release). Selection rule: the extension ships no npm runtime code and the server keeps a small set of libraries. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/ARCHITECTURE.md#6-external-dependencies


    Genug für ein Badge!

    Die Projektdokumentation MUSS Anweisungen enthalten, wie die Software gebaut wird, einschließlich erforderlicher Bibliotheken, Frameworks, SDKs und Abhängigkeiten. [OSPS-DO-07.01]
    Es wird empfohlen, diese Informationen zusammen mit der Beiträgerdokumentation des Projekts zu veröffentlichen, z. B. in CONTRIBUTING.md oder anderen Entwickleraufgabendokumentationen. Dies kann auch mithilfe von Makefile-Zielen oder anderen Automatisierungsskripten dokumentiert werden.

    CONTRIBUTING.md Setup installs everything needed to change and test Kotiko with each ecosystem's standard tools: mix deps.get and mix test for the server, npm ci and npm test for the extension, and npx playwright install chromium for the end-to-end tests. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#setup [installation_development_quick]


    Genug für ein Badge!

    Die Projektdokumentation MUSS eine Liste der Projektmitglieder mit Zugriff auf sensible Ressourcen enthalten. [OSPS-GV-01.01]
    Dokumentieren Sie Projektteilnehmer und ihre Rollen durch Artefakte wie members.md, governance.md, maintainers.md oder eine ähnliche Datei im Quellcode-Repository des Projekts. Dies kann so einfach sein wie die Aufnahme von Namen oder Account-Handles in einer Liste von Maintainern, oder komplexer sein, abhängig von der Governance des Projekts.

    MAINTAINERS.md lists everyone with access to sensitive resources (admin on the repository, release tags, the release environment and organization ownership): currently the lead maintainer, Ayla Croft (@HackTuah), and states that the kotiko-maintainers team holds exactly the active maintainers. https://github.com/ScriptKittyOS/kotiko/blob/main/MAINTAINERS.md


    Genug für ein Badge!

    Die Projektdokumentation MUSS Beschreibungen der Rollen und Verantwortlichkeiten der Projektmitglieder enthalten. [OSPS-GV-01.02]
    Dokumentieren Sie Projektteilnehmer und ihre Rollen durch Artefakte wie members.md, governance.md, maintainers.md oder ähnliche Dateien im Quellcode-Repository des Projekts.

    GOVERNANCE.md defines each role and the tasks it must perform: lead maintainer, maintainer (reviews and merges, weekly triage with a first response within 7 days, approves releases, enforces the code of conduct), release manager, security response lead, steward, locale reviewer and contributor (https://github.com/ScriptKittyOS/kotiko/blob/main/GOVERNANCE.md#roles). MAINTAINERS.md says who holds which role today: one person holds every role except steward, and the roles not yet filled are listed (https://github.com/ScriptKittyOS/kotiko/blob/main/MAINTAINERS.md). The kotiko-maintainers team, which owns every file through .github/CODEOWNERS, holds exactly the active maintainers. [roles_responsibilities]


    Genug für ein Badge!

    Die Projektdokumentation MUSS einen Leitfaden für Code-Mitwirkende enthalten, der die Anforderungen für akzeptable Beiträge beschreibt. [OSPS-GV-03.02]
    Erweitern Sie die Inhalte von CONTRIBUTING.md oder CONTRIBUTING/ in der Projektdokumentation, um die Anforderungen für akzeptable Beiträge zu beschreiben, einschließlich Codierungsstandards, Testanforderungen und Einreichungsrichtlinien für Code-Beitragende. Es wird empfohlen, dass dieser Leitfaden die verbindliche Quelle sowohl für Beitragende als auch für Genehmiger ist.

    CONTRIBUTING.md lists the requirements: rules that protect users, tests with every change and a regression test with every fix, Conventional Commits, SPDX headers, and the coding standards in docs/CODING_STANDARDS.md. https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md [contribution_requirements]


    Nicht genug für ein Badge.

    Das Versionskontrollsystem MUSS bei jedem Commit von allen Code-Mitwirkenden verlangen zu bestätigen, dass sie rechtlich befugt sind, die zugehörigen Beiträge zu leisten. [OSPS-LE-01.01]
    Fügen Sie ein DCO in das Repository des Projekts ein, das Code-Beitragende dazu verpflichtet zu bestätigen, dass sie rechtlich berechtigt sind, die zugehörigen Beiträge bei jedem Commit zu leisten. Verwenden Sie eine Statusüberprüfung, um sicherzustellen, dass die Bestätigung erfolgt ist. Ein CLA erfüllt diese Anforderung ebenfalls. Einige Versionskontrollsysteme, wie GitHub, können dies in den Nutzungsbedingungen der Plattform enthalten.

    The project has not adopted a DCO or a CLA. Contributions are accepted under Apache-2.0 section 5 (inbound = outbound), as CONTRIBUTING.md states (https://github.com/ScriptKittyOS/kotiko/blob/main/CONTRIBUTING.md#licensing), with no Signed-off-by requirement: for a volunteer project with no plans to relicense, a failing sign-off check on a first pull request costs more than it adds. Adopting the DCO will be reconsidered if an organization asks to contribute substantial code, and before applying for gold. [dco]


    Genug für ein Badge!

    Wenn ein Commit in den primären Branch erfolgt, MÜSSEN alle automatisierten Statusüberprüfungen für Commits bestanden werden oder manuell umgangen werden. [OSPS-QA-03.01]
    Konfigurieren Sie das Versionskontrollsystem des Projekts so, dass alle automatisierten Statusüberprüfungen bestanden werden müssen oder eine manuelle Bestätigung erforderlich ist, bevor ein Commit in den primären Branch zusammengeführt werden kann. Es wird empfohlen, dass optionale Statusüberprüfungen NICHT als Bestehen-oder-Durchfallen-Anforderung konfiguriert werden, die Genehmiger versucht sein könnten zu umgehen.

    GitHub Actions runs on every push to main and every pull request: the server tests on the oldest and newest supported Elixir, the extension's unit, DOM and background suites, the shared-spec checks, and Playwright end-to-end tests against the real server. Each job reports pass or fail on the pull request, and main accepts only pull requests whose 8 required checks pass. https://github.com/ScriptKittyOS/kotiko/actions/workflows/ci.yml [automated_integration_testing]


    Genug für ein Badge!

    Bevor ein Commit akzeptiert wird, MÜSSEN die CI/CD-Pipelines des Projekts mindestens eine automatisierte Test-Suite ausführen, um sicherzustellen, dass die Änderungen den Erwartungen entsprechen. [OSPS-QA-06.01]
    Automatisierte Tests sollten vor jedem Merge in den primären Branch ausgeführt werden. Die Test-Suite sollte in einer CI/CD-Pipeline ausgeführt werden und die Ergebnisse sollten für alle Beitragenden sichtbar sein. Die Test-Suite sollte in einer konsistenten Umgebung ausgeführt werden und so ausgeführt werden, dass Beitragende die Tests lokal ausführen können. Beispiele für Test-Suites sind Unit-Tests, Integrationstests und End-to-End-Tests.

    GitHub Actions runs on every push to main and every pull request: the server tests on the oldest and newest supported Elixir, the extension's unit, DOM and background suites, the shared-spec checks, and Playwright end-to-end tests against the real server. Each job reports pass or fail on the pull request, and main accepts only pull requests whose 8 required checks pass. https://github.com/ScriptKittyOS/kotiko/actions/workflows/ci.yml [automated_integration_testing]


    Genug für ein Badge!

    Wenn das Projekt eine Veröffentlichung vorgenommen hat, MUSS die Projektdokumentation Design-Dokumentation enthalten, die alle Aktionen und Akteure innerhalb des Systems demonstriert. [OSPS-SA-01.01]
    Fügen Sie Designs in die Projektdokumentation ein, die die Aktionen und Akteure erklären. Akteure umfassen jedes Subsystem oder jede Entität, die ein anderes Segment im System beeinflussen kann. Stellen Sie sicher, dass dies für neue Funktionen oder Breaking Changes aktualisiert wird.

    docs/ARCHITECTURE.md describes the code on main: the two parts (the browser extension and the optional Elixir server) and their components, the shared spec, where data is kept, the main flows, trust boundaries and external dependencies. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/ARCHITECTURE.md [documentation_architecture]


    Genug für ein Badge!

    Wenn das Projekt eine Veröffentlichung vorgenommen hat, MUSS die Projektdokumentation Beschreibungen aller externen Software-Schnittstellen der veröffentlichten Software-Assets enthalten. [OSPS-SA-02.01]
    Dokumentieren Sie alle Software-Schnittstellen (APIs) der veröffentlichten Software-Assets und erklären Sie, wie Benutzer mit der Software interagieren können und welche Daten erwartet oder produziert werden. Stellen Sie sicher, dass dies für neue Funktionen oder Breaking Changes aktualisiert wird.

    The server's HTTP API (every route, field, limit, status code and error) and every setting are documented in https://github.com/ScriptKittyOS/kotiko/tree/main/docs/reference ; a test fails when a route or setting is missing from them. The Telegram bot's commands and the extension's screens are described in the user guides in site/src/content/docs; the word record and the export file are specified as JSON schemas in spec/. [documentation_interface]


    Genug für ein Badge!

    Wenn das Projekt eine Veröffentlichung vorgenommen hat, MUSS das Projekt eine Sicherheitsbewertung durchführen, um die wahrscheinlichsten und folgenschwersten potenziellen Sicherheitsprobleme zu verstehen, die innerhalb der Software auftreten könnten. [OSPS-SA-03.01]
    Die Durchführung einer Sicherheitsbewertung informiert sowohl Projektmitglieder als auch nachgelagerte Verbraucher darüber, dass das Projekt versteht, welche Probleme innerhalb der Software auftreten könnten. Das Verständnis darüber, welche Bedrohungen realisiert werden könnten, hilft dem Projekt, Risiken zu verwalten und anzugehen. Diese Informationen sind für nachgelagerte Verbraucher nützlich, um den Sicherheitssachverstand und die Praktiken des Projekts zu demonstrieren. Stellen Sie sicher, dass dies für neue Funktionen oder Breaking Changes aktualisiert wird.

    docs/security/assurance-case.md: the top claim and its sub-claims mapped to arguments and evidence, the threat model (assets, attackers and what each can reach), the trust boundaries (diagram and table), how each secure design principle is applied, the CWE Top 25 and OWASP Top 10 weaknesses that apply and how each is countered, every input and how it is validated, and the residual risks. https://github.com/ScriptKittyOS/kotiko/blob/main/docs/security/assurance-case.md [assurance_case]


    Genug für ein Badge!

    Die Projektdokumentation MUSS eine Richtlinie für die koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) mit einem klaren Zeitrahmen für die Reaktion enthalten. [OSPS-VM-01.01]
    Erstellen Sie eine SECURITY.md-Datei im Stammverzeichnis, die die Richtlinie des Projekts für koordinierte Offenlegung von Schwachstellen beschreibt. Fügen Sie eine Methode zur Meldung von Schwachstellen hinzu. Setzen Sie Erwartungen dafür, wie das Projekt reagieren und gemeldete Probleme angehen wird.

    https://github.com/ScriptKittyOS/kotiko/blob/main/SECURITY.md [vulnerability_report_process]


    Genug für ein Badge!

    Die Projektdokumentation MUSS eine Möglichkeit zur privaten Meldung von Schwachstellen direkt an die Sicherheitskontakte des Projekts bereitstellen. [OSPS-VM-03.01]
    Bieten Sie Sicherheitsforschern eine Möglichkeit, Schwachstellen privat an das Projekt zu melden. Dies kann eine dedizierte E-Mail-Adresse, ein Webformular, spezialisierte VCS-Tools, E-Mail-Adressen für Sicherheitskontakte oder andere Methoden sein.

    Report privately through GitHub's private vulnerability reporting (https://github.com/ScriptKittyOS/kotiko/security/advisories/new) or by email to security@scriptkittyos.com, as SECURITY.md says: https://github.com/ScriptKittyOS/kotiko/blob/main/SECURITY.md [vulnerability_report_private]


    Genug für ein Badge!

    Die Projektdokumentation MUSS Daten über entdeckte Schwachstellen öffentlich veröffentlichen. [OSPS-VM-04.01]
    Bereitstellen von Informationen über bekannte Schwachstellen in einem vorhersehbaren öffentlichen Kanal, wie z.B. einem CVE-Eintrag, Blogbeitrag oder einem anderen Medium. Soweit möglich sollten diese Informationen betroffene Version(en) enthalten, wie ein Verbraucher feststellen kann, ob er betroffen ist, und Anweisungen zur Schadensbegrenzung oder Behebung.

    Vulnerabilities are published as GitHub Security Advisories (with a CVE for medium and above) together with the fixing release, whose notes have a Security section with the advisory, CVE, severity and affected versions. The one security fix so far (0.2.0, an authentication bypass found internally) is named in the CHANGELOG. https://github.com/ScriptKittyOS/kotiko/security/advisories



Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/15259/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Wie das geht, erfahren Sie in unserem Automatisierungsvorschlagssystem. 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 Ayla Croft und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Ayla Croft.
Eintrag erstellt: 2026-10-06 18:38:00 UTC, zuletzt aktualisiert: 2026-10-06 22:13:39 UTC. Letztes erreichtes Badge: 2026-10-06 19:36:22 UTC.