EGC - Extended Global Context

本サイトが提示する下記のベストプラクティスを実行するプロジェクトは、Open Source Security Foundation (OpenSSF) バッジを達成したことを自主的に自己認証し、そのことを外部に示すことができます。

ソフトウェアに欠陥や脆弱性がないことを保証する手立てはありません。形式論的な証明ができたとしても、仕様や前提が間違っていると誤動作の可能性があります。また、プロジェクトが健全で、かつ機能的な開発コミュニティであり続けることを保証する手立てもありません。しかし、ベストプラクティスの採用は、プロジェクトの成果の向上に寄与する可能性があります。たとえば、いくつものベストプラクティスがリリース前の複数人によるレビューを定めていますが、それによりレビュー以外では発見困難な技術的脆弱性を見つけるのを助け、同時に異なる企業の開発者間の信頼を築き、さらに交流を続けることに対する意欲を生んでいます。バッジを獲得するには、すべてのMUSTおよびMUST NOT基準を満たさなければなりません。すべてのSHOULD基準も満たさなければなりませんが、正当な理由がある場合は満たさなくても構いません。そしてすべてのSUGGESTED基準も満たさなければなりませんが、満たさないとしても、少なくとも考慮することが望まれます。フィードバックは、 GitHubサイトのissueまたはpull requestとして提示されれば歓迎します。また、議論のためのメールリストも用意されています。

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトである場合は、プロジェクトページにベースラインバッジステータスを表示してください！ベースラインバッジステータスは次のようになります： プロジェクト13099のベースラインバッジレベルはbaseline-3です ベースラインバッジを埋め込む方法は次のとおりです：
ベースラインバッジステータスを表示するには、マークダウンファイルに以下を埋め込みます：
[![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)」。一重引用符または二重引用符を含めないでください。
    複数の言語がある場合は、コンマを区切り（スペースを入れてもよい）としてリストし、使用頻度の高いものから順に並べます。使用言語が多くある場合は、少なくとも最初の3つの最も多く使われるものをリストアップしてください。言語がない場合（例：ドキュメントだけ、またはテスト専用のプロジェクトの場合）、1文字 " - "を使用します。言語ごとにある大文字・小文字の慣用を踏襲してください（例：「JavaScript」）。
    Common Platform Enumeration（CPE）は、情報技術（IT）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

 管理策 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.


    バッジには十分です！

    プロジェクトがリリースを作成した場合、プロジェクトのドキュメントには、ソフトウェアリリースを作成した人またはプロセスの期待されるIDを検証するための手順が含まれている必要があります。 [OSPS-DO-03.02]
    期待されるIDは、署名に使用される鍵ID、sigstore証明書からの発行者とID、または他の類似の形式である可能性があります。可能であれば、このドキュメントをビルドおよびリリースパイプラインと同じ場所に保存しないようにして、単一の侵害によってソフトウェアとその整合性を検証するためのドキュメントの両方が侵害されることを避けてください。

    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]
    マージ承認やシークレットへのアクセスなど、機密リソースへのエスカレートされた権限を付与される前に、コード共同作業者がレビューおよび承認される必要があるという実行可能なポリシーをプロジェクトのドキュメントに公開してください。審査には、既知の信頼できる組織との貢献者の関連性を確認するなど、正当化可能なIDの系統を確立することが推奨されます。

    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 Baseline要件に従うことに加えて、これにはセキュリティレビューを要求すること、脆弱性がないこと、および既知のセキュリティ問題がないことを確認することが含まれる場合があります。

    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.


    バッジには十分です！

    アクティブな間、プロジェクトのドキュメントには、プロジェクトが生成するソフトウェアに対するすべての主要な変更は、自動化されたテストスイートの機能のテストを追加または更新する必要があるというポリシーを含めなければなりません（MUST）。 [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.


    バッジには十分です！

    プライマリブランチにコミットが行われる場合、プロジェクトのバージョン管理システムは、マージする前に、作者以外の少なくとも1人の人間による変更の承認を要求しなければなりません（MUST）。 [OSPS-QA-07.01]
    プロジェクトのバージョン管理システムを構成し、リリースまたはプライマリブランチにマージする前に、作者以外の少なくとも1人の人間による変更の承認を要求します。これは、プルリクエストがマージされる前に、少なくとも1人の他のコラボレーターによってレビューおよび承認されることを要求することで実現できます。

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


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトは、システム内の重要なコードパス、関数、および相互作用に対する攻撃を理解して防御するために、脅威モデリングと攻撃面分析を実行しなければなりません（MUST）。 [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ドキュメントで説明し、非悪用可能性の詳細で脆弱性レポートを補強しなければなりません（MUST）。 [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調査結果の修復のしきい値を定義するポリシーを含めなければなりません（MUST）。 [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違反に対処するポリシーを含めなければなりません（MUST）。 [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.


    バッジには十分です！

    アクティブな間、プロジェクトのコードベースへのすべての変更は、悪意のある依存関係と依存関係の既知の脆弱性に関する文書化されたポリシーに対して自動的に評価され、非悪用可能と宣言および抑制されている場合を除き、違反の場合はブロックされなければなりません（MUST）。 [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調査結果の修復のしきい値を定義するポリシーを含めなければなりません（MUST）。 [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.


    バッジには十分です！

    アクティブな間、プロジェクトのコードベースへのすべての変更は、セキュリティの弱点に関する文書化されたポリシーに対して自動的に評価され、非悪用可能と宣言および抑制されている場合を除き、違反の場合はブロックされなければなりません（MUST）。 [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.



このデータは、Community Data License Agreement – Permissive, Version 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にバッジ合格を達成しました。