flowpact

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


Dies sind die Baseline Niveau 1 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.

    Data-flow linter for GitHub Actions: finds inputs, secrets and matrix values that arrive empty across reusable workflows, local actions and matrix combinations, and grades the release impact of changes. CLI, GitHub Action, VS Code extension.

    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 23/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.

    The ciatlas GitHub organization that owns the authoritative repository (https://github.com/ciatlas/flowpact) requires two-factor authentication for every member and outside collaborator, and GitHub accepts passkeys for it. The only person with access is the maintainer, as org owner and repository admin.


    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.

    Organization members get only the base permission Read on ciatlas repositories, which on this public repository grants nothing beyond what anyone already has. Outside collaborators get no access until an owner invites them with a role chosen by hand. Today the maintainer is the only member and collaborator.


    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.

    The active 'main' ruleset (https://github.com/ciatlas/flowpact/blob/main/.github/rulesets/main.json, also shown at https://github.com/ciatlas/flowpact/rules) requires every change to main to arrive as a squash-merged pull request that passes the 'CI passed' and 'Conventional PR title' checks. It blocks force pushes and has no bypass actors, so not even an admin can push to main directly.


    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 same 'main' ruleset includes a deletion rule and has no bypass actors (https://github.com/ciatlas/flowpact/blob/main/.github/rulesets/main.json), so GitHub refuses to delete main for everyone. An admin would first have to take the separate, explicit step of editing or disabling the ruleset, and the weekly settings sync would revert that.


    Genug für ein Badge!

    Wenn eine CI/CD-Pipeline mit nicht vertrauenswürdigen Metadaten arbeitet, MÜSSEN diese 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.

    No workflow puts an expression directly into a shell script. Untrusted metadata such as the PR title, head ref and base ref reaches run steps only through environment variables used quoted, and the PR title is checked against a strict Conventional Commits regex (https://github.com/ciatlas/flowpact/blob/main/.github/workflows/pr-title.yml). CodeQL's Actions queries (security-extended) and flowpact's own lint scan every workflow on each PR.


    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.

    Workflows that run code from pull requests use the pull_request trigger, never pull_request_target or workflow_run. Fork PRs therefore get a read-only GITHUB_TOKEN and no secrets, and a first-time contributor's run needs maintainer approval. Credentials are used only in jobs that run from main (release.yml, the 'Apply settings' job in repo-settings.yml), and https://github.com/ciatlas/flowpact/blob/main/.github/workflows/dependency-bundle.yml builds Renovate's branch in a job with no secrets, giving the bot token only to a separate job that runs none of the branch'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-only. That covers the repository, issues and security advisories on https://github.com/ciatlas/flowpact and the docs on GitHub Pages at https://ciatlas.github.io/flowpact, where HTTPS is enforced, along with the npm, VS Code Marketplace and Open VSX pages. Plain-HTTP requests to each of them redirect to HTTPS.


    Genug für ein Badge!

    Wenn das Projekt eine URI als offiziellen Distributionskanal angibt, MUSS dieser Kanal durch kryptografisch authentifizierte Kanäle vor Adversary-in-the-Middle-Angriffen geschützt werden. [OSPS-BR-03.02]
    Vom Projekt verteilte Artefakte sollten über Kanäle verteilt werden, die Integrität und Authentizität gewährleisten. Die Verwendung von HTTPS für Downloads, signierten Releases oder die Verteilung über vertrauenswürdige Paketmanager sind allesamt akzeptable Methoden, um sich vor Adversary-in-the-Middle-Angriffen zu schützen.

    Every distribution channel is authenticated. npm is served over HTTPS, with trusted publishing and npm provenance. GitHub Releases are served over HTTPS and, from 0.10.0, are immutable and covered by GitHub's signed release attestation; the npm tarball, the Action archive and the .vsix each carry a Sigstore bundle and in-toto provenance. The Action is fetched through git tags over HTTPS, which only the release bot and admins can create. The VS Code Marketplace and Open VSX are served over HTTPS. https://ciatlas.github.io/flowpact/docs/security/#verify-a-release shows how to verify each artifact.


    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 on for the repository. It is kept in code at https://github.com/ciatlas/flowpact/blob/main/.github/security.json and re-applied weekly, so a push containing a recognized credential is rejected before it lands. Publishing uses OIDC trusted publishing and GitHub secrets, so no credential files are part of the workflow.


    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.

    The docs at https://ciatlas.github.io/flowpact cover installing and a first run (https://ciatlas.github.io/flowpact/docs/getting-started/), the CLI (https://ciatlas.github.io/flowpact/docs/cli/), the GitHub Action (https://ciatlas.github.io/flowpact/docs/action/), the editors (https://ciatlas.github.io/flowpact/docs/editors/), CI setup and configuration. The one dangerous capability, plugins that run repository code, is flagged with highlighted warning callouts on the Action and configuration pages and in https://ciatlas.github.io/flowpact/docs/security/#plugins-run-code.


    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.

    The README's 'Feedback and contributing' section (https://github.com/ciatlas/flowpact#feedback-and-contributing) sends bug reports to GitHub Issues, where a bug report form (https://github.com/ciatlas/flowpact/blob/main/.github/ISSUE_TEMPLATE/bug_report.yml) asks for what happened, a minimal reproduction, the flowpact version and how it was run. The CLI docs ask users to report internal errors with --debug output (https://ciatlas.github.io/flowpact/docs/cli/), and vulnerabilities go privately through SECURITY.md.


    Genug für ein Badge!

    Das Projekt MUSS 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.

    Proposed changes and usage problems are discussed publicly in GitHub Issues (https://github.com/ciatlas/flowpact/issues) and pull requests (https://github.com/ciatlas/flowpact/pulls). Anyone with a GitHub account can open or comment on them, and the README points users there.


    Genug für ein Badge!

    Die Projektdokumentation MUSS eine Erklärung des Beitragsprozesses enthalten oder deutlich angeben, dass öffentliche Beiträge nicht akzeptiert werden [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.

    https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md explains the contribution process: setup, repository layout, and pull requests that are squash-merged after the 'CI passed' and 'Conventional PR title' checks pass and a code owner approves. It also covers the test expectations, the commit message convention and how releases happen. The README links to it.


    Genug für ein Badge!

    Die Lizenz für den Quellcode MUSS der OSI Open Source Definition oder der FSF Free Software Definition entsprechen. [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.

    The MIT license for the repository contents is approved by the Open Source Initiative (OSI).


    Genug für ein Badge!

    Die Lizenz für die veröffentlichten Software-Assets MUSS der OSI Open Source Definition oder der FSF Free Software Definition entsprechen. [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.

    Every released asset is MIT-licensed and ships the license. The npm tarball and the action archive contain LICENSE, the .vsix declares MIT and lists LICENSE among its files, and the code they bundle is under MIT, ISC, BSD-3-Clause or BlueOak-1.0.0, all OSI-approved. Each asset lists its bundled packages and their license texts in THIRD_PARTY_LICENSES.txt and in a CycloneDX SBOM attached to the release (https://github.com/ciatlas/flowpact/releases/tag/v0.12.2).


    Genug für ein Badge!

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

    The MIT license is in a top-level LICENSE file at https://github.com/ciatlas/flowpact/blob/main/LICENSE. The project's other repository, the workflow model ciatlas/core, has its own MIT LICENSE at https://github.com/ciatlas/core/blob/main/LICENSE.


    Genug für ein Badge!

    Die Lizenz für die veröffentlichten Software-Assets MUSS 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.

    Every released asset carries the license. The npm package flowpact includes LICENSE (packages/cli/package.json files), the VS Code extension .vsix includes LICENSE.txt, and the GitHub Action archive flowpact-action-X.Y.Z.tar.gz includes LICENSE next to action.yml; see https://github.com/ciatlas/flowpact/releases. The Action at a release tag and GitHub's source archives contain the repository's LICENSE.


    Genug für ein Badge!

    Das Quellcode-Repository des Projekts MUSS 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.

    The source is in a public GitHub repository at the stable URL https://github.com/ciatlas/flowpact, with no mirrors. It moved there from the maintainer's personal account in 0.12.0, and GitHub redirects the old URL.


    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.

    The public Git history at https://github.com/ciatlas/flowpact/commits/main records every change with its author and date. Each change arrives as a squash-merged pull request whose author is the commit author and whose individual commits stay visible on the PR. The main ruleset blocks force pushes and branch deletion for everyone, so history cannot be rewritten (https://github.com/ciatlas/flowpact/blob/main/.github/rulesets/main.json).


    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.

    Direct dependencies are declared in the package.json of each workspace package (for example https://github.com/ciatlas/flowpact/blob/main/packages/lint/package.json) and locked in https://github.com/ciatlas/flowpact/blob/main/pnpm-lock.yaml. The lockfile also pins the git dependency @ciatlas/core to a commit. Each release also ships a CycloneDX SBOM of what is bundled.


    Genug für ein Badge!

    Projekte mit mehreren Repositorys MÜSSEN eine Liste der Codebasen dokumentieren, die Teil des Projekts sind. [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 project has two repositories. The 'The workflow model: @ciatlas/core' section of https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#the-workflow-model-ciatlascore documents the second one, https://github.com/ciatlas/core: what it is (the model flowpact's checks are built on), that it has its own tests and releases, and that the CLI, Action and extension bundle it from a release tag. The repository layout table in the same file lists the monorepo's own packages.


    Nicht genug für ein Badge.

    Das Versionskontrollsystem DARF 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.

    The repository commits one generated file, the GitHub Action's bundle packages/action/dist/index.js, because GitHub runs a JavaScript action from the ref that uses: names. A required CI job rebuilds it from source on every pull request and fails on any difference (https://github.com/ciatlas/flowpact/blob/main/.github/workflows/ci.yml, job action-dist), and the release archive is built reproducibly; it remains a generated artifact in version control.


    Genug für ein Badge!

    Das Versionskontrollsystem DARF 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.

    The only binary files in the repository are PNG images: brand assets, docs screenshots and the extension icon. This control explicitly allows those. No executables, libraries, archives or other compiled binaries are committed, and the GitHub Action bundle is plain-text JavaScript that CI checks against a fresh build (https://github.com/ciatlas/flowpact/blob/main/.github/workflows/ci.yml).


    Genug für ein Badge!

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

    https://github.com/ciatlas/flowpact/blob/main/SECURITY.md#reporting-a-vulnerability says how to reach the project about security issues: privately through GitHub's private vulnerability reporting (https://github.com/ciatlas/flowpact/security/advisories/new), which is enabled and goes to the maintainers. The README and https://ciatlas.github.io/flowpact/docs/security link to it. ciatlas/core has its own SECURITY.md with the same channel.



Sie können Tools und KI-Systeme nutzen, um Änderungen über eine einfache URL vorzuschlagen, z. B. https://www.bestpractices.dev/de/projects/15403/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 Ruman Kazi und die OpenSSF Best Practices Badge-Mitwirkenden als Urheber.

Projekt-Badge-Eintrag im Besitz von: Ruman Kazi.
Eintrag erstellt: 2026-10-12 07:45:57 UTC, zuletzt aktualisiert: 2026-10-12 10:15:42 UTC. Letztes erreichtes Badge: 2026-10-12 07:46:35 UTC.