flowpact

遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法;如果规范或假设是错误的,即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是,遵循最佳做法可以帮助改善项目的成果。例如,一些做法可以在发布之前进行多人评估,这可以帮助您找到其他难以找到的技术漏洞,并帮助建立信任,并希望不同公司的开发人员之间进行重复的交互。要获得徽章,必须满足所有“必须”和“禁止”的条款,满足所有“应该”条款或有合适的理由,和所有“建议”条款必须满足或未满足(至少希望考虑)。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目,请在项目页面上显示您的基准徽章状态!基准徽章状态如下所示: 项目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>


这些是基准等级2的标准。 这些是标准版本 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”。
    通用平台枚举(CPE)是用于信息技术系统,软件和软件包的结构化命名方案。在报告漏洞时,它可用于多个系统和数据库。

 控制 19/19 ●

  • 控制


    当执行CI/CD任务且未指定权限时,CI/CD系统必须将任务的权限默认为管道中授予的最低权限。 [OSPS-AC-04.01]
    配置项目的设置,默认情况下为新管道分配最低可用权限,仅在特定任务需要时才授予额外权限。

    The GITHUB_TOKEN default is read-only, the lowest setting, for both the ciatlas organization and the repository, and workflows cannot approve pull requests, so a job that sets no permissions gets read access only. Every workflow also sets its own top-level permissions: contents: read in most, {} in pr-title.yml, read-all in scorecard.yml, and in docs.yml contents: read with pages: write and id-token: write for the Pages deployment. Other write scopes are granted only on the jobs that use them (https://github.com/ciatlas/flowpact/tree/main/.github/workflows).



    当创建正式发布时,该发布必须分配一个唯一的版本标识符。 [OSPS-BR-02.01]
    为项目生成的每个发布分配一个唯一的版本标识符,遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交id。

    Every release gets a unique Semantic Versioning number and a vX.Y.Z tag, which release-please computes from Conventional Commit titles (https://github.com/ciatlas/flowpact/blob/main/release-please-config.json, https://github.com/ciatlas/flowpact/blob/main/CHANGELOG.md). npm never accepts a version twice, releases are immutable since 0.10.0, and a ruleset lets only the release bot and admins create, move or delete v* tags.



    当创建正式发布时,该发布必须包含功能和安全修改的描述性日志。 [OSPS-BR-04.01]
    确保所有发布都包含描述性的变更日志。建议确保变更日志是人类可读的,并且包含超出提交消息的详细信息,例如安全影响的描述或与不同用例的相关性。为确保机器可读性,请将内容放在markdown标题下,例如"## Changelog"。

    Every release has a descriptive changelog, both on its GitHub release page (https://github.com/ciatlas/flowpact/releases) and in https://github.com/ciatlas/flowpact/blob/main/CHANGELOG.md. It groups changes into breaking changes with upgrade steps, features, bug fixes and performance, written from user-facing PR titles. Security-relevant changes are listed too, for example 0.9.0's 'harden 0.9.0 before its release: flag values, plugins, report paths and release assets' and 0.12.1's bounded walking of linked directories.



    当构建和发布管道摄取依赖项时,它必须使用标准化工具(如果可用)。 [OSPS-BR-05.01]
    为您的生态系统使用通用工具,例如包管理器或依赖项管理工具,以在构建时摄取依赖项。这可能包括使用依赖项文件、锁文件或清单来指定所需的依赖项,然后由构建系统拉入。

    The build and release pipelines take dependencies through pnpm, the project's standard package manager. The version is pinned in package.json's packageManager, and every CI and release job runs pnpm install --frozen-lockfile against the committed lockfile (https://github.com/ciatlas/flowpact/blob/main/.github/workflows/release.yml, https://github.com/ciatlas/flowpact/blob/main/.github/workflows/ci.yml). Workflow actions are pinned to commit SHAs and updated by Renovate.



    当创建正式发布时,该发布必须进行签名或在包含每个资产加密哈希值的签名清单中进行说明。 [OSPS-BR-06.01]
    在构建时使用加密签名或证明(例如GPG或PGP签名、Sigstore签名、SLSA来源或SLSA VSA)对所有发布的软件资产进行签名。在签名清单或元数据文件中包含每个资产的加密哈希值。

    The npm tarball, the Action archive and the .vsix each have a Sigstore-signed SLSA build provenance attestation from GitHub Actions, attached as .sigstore.json and .intoto.jsonl, and each CycloneDX SBOM is attested against its artifact. Since 0.10.0 every release is also an immutable GitHub release whose signed release attestation lists the SHA-256 of every attached file (gh release verify), and the npm package has npm provenance. See https://github.com/ciatlas/flowpact/blob/main/SECURITY.md#verifying-releases and https://ciatlas.github.io/flowpact/docs/security/#verify-a-release.



    当项目发布版本后,项目文档必须包含项目如何选择、获取和跟踪其依赖项的描述。 [OSPS-DO-06.01]
    建议在可公开查看的资源(如源代码存储库、项目网站或其他渠道)上与项目的技术和设计文档一起发布此信息。

    https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#dependencies describes how dependencies are selected (reviewed in a pull request, bundled into every artifact), obtained (pnpm with a frozen lockfile, a two-day minimum release age, install scripts only for allowlisted packages, @ciatlas/core from a release tag, actions pinned to commit SHAs) and tracked (Renovate, OSV vulnerability alerts, and an SBOM and license notices in every release).



    项目文档必须包含如何构建软件的说明,包括所需的库、框架、SDK 和依赖项。 [OSPS-DO-07.01]
    建议将此信息与项目的贡献者文档一起发布,例如在 CONTRIBUTING.md 或其他开发者任务文档中。也可以使用 Makefile 目标或其他自动化脚本来记录此信息。

    https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#setup lists what a build needs: Node.js 22 or later, and pnpm, pinned in package.json and enabled with corepack enable. It also gives the commands. pnpm install fetches every dependency from the lockfile, including the workflow model @ciatlas/core from its GitHub release tag (explained in the next section). pnpm build bundles the CLI and the GitHub Action.



    项目文档必须包含有权访问敏感资源的项目成员列表。 [OSPS-GV-01.01]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。这可以简单到在维护者列表中包含姓名或账户句柄,或者根据项目的治理更复杂。

    https://github.com/ciatlas/flowpact/blob/main/MAINTAINERS.md#access-to-sensitive-resources lists everyone and everything with access to the project's sensitive resources: the GitHub organization and repositories, the two GitHub Apps and their permissions, the release bot's credentials, and the npm, VS Code Marketplace, Azure and Open VSX accounts that publish releases.



    项目文档必须包含对项目成员角色和职责的描述 [OSPS-GV-01.02]
    通过项目源代码存储库中的members.md、governance.md、maintainers.md或类似文件等工件记录项目参与者及其角色。

    https://github.com/ciatlas/flowpact/blob/main/MAINTAINERS.md#roles-and-responsibilities describes the roles (maintainer, contributors, the release bot, Renovate) and what each is responsible for, and how access is given and taken away when people join or leave.



    项目文档必须包含面向代码贡献者的指南,其中包含可接受贡献的要求。 [OSPS-GV-03.02]
    扩展项目文档中的CONTRIBUTING.md或CONTRIBUTING/的内容,以概述可接受的贡献要求,包括编码标准、测试要求和代码贡献者的提交指南。建议将该指南作为贡献者和批准者的真实来源。

    https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#pull-requests sets the requirements for an acceptable contribution. They are a Conventional Commits PR title and the required CI checks: Biome lint, typecheck, tests on Node 22 and 24, line coverage of at least 80% overall and 90% in packages/lint, and fallow code health. A behaviour change needs tests, and a bug fix needs a test that fails without it. Docs and the committed action bundle must be regenerated, and a code owner must approve.



    版本控制系统必须要求所有代码贡献者在每次提交时都声明他们在法律上有权作出相关贡献。 [OSPS-LE-01.01]
    在项目的代码库中包含一个DCO,要求代码贡献者在每次提交时断言他们有合法授权提交相关贡献。使用状态检查以确保完成此断言。CLA也满足此要求。某些版本控制系统(例如GitHub)可能会在平台服务条款中包含此项。

    Every change reaches main through a pull request on GitHub (the main ruleset requires one and has no bypass, https://github.com/ciatlas/flowpact/blob/main/.github/rulesets/main.json). Under section D.6 of GitHub's Terms of Service, contributors to this MIT-licensed repository assert they have the right to license their contributions, as https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#pull-requests also states.



    当向主分支提交时,必须通过或手动绕过提交的任何自动化状态检查。 [OSPS-QA-03.01]
    配置项目的版本控制系统,要求所有自动化状态检查通过或在提交合并到主分支之前需要手动确认。建议不要将任何可选状态检查配置为批准者可能会绕过的通过或失败要求。

    The live main ruleset has no bypass actors and requires the 'CI passed' and 'Conventional PR title' checks to pass on an up-to-date branch before any merge (https://github.com/ciatlas/flowpact/blob/main/.github/rulesets/main.json). 'CI passed' fails unless every CI job succeeds (https://github.com/ciatlas/flowpact/blob/main/.github/workflows/ci.yml). Renovate merges only when all checks are green. The other checks (CodeQL, code-scanning results) are informational, so merging past a failure in one of them is a manual action by the maintainer.



    在接受提交之前,项目的CI/CD管道必须运行至少一个自动化测试套件,以确保更改符合预期。 [OSPS-QA-06.01]
    应在每次合并到主分支之前运行自动化测试。测试套件应在CI/CD管道中运行,结果应对所有贡献者可见。测试套件应在一致的环境中运行,并应以允许贡献者在本地运行测试的方式运行。测试套件的示例包括单元测试、集成测试和端到端测试。

    On every pull request, CI's Test job runs the Vitest suite of unit, property and end-to-end tests (pnpm coverage) on Node 22 and 24 (https://github.com/ciatlas/flowpact/blob/main/.github/workflows/ci.yml). CI also smoke-tests the packed CLI on Linux, macOS and Windows and the extension in VS Code. The main ruleset requires the aggregate 'CI passed' check and has no bypass actors, so nothing merges without these tests.



    当项目发布版本时,项目文档必须包括设计文档,展示系统中的所有操作和参与者。 [OSPS-SA-01.01]
    在项目文档中包括说明操作和参与者的设计。参与者包括可以影响系统中另一段的任何子系统或实体。确保为新功能或重大更改更新此文档。

    https://ciatlas.github.io/flowpact/docs/how-it-works describes the analysis step by step, from YAML to reports. https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#repository-layout names each component: the core model, lint, reporters, CLI/API, action, language server and extension. https://ciatlas.github.io/flowpact/docs/security covers every actor and action around them: the analyzed repository as untrusted input, plugins, what flowpact writes, the Action's two network calls and its token, and permissions. The release workflow, release bot and Renovate are covered there and in https://github.com/ciatlas/flowpact/blob/main/CONTRIBUTING.md#releases.



    当项目发布版本时,项目文档必须包括对已发布软件资产的所有外部软件接口的描述。 [OSPS-SA-02.01]
    记录已发布软件资产的所有软件接口(API),解释用户如何与软件交互以及期望或产生什么数据。确保为新功能或重大更改更新此文档。

    Reference docs cover every external interface of the released assets. The CLI's commands, options, output formats, JSON report, exit codes and environment variables: https://ciatlas.github.io/flowpact/docs/cli. The Action's inputs, outputs, annotations and permissions: https://ciatlas.github.io/flowpact/docs/action. The programmatic API: https://ciatlas.github.io/flowpact/docs/api. The config, with JSON Schemas: https://ciatlas.github.io/flowpact/docs/configuration. Contracts: https://ciatlas.github.io/flowpact/docs/contracts. The plugin API: https://ciatlas.github.io/flowpact/docs/custom-rules. The language server and extension settings: https://ciatlas.github.io/flowpact/docs/editors.



    当项目发布版本时,项目必须执行安全评估,以了解软件中可能发生的最可能和最具影响力的潜在安全问题。 [OSPS-SA-03.01]
    执行安全评估可以告知项目成员和下游消费者,项目了解软件中可能出现的问题。了解可能实现的威胁有助于项目管理和应对风险。此信息对下游消费者很有用,可以证明项目的安全敏锐度和实践。确保为新功能或重大更改更新此文档。

    The threat model at https://ciatlas.github.io/flowpact/docs/threat-model ranks the most likely and impactful security problems by residual risk, each with the mitigation in the code, the tests that cover it and the risk that remains; CONTRIBUTING.md asks to revisit it for new features and breaking changes.



    项目文档必须包含协调漏洞披露(CVD)政策,并明确响应的时间框架。 [OSPS-VM-01.01]
    在目录根目录创建一个SECURITY.md文件,概述项目的协调漏洞披露政策。包括报告漏洞的方法。设定项目将如何响应和处理报告问题的期望。

    https://github.com/ciatlas/flowpact/blob/main/SECURITY.md is the coordinated disclosure policy, also shown at https://github.com/ciatlas/flowpact/security/policy. Reports go privately through GitHub's private vulnerability reporting, with an acknowledgement within 3 working days and an assessment within 10. The advisory is published once a fixed release is available, crediting the reporter.



    项目文档必须提供一种方式,让贡献者能够直接向项目内的安全联系人私下报告漏洞。 [OSPS-VM-03.01]
    为安全研究人员提供一种方式,以私下向项目报告漏洞。这可能是专用电子邮件地址、Web表单、VCS专用工具、安全联系人的电子邮件地址或其他方法。

    https://github.com/ciatlas/flowpact/blob/main/SECURITY.md#reporting-a-vulnerability directs reporters to GitHub's private vulnerability reporting form (https://github.com/ciatlas/flowpact/security/advisories/new) and not to public issues. The form is enabled for the repository, and reports reach the maintainer privately.



    项目文档必须公开发布已发现漏洞的相关数据。 [OSPS-VM-04.01]
    在可预测的公共渠道(例如CVE条目、博客文章或其他媒体)中提供有关已知漏洞的信息。在可能的情况下,此信息应包括受影响的版本、消费者如何确定他们是否容易受到攻击以及缓解或修复的说明。

    Vulnerabilities fixed in past releases are published in https://github.com/ciatlas/flowpact/blob/main/SECURITY.md#security-fixes-in-past-releases with the affected versions, how to tell whether you are affected and the fix; future ones are published as GitHub security advisories (https://github.com/ciatlas/flowpact/security/advisories) and named in the release notes.



您可以使用工具和AI系统通过简单的URL提交变更建议,例如 https://www.bestpractices.dev/zh-CN/projects/15403/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统,了解具体操作方法。 该数据可在社区数据许可协议 – 许可性,版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据,无论是否经过修改,只要数据接收方在共享数据时提供本协议文本。请注明Ruman Kazi和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者: Ruman Kazi.
最后更新于 2026-10-12 07:45:57 UTC, 最后更新于 2026-10-12 10:15:42 UTC。 最后在 2026-10-12 07:46:35 UTC 获得通过徽章。