EGC - Extended Global Context

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

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

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


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

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

        

 基本

  • 常规

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

    Your AI remembers your project across sessions and tools. Local-first MCP runtime with persistent memory, shared workflows, and plug-and-play integration.

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

 控制 21/21 ●

  • 控制


    足够获得徽章！

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

    Each workflow job declares only the permissions it requires. The release job has contents: write and id-token: write for provenance; all others use contents: read or no permissions.


    足够获得徽章！

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

    workflow_dispatch triggers do not accept external user inputs. All context variables in shell steps are passed through env: to avoid injection. Tag name format is validated by regex before use.


    足够获得徽章！

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

    All assets within a GitHub release are clearly associated with the release tag identifier. The npm tarball filename includes the version. Attestations are linked to specific release artifacts: https://github.com/Fmarzochi/EGC/releases.


    足够获得徽章！

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

    A secrets and credentials management policy is documented in SECURITY.md, covering storage, access, rotation, scope, and audit: https://github.com/Fmarzochi/EGC/blob/main/SECURITY.md.


    足够获得徽章！

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

    Instructions to verify the integrity and authenticity of release assets using gh attestation verify and npm audit signatures are documented at: https://github.com/Fmarzochi/EGC/blob/main/docs/security/RELEASE-VERIFICATION.md.


    足够获得徽章！

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

    Instructions to verify the expected identity of the release author via Sigstore attestation certificates (issuer and subject) are documented at: https://github.com/Fmarzochi/EGC/blob/main/docs/security/RELEASE-VERIFICATION.md.


    足够获得徽章！

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

    SUPPORT.md describes the support scope and duration for each release, including which versions receive security updates: https://github.com/Fmarzochi/EGC/blob/main/SUPPORT.md.


    足够获得徽章！

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

    SUPPORT.md includes a statement on when versions will no longer receive security updates (only latest stable release is supported): https://github.com/Fmarzochi/EGC/blob/main/SUPPORT.md.


    足够获得徽章！

    在活跃期间，项目文档必须有一个策略，要求在授予对敏感资源的提升权限之前审查代码协作者。 [OSPS-GV-04.01]
    在项目文档中发布可执行的策略，要求在授予对敏感资源（例如合并批准或访问秘密）的提升权限之前审查和批准代码协作者。建议审查包括建立可证明的身份血统，例如确认贡献者与已知可信组织的关联。

    MAINTAINERS.md documents the policy requiring review of contributors prior to granting escalated permissions, including the steps for evaluation and minimum-privilege assignment: https://github.com/Fmarzochi/EGC/blob/main/MAINTAINERS.md.


    足够获得徽章！

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

    The release workflow generates an SBOM using anchore/sbom-action and attests it via actions/attest-sbom, delivering a signed SBOM with every release: https://github.com/Fmarzochi/EGC/blob/main/.github/workflows/release.yml.


    足够获得徽章！

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

    EGC is a single-repository project. There are no subproject repositories that form part of the release.


    足够获得徽章！

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

    CONTRIBUTING.md documents when and how tests are run (npm test locally; CI runs on every PR across Node 18/20/22 on Linux/macOS/Windows): https://github.com/Fmarzochi/EGC/blob/main/CONTRIBUTING.md.


    足够获得徽章！

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

    CONTRIBUTING.md includes a policy that all significant changes to the codebase should add or update tests, verified via the PR checklist: https://github.com/Fmarzochi/EGC/blob/main/CONTRIBUTING.md.


    足够获得徽章！

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

    GitHub branch protection requires at least one non-author review approval before any PR can be merged to the main branch.


    足够获得徽章！

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

    A threat model and attack surface analysis identifying critical code paths and potential attack vectors is documented at: https://github.com/Fmarzochi/EGC/blob/main/docs/security/THREAT-MODEL.md.


    足够获得徽章！

    在活跃期间，软件组件中不影响项目的任何漏洞必须在VEX文档中予以说明，并以不可利用性细节补充漏洞报告。 [OSPS-VM-04.02]
    建立VEX供给源，传达已知漏洞的可利用性状态，包括评估细节或任何阻止易受攻击代码执行的缓解措施。

    npm audit reports zero known vulnerabilities as of 2026-06-04. A VEX document registry is established at docs/security/vex/ to account for any future findings: https://github.com/Fmarzochi/EGC/blob/main/docs/security/vex/README.md.


    足够获得徽章！

    在活跃期间，项目文档必须包含一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。 [OSPS-VM-05.01]
    在项目中记录一项政策，定义与漏洞和许可证相关的SCA发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    SCA-POLICY.md defines remediation thresholds by severity (Critical: 7 days, High: 14 days, Moderate: 90 days) and license compliance requirements: https://github.com/Fmarzochi/EGC/blob/main/docs/security/SCA-POLICY.md.


    足够获得徽章！

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

    SCA-POLICY.md documents that no release may proceed if npm audit reports high/critical vulnerabilities. The dependency-review.yml workflow enforces this: https://github.com/Fmarzochi/EGC/blob/main/docs/security/SCA-POLICY.md.


    足够获得徽章！

    在活跃期间，对项目代码库的所有更改必须根据记录的恶意依赖项和依赖项中已知漏洞的政策自动评估，然后在违规的情况下阻止，除非声明并抑制为不可利用。 [OSPS-VM-05.03]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行软件组成分析工具。要求状态检查在更改可以合并之前必须通过。

    dependency-review.yml runs on all PRs and blocks merges that introduce new high or critical severity dependencies. npm audit runs in CI on every push: https://github.com/Fmarzochi/EGC/blob/main/.github/workflows/dependency-review.yml.


    足够获得徽章！

    在活跃期间，项目文档必须包含一项政策，定义SAST发现的修复阈值。 [OSPS-VM-06.01]
    在项目中记录一项政策，定义静态应用程序安全测试（SAST）发现的修复阈值。包括识别、优先级排序和修复这些发现的流程。

    SCA-POLICY.md defines SAST remediation thresholds by severity (Critical/High: block merge; Medium: 30 days; Low: best effort): https://github.com/Fmarzochi/EGC/blob/main/docs/security/SCA-POLICY.md.


    足够获得徽章！

    在活跃期间，对项目代码库的所有更改必须根据记录的安全弱点政策自动评估，并在违规的情况下阻止，除非声明并抑制为不可利用。 [OSPS-VM-06.02]
    在项目的版本控制系统中创建一个状态检查，对代码库的所有更改运行静态应用程序安全测试（SAST）工具。要求状态检查在更改可以合并之前必须通过。

    CodeQL and ESLint run automatically on all PRs and pushes, blocking merges on any high/critical security findings: https://github.com/Fmarzochi/EGC/blob/main/.github/workflows/codeql.yml.



该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Felipe Marzochi和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Felipe Marzochi.
最后更新于 2026-06-04 17:03:36 UTC, 最后更新于 2026-06-08 02:58:41 UTC。 最后在 2026-06-04 17:57:02 UTC 获得通过徽章。