flowpact

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 15403 - baseline-2 Вот как встроить базовый значок:
Вы можете показать статус базового значка, вставив это в ваш файл markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/15403/baseline)](https://www.bestpractices.dev/projects/15403)
или вставив это в ваш HTML:
<a href="https://www.bestpractices.dev/projects/15403"><img src="https://www.bestpractices.dev/projects/15403/baseline"></a>


Это критерии Базового Уровня 1. Это критерии версии v2026.08.28.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

    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.

    Используйте формат выражения лицензии SPDX; примеры включают «Apache-2.0», «BSD-2-Clause», «BSD-3-Clause», «GPL-2.0+», «LGPL-3.0+», «MIT» и «(BSD-2-Clause OR Ruby)».
    Если используется более одного языка, перечислите их через запятую (пробелы необязательны), и отсортируйте их от наиболее до наименее используемого. Если список длинный, пожалуйста, перечислите по крайней мере три наиболее распространенных. Если языка нет (например, это проект только для документации или только для тестирования), используйте один символ «-» (минус). Для каждого языка используйте общепринятую капитализацию названия, например «JavaScript».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

 Элементы управления 23/24 ●

  • Элементы управления


    Достаточно для значка!

    Когда пользователь пытается прочитать или изменить чувствительный ресурс в авторитетном репозитории проекта, система ДОЛЖНА требовать от пользователя прохождения процесса многофакторной аутентификации. [OSPS-AC-01.01]
    Обеспечьте многофакторную аутентификацию для системы контроля версий проекта, требуя от соавторов предоставления второй формы аутентификации при доступе к конфиденциальным данным или изменении настроек репозитория. Для этой меры приемлемы passkeys (ключи доступа).

    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.


    Достаточно для значка!

    При добавлении нового соавтора система контроля версий ДОЛЖНА требовать ручного назначения прав доступа или по умолчанию ограничивать права доступа соавтора до минимально доступных привилегий. [OSPS-AC-02.01]
    Большинство публичных систем контроля версий настроены таким образом. Убедитесь, что система контроля версий проекта всегда назначает минимально доступные права доступа соавторам по умолчанию при добавлении, предоставляя дополнительные права доступа только при необходимости.

    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.


    Достаточно для значка!

    При попытке прямого коммита в основную ветку проекта механизм принудительного исполнения ДОЛЖЕН предотвращать применение изменения. [OSPS-AC-03.01]
    Если VCS централизована, установите защиту ветки на основную ветку в VCS проекта. В качестве альтернативы используйте децентрализованный подход, как в ядре Linux, где изменения сначала предлагаются в другом репозитории, а слияние изменений в основной репозиторий требует специального отдельного действия.

    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.


    Достаточно для значка!

    Когда предпринимается попытка удалить основную ветку проекта, система контроля версий ОБЯЗАНА рассматривать это как деликатное действие и требовать явного подтверждения намерения. [OSPS-AC-03.02]
    Установите защиту ветки на основную ветку в системе контроля версий проекта для предотвращения удаления.

    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.


    Достаточно для значка!

    Когда конвейер CI/CD оперирует ненадежными метаданными, эти параметры ОБЯЗАНЫ быть очищены и проверены перед использованием в конвейере. [OSPS-BR-01.01]
    Конвейеры CI/CD должны санировать (заключать в кавычки, экранировать или завершаться при ожидаемых значениях) все входные метаданные, соответствующие недоверенным источникам. Это включает такие данные, как имена веток, сообщения коммитов, теги, заголовки запросов на слияние и информацию об авторах.

    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.


    Достаточно для значка!

    Когда конвейер CI/CD работает с недоверенными снимками кода, он ДОЛЖЕН запрещать доступ к привилегированным учётным данным и ресурсам CI/CD. [OSPS-BR-01.03]
    Конвейеры CI/CD должны изолировать недоверенные снимки кода от привилегированных учётных данных и ресурсов. В частности, проекты должны следить за тем, чтобы рабочие процессы, выполняющие сборку или запуск кода до его проверки коллаборатором, не имели доступа к учётным данным CI/CD.

    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.


    Достаточно для значка!

    Когда проект указывает URI как официальный канал проекта, этот URI ОБЯЗАН передаваться исключительно с использованием зашифрованных каналов. [OSPS-BR-03.01]
    Настройте веб-сайты и системы контроля версий проекта на использование зашифрованных каналов, таких как SSH или HTTPS для передачи данных. Убедитесь, что все инструменты и домены, на которые ссылается документация проекта, доступны только через зашифрованные каналы.

    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.


    Достаточно для значка!

    Если проект указывает URI в качестве официального канала распространения, этот канал ОБЯЗАН быть защищен от атак «злоумышленник в канале связи» (adversary-in-the-middle) с использованием криптографически аутентифицированных каналов. [OSPS-BR-03.02]
    Артефакты, распространяемые проектом, следует распространять через каналы, обеспечивающие целостность и подлинность. Использование HTTPS для загрузок, подписанных релизов или распространения через доверенные менеджеры пакетов — все это приемлемые методы защиты от атак «злоумышленник в канале связи».

    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.


    Достаточно для значка!

    Проект ОБЯЗАН предотвращать непреднамеренное сохранение незашифрованных конфиденциальных данных, таких как секреты и учетные данные, в системе контроля версий. [OSPS-BR-07.01]
    Настройте .gitignore или эквивалент для исключения файлов, которые могут содержать конфиденциальную информацию. Используйте pre-commit хуки и автоматизированные инструменты сканирования для обнаружения и предотвращения включения конфиденциальных данных в коммиты.

    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.


    Достаточно для значка!

    Когда проект сделал релиз, документация проекта ОБЯЗАНА включать руководства пользователя для всего базового функционала. [OSPS-DO-01.01]
    Создайте руководства пользователя или документацию для всего базового функционала проекта, объясняющие, как устанавливать, настраивать и использовать возможности проекта. Если есть какие-либо известные опасные или деструктивные действия, включите хорошо заметные предупреждения.

    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.


    Достаточно для значка!

    Когда проект сделал релиз, документация проекта ОБЯЗАНА включать руководство по сообщению о дефектах. [OSPS-DO-02.01]
    Рекомендуется, чтобы проекты использовали трекер задач по умолчанию в их системе контроля версий. Если используется внешний источник, убедитесь, что документация проекта и руководство по внесению вклада четко и заметно объясняют, как использовать систему сообщения об ошибках. Рекомендуется, чтобы документация проекта также устанавливала ожидания относительно того, как дефекты будут сортироваться и решаться.

    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.


    Достаточно для значка!

    Проект ОБЯЗАН иметь один или несколько механизмов для публичного обсуждения предлагаемых изменений и препятствий использования. [OSPS-GV-02.01]
    Создайте один или несколько механизмов для публичных обсуждений в рамках проекта, таких как списки рассылки, мгновенные сообщения или трекеры задач, чтобы облегчить открытое общение и обратную связь.

    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.


    Достаточно для значка!

    Документация проекта ОБЯЗАНА включать объяснение процесса внесения вклада или четко указывать, что публичные вклады не принимаются [OSPS-GV-03.01]
    Создайте файл CONTRIBUTING.md или директорию CONTRIBUTING/ для описания процесса внесения вклада, включая шаги для отправки изменений и взаимодействия с сопровождающими проекта.

    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.


    Достаточно для значка!

    Лицензия исходного кода ОБЯЗАНА соответствовать Определению Открытого ПО OSI или Определению Свободного Программного Обеспечения FSF. [OSPS-LE-02.01]
    Добавьте файл LICENSE в репозиторий проекта с лицензией, которая является одобренной лицензией Open Source Initiative (OSI), или свободной лицензией, одобренной Фондом свободного программного обеспечения (FSF). Примеры таких лицензий включают MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) и GNU General Public License (GPL). Выпуск в публичное достояние соответствует этому контролю, если нет других ограничений, таких как патенты.

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


    Достаточно для значка!

    Лицензия выпускаемых программных активов ОБЯЗАНА соответствовать Определению Открытого ПО OSI или Определению Свободного Программного Обеспечения FSF. [OSPS-LE-02.02]
    Если с выпущенными программными активами включена другая лицензия, убедитесь, что это одобренная лицензия Open Source Initiative (OSI) или свободная лицензия, одобренная Free Software Foundation (FSF). Примеры таких лицензий включают MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) и GNU General Public License (GPL). Обратите внимание, что лицензия для выпущенных программных активов может отличаться от лицензии для исходного кода.

    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).


    Достаточно для значка!

    Лицензия исходного кода ОБЯЗАНА поддерживаться в файле LICENSE, файле COPYING, каталоге LICENSES/ или каталоге LICENSE/ соответствующего репозитория. [OSPS-LE-03.01]
    Включите лицензию исходного кода проекта в файл LICENSE, файл COPYING, каталог LICENSES/ или каталог LICENSE/ проекта, чтобы обеспечить наглядность и ясность условий лицензирования. Имя файла МОЖЕТ иметь расширение. Если у проекта несколько репозиториев, убедитесь, что каждый репозиторий включает файл лицензии.

    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.


    Достаточно для значка!

    Лицензия выпускаемых программных активов ОБЯЗАНА быть включена в выпускаемый исходный код или в файл LICENSE, файл COPYING либо каталог LICENSE/ рядом с соответствующими активами релиза. [OSPS-LE-03.02]
    Включите лицензию выпущенных программных активов проекта в выпущенный исходный код или в файл LICENSE, файл COPYING или директорию LICENSE/ рядом с соответствующими выпущенными активами, чтобы обеспечить видимость и ясность условий лицензирования. Имя файла МОЖЕТ иметь расширение. Если у проекта несколько репозиториев, убедитесь, что каждый репозиторий включает файл лицензии.

    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.


    Достаточно для значка!

    Репозиторий исходного кода проекта ОБЯЗАН быть общедоступным для чтения по статическому URL. [OSPS-QA-01.01]
    Используйте общую систему контроля версий (VCS), такую как GitHub, GitLab или Bitbucket. Убедитесь, что репозиторий доступен для публичного чтения. Избегайте дублирования или зеркалирования репозиториев, если только хорошо видимая документация не разъясняет первичный источник. Избегайте частых изменений репозитория, которые могут повлиять на URL репозитория. Убедитесь, что репозиторий публичный.

    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.


    Достаточно для значка!

    Система контроля версий ОБЯЗАНА содержать общедоступную запись всех внесенных изменений, кто внес изменения и когда были внесены изменения. [OSPS-QA-01.02]
    Используйте общую VCS, такую как GitHub, GitLab или Bitbucket, для поддержания публично доступной истории коммитов. Избегайте сжатия или перезаписи коммитов таким образом, чтобы это скрывало автора любых коммитов.

    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).


    Достаточно для значка!

    Когда система управления пакетами это поддерживает, репозиторий исходного кода ОБЯЗАН содержать список зависимостей, учитывающий прямые языковые зависимости. [OSPS-QA-02.01]
    Это может быть в виде файла менеджера пакетов или файла языковых зависимостей, перечисляющего все прямые зависимости, такие как package.json, Gemfile или 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.


    Достаточно для значка!

    Проекты с несколькими репозиториями ОБЯЗАНЫ документировать список кодовых баз, являющихся частью проекта. [OSPS-QA-04.01]
    Документируйте любые дополнительные репозитории кода подпроектов, создаваемые проектом и компилируемые в выпуск. Эта документация должна включать статус и назначение соответствующей кодовой базы.

    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.


    Недостаточно для значка.

    Система управления версиями НЕ ДОЛЖНА содержать сгенерированные исполняемые артефакты. [OSPS-QA-05.01]
    Удалите сгенерированные исполняемые артефакты из системы контроля версий проекта. Рекомендуется, чтобы в любом сценарии, где сгенерированный исполняемый артефакт является критическим для процесса, такого как тестирование, он должен вместо этого генерироваться во время сборки или храниться отдельно и загружаться во время определенного хорошо задокументированного этапа конвейера.

    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.


    Достаточно для значка!

    Система управления версиями НЕ ДОЛЖНА содержать нерецензируемые двоичные артефакты. [OSPS-QA-05.02]
    Не добавляйте никакие непроверяемые бинарные артефакты в систему контроля версий проекта. Это включает исполняемые бинарные файлы приложений, файлы библиотек и аналогичные артефакты. Это не включает такие активы, как графические изображения, звуковые или музыкальные файлы и подобный контент, обычно хранящийся в бинарном формате.

    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).


    Достаточно для значка!

    Документация проекта ОБЯЗАНА содержать контакты по вопросам безопасности. [OSPS-VM-02.01]
    Создайте файл security.md (или с аналогичным именем), который содержит контакты по вопросам безопасности для проекта.

    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.



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/15403/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Ruman Kazi и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Ruman Kazi.
2026-10-12 07:45:57 UTC, последнее изменение сделано 2026-10-12 10:15:42 UTC. Последний раз условия для получения значка были выполнены 2026-10-12 07:46:35 UTC.