gqlPrune

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

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

如果这是您的项目,请在项目页面上显示您的基准徽章状态!基准徽章状态如下所示: 项目13364的基准徽章等级为baseline-2 以下是如何嵌入基准徽章:
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13364/baseline)](https://www.bestpractices.dev/projects/13364)
或者将其嵌入到HTML中:
<a href="https://www.bestpractices.dev/projects/13364"><img src="https://www.bestpractices.dev/projects/13364/baseline"></a>


这些是基准等级3的标准。 这些是标准版本 v2026.08.28。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

  • 常规

    请注意,其他项目可能使用相同的名称。

    This script helps identify unused GraphQL operations (queries, mutations, subscriptions) in your project. It scans .gql files for operations and checks if they are being used in your TypeScript/JavaScript files

    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”,“BSD-2-Clause”,“BSD-3-Clause”,“GPL-2.0+”,“LGPL-3.0 +”,“MIT”和“(BSD-2-Clause OR Ruby)”。
    如果有多种语言,请将它们列为逗号分隔值(可选空格),并将它们从最多到最少使用。如果有长列表,请至少列出前三个最常见的列表。如果没有语言(例如,这是仅文档或仅测试项目),请使用单个字符“ - ”。请使用每种语言的常规大小写,例如“JavaScript”。
    通用平台枚举(CPE)是用于信息技术系统,软件和软件包的结构化命名方案。在报告漏洞时,它可用于多个系统和数据库。

 控制 20/21 ●

  • 控制


    当在CI/CD管道中为作业分配权限时,源代码或配置必须仅分配相应活动所需的最低权限。 [OSPS-AC-04.02]
    配置项目的CI/CD流水线,默认为用户和服务分配最低可用权限,仅在特定任务需要时才提升权限。在某些版本控制系统中,这可以在组织或代码仓库级别实现。如果不行,请在流水线的顶层设置权限。

    Every workflow assigns permissions explicitly, contents: read at the workflow level, elevated per job only where a task needs it (the SBOM job gets contents: write to upload the release asset; publishing gets its OIDC token in the shared release workflow).



    接受可信协作者输入的 CI/CD 流水线在流水线中使用该输入之前,必须对其进行清理和验证。 [OSPS-BR-01.04]
    CI/CD 流水线应对显式工作流执行中的所有协作者输入进行清理(引用、转义或在期望值时退出)。虽然协作者通常是可信的,但工作流的手动输入无法经过审查,可能被账户劫持或内部威胁所滥用。

    Workflows accept no free-text collaborator input. The only inputs to the reusable workflows are typed booleans, and metadata such as pull request bodies is passed through environment variables rather than interpolated into shell.



    当创建正式发布版本时,该发布版本中的所有资产必须明确关联到发布标识符或资产的其他唯一标识符。 [OSPS-BR-02.02]
    为项目生成的每个软件资产分配唯一的版本标识符,遵循一致的命名约定或编号方案。示例包括SemVer、CalVer或git提交ID。

    Each user-facing release has a unique semantic version, published to npm (https://www.npmjs.com/package/gqlprune) and tagged in git (e.g. v2.0.1). [version_unique]



    项目必须定义管理项目使用的秘密和凭证的策略。该策略应包括存储、访问和轮换秘密和凭证的指南。 [OSPS-BR-07.02]
    记录项目内如何管理和使用秘密和凭证。这应包括如何存储秘密(例如,使用秘密管理工具)、如何控制访问以及如何轮换或更新秘密的详细信息。确保敏感信息不会硬编码在源代码中或存储在版本控制系统中。

    docs/security-policies.md documents the secrets policy: publishing holds no credential (OIDC trusted publishing), the only standing secret is the Codecov upload token in GitHub Actions secrets, secret scanning and gitignore guard the repository, access follows the GOVERNANCE.md escalated-permissions policy, and rotation is defined. https://github.com/Krister-Johansson/gqlPrune/blob/main/docs/security-policies.md



    当项目已发布版本时,项目文档必须包含验证发布资产完整性和真实性的说明。 [OSPS-DO-03.01]
    项目中的说明应包含所使用技术、要运行的命令以及预期输出的信息。如果可能,避免将此文档存储在构建和发布流水线的相同位置,以避免单一漏洞同时危及软件和验证软件完整性的文档。

    The Verifying a release section of SECURITY.md documents npm audit signatures (command, what it checks, expected result) and the SBOM asset attached to each GitHub release. https://github.com/Krister-Johansson/gqlPrune/blob/main/SECURITY.md



    当项目已发布版本时,项目文档必须包含验证软件发布作者的预期身份的说明。 [OSPS-DO-03.02]
    预期身份可能采用用于签名的密钥ID、来自sigstore证书的颁发者和身份或其他类似形式。如果可能,避免将此文档存储在构建和发布流水线的相同位置,以避免单一漏洞同时危及软件和验证软件完整性的文档。

    The same section states the expected identity in the provenance attestation: built by GitHub Actions from Krister-Johansson/gqlPrune via the release-please workflow, and says to treat any other identity as compromised. https://github.com/Krister-Johansson/gqlPrune/blob/main/SECURITY.md



    当项目已发布版本时,项目文档必须包含关于每个发布版本支持范围和持续时间的描述性声明。 [OSPS-DO-04.01]
    为了传达项目发布的软件资产的支持范围和持续时间,项目应有SUPPORT.md文件、SECURITY.md中的"支持"部分或其他文档,说明支持生命周期,包括每个发布版本的预期支持持续时间、提供的支持类型(例如,错误修复、安全更新)以及获取支持的任何相关策略或程序。

    SECURITY.md states the scope and duration of support: bug fixes and security updates for the latest release only, with no long-term support branches. https://github.com/Krister-Johansson/gqlPrune/blob/main/SECURITY.md



    当项目已发布版本时,项目文档必须提供描述性声明说明何时发布版本或版本将不再接收安全更新。 [OSPS-DO-05.01]
    为了传达安全修复的支持范围和持续时间,项目应有SUPPORT.md或其他文档,说明项目的安全更新策略。

    SECURITY.md states that a release stops receiving security updates the moment a newer release is published. https://github.com/Krister-Johansson/gqlPrune/blob/main/SECURITY.md



    项目文档必须制定一项政策,规定在向代码协作者授予提升权限以访问敏感资源之前对其进行审核。 [OSPS-GV-04.01]
    在项目文档中发布可执行的策略,要求在授予对敏感资源(例如合并批准或访问秘密)的提升权限之前审查和批准代码协作者。建议审查包括建立可证明的身份血统,例如确认贡献者与已知可信组织的关联。

    GOVERNANCE.md requires review before any escalated permissions: the maintainer reviews contribution history and identity, and records the grant and reasoning in an issue. https://github.com/Krister-Johansson/gqlPrune/blob/main/GOVERNANCE.md



    当项目已发布版本时,所有编译的已发布软件资产必须附带软件物料清单。 [OSPS-QA-02.02]
    建议在构建时使用经过准确性审查的工具自动生成SBOM。这使用户能够以标准化的方式将此数据与其环境中的其他项目一起提取。

    Each GitHub release carries a CycloneDX SBOM of the production dependency tree as an asset, generated by the SBOM workflow; the current release (gqlprune-v2.11.0) has gqlprune-2.11.0.cdx.json attached. https://github.com/Krister-Johansson/gqlPrune/blob/main/.github/workflows/sbom.yml



    当项目已发布包含多个源代码仓库的版本时,所有子项目必须执行与主代码库一样严格或更严格的安全要求。 [OSPS-QA-04.02]
    项目生成并编译到发布版本中的任何其他子项目代码仓库必须根据相应代码库的状态和意图执行安全要求。除了遵循相应的OSPS基线要求外,这还可能包括要求进行安全审查、确保其没有漏洞以及确保其没有已知的安全问题。

    The project is a single repository; releases comprise no other codebases.



    项目文档必须清楚地记录测试的运行时间和方式。 [OSPS-QA-06.02]
    在贡献文档中添加一个章节,说明如何在本地运行测试以及如何在CI/CD管道中运行测试。文档应说明测试的测试内容以及如何解释测试结果。

    Automated Jest test suite covering the utilities, core pruner, config generator, and CLI dispatch. [test]



    项目文档必须包含一项政策,规定对项目生成的软件所做的所有重大更改都应在自动化测试套件中添加或更新相应功能的测试。 [OSPS-QA-06.03]
    在贡献文档中添加一个章节,说明添加或更新测试的政策。该政策应说明什么是重大更改以及应该添加或更新哪些测试。

    The testing policy is documented in CONTRIBUTING.md: https://github.com/Krister-Johansson/gqlPrune/blob/main/CONTRIBUTING.md#testing-policy [tests_documented_added]



    当向主分支提交时,项目的版本控制系统必须在合并之前要求至少一名非作者人工审批更改。 [OSPS-QA-07.01]
    配置项目的版本控制系统,要求在合并到发布分支或主分支之前至少有一名非作者人工审批更改。这可以通过要求拉取请求在合并之前必须由至少另一位协作者审查和批准来实现。

    The project has a single maintainer, so no second human exists to approve changes; requiring non-author approval would deadlock every merge. Compensating controls: all changes go through pull requests gated by five required status checks (build and test on Node 20 and 22, linked issue, dependency audit, CodeQL) plus an automated review. GOVERNANCE.md describes the path to additional committers; this control will be met if the project gains one.



    当项目发布版本时,项目必须执行威胁建模和攻击面分析,以理解和防护针对系统内关键代码路径、函数和交互的攻击。 [OSPS-SA-03.02]
    威胁建模是一项活动,其中项目查看代码库、相关流程和基础设施、接口、关键组件,并"像黑客一样思考",集思广益探讨系统可能如何被破坏或受到损害。每个识别的威胁都会被列出,以便项目可以考虑如何主动避免或关闭可能出现的任何漏洞/脆弱点。确保为新功能或破坏性更改更新此分析。

    docs/assurance-case.md is the threat model and attack surface analysis: it enumerates the surfaces (scanned input, the release pipeline, dependencies, output), argues each threat and its mitigations, and states known limitations; it is updated as the design changes. https://github.com/Krister-Johansson/gqlPrune/blob/main/docs/assurance-case.md



    软件组件中不影响本项目的任何漏洞必须在VEX文档中予以记录,通过补充不可利用性的详细信息来完善漏洞报告。 [OSPS-VM-04.02]
    建立VEX供给源,传达已知漏洞的可利用性状态,包括评估细节或任何阻止易受攻击代码执行的缓解措施。

    docs/security-policies.md defines the exploitability (VEX) process: any non-affecting component vulnerability gets a recorded statement matching the alert dismissal. Currently there are zero such open vulnerabilities (last reviewed 2026-08-15); the dev-only js-yaml case is the recorded historical example. https://github.com/Krister-Johansson/gqlPrune/blob/main/docs/security-policies.md



    项目文档必须包含一项政策,为与漏洞和许可证相关的软件成分分析(SCA)发现结果的修复设定阈值。 [OSPS-VM-05.01]
    在项目中记录一项政策,定义与漏洞和许可证相关的SCA发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    docs/security-policies.md defines severity-based remediation thresholds for dependency findings (critical 7 days, high 14, moderate 30, low at next release) and the license policy (OSI-approved, MIT-compatible, inventoried in NOTICES.md). https://github.com/Krister-Johansson/gqlPrune/blob/main/docs/security-policies.md



    项目文档必须包含一项政策,要求在任何发布之前处理软件成分分析(SCA)违规问题。 [OSPS-VM-05.02]
    在项目中记录一项政策,在任何发布之前解决适用的软件组成分析结果,并添加状态检查以验证在发布之前符合该政策。

    The policy states that a release does not ship while a critical or high dependency finding is open against the production tree, and the required dependency audit check enforces this continuously. All dependency findings were cleared before 2.11.0 shipped. https://github.com/Krister-Johansson/gqlPrune/blob/main/docs/security-policies.md



    对项目代码库的所有更改都必须根据针对恶意依赖项和依赖项中已知漏洞的书面政策进行自动评估,并在出现违规情况时予以阻止,但已声明并抑制为不可利用的情况除外。 [OSPS-VM-05.03]
    在项目的版本控制系统中创建一个状态检查,对代码库的所有更改运行软件组成分析工具。要求状态检查在更改可以合并之前必须通过。

    The dependency audit status check runs npm audit against the production tree on every pull request and is required by the branch ruleset, so high or critical advisories block merge. Dependabot supplies the vulnerability intelligence, and suppressions require a recorded VEX statement per the policy. https://github.com/Krister-Johansson/gqlPrune/blob/main/.github/workflows/sca.yml



    项目文档必须包含一项政策,为静态应用程序安全测试(SAST)发现结果的修复设定阈值。 [OSPS-VM-06.01]
    在项目中记录一项政策,定义静态应用程序安全测试(SAST)发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    CodeQL findings surface in GitHub code scanning and are addressed. [static_analysis_fixed]



    对项目代码库的所有更改都必须根据书面政策针对安全弱点进行自动评估,并在出现违规情况时予以阻止,但已声明并抑制为不可利用的情况除外。 [OSPS-VM-06.02]
    在项目的版本控制系统中创建一个状态检查,对代码库的所有更改运行静态应用程序安全测试(SAST)工具。要求状态检查在更改可以合并之前必须通过。

    GitHub CodeQL code scanning runs on pushes, pull requests, and on a schedule; ESLint (typescript-eslint) and strict tsc --noEmit also run in CI. [static_analysis]



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

项目徽章条目拥有者: Krister Johansson.
最后更新于 2026-06-24 18:24:23 UTC, 最后更新于 2026-08-15 10:23:16 UTC。 最后在 2026-06-24 20:12:34 UTC 获得通过徽章。