trentpower.fr

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

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

私たちは多言語で情報を提供していますが、翻訳版に矛盾や意味の不一致がある場合は、英語版を正式な記述とします。
これがあなたのプロジェクトである場合は、プロジェクトページにベースラインバッジステータスを表示してください！ベースラインバッジステータスは次のようになります： プロジェクト13182のベースラインバッジレベルはbaseline-2です ベースラインバッジを埋め込む方法は次のとおりです：
ベースラインバッジステータスを表示するには、マークダウンファイルに以下を埋め込みます：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13182/baseline)](https://www.bestpractices.dev/projects/13182)
または、HTMLに以下を埋め込みます：
<a href="https://www.bestpractices.dev/projects/13182"><img src="https://www.bestpractices.dev/projects/13182/baseline"></a>


これらはベースラインレベル2の基準です。 これらは基準バージョン v2026.02.19 の評価項目です。

Baseline Series: ベースラインレベル1 ベースラインレベル2 ベースラインレベル3

        

 基本的情報

  • 一般

    他のプロジェクトが同じ名前を使用していないか注意してください。

    A bilingual (English/French) personal publication, built as a static site whose every published file can be verified against a signed integrity manifest. The repository is the complete, inspectable record of how it is built, checked and released.

    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）システム、ソフトウェア、およびパッケージのための構造化された命名体系です。脆弱性を報告する際に、多くのシステムやデータベースで使用されています。

    This is a single-author publication system, not a library meant to be installed. Where a criterion assumes a software package, I have answered for the build and verification tooling, which is where the executable code lives.

 管理策 19/19 ●

  • 管理策


    バッジには十分です！

    CI/CDタスクが権限を指定せずに実行される場合、CI/CDシステムはパイプラインで付与される最低限の権限をタスクの権限としてデフォルトで設定しなければなりません。 [OSPS-AC-04.01]
    プロジェクトの設定を構成して、デフォルトで新しいパイプラインに利用可能な最低限の権限を割り当て、特定のタスクに必要な場合にのみ追加の権限を付与します。

    Every workflow sets a top-level permissions: contents: read; jobs needing more (e.g. Scorecard security-events: write) declare it explicitly and narrowly. See .github/workflows/.


    バッジには十分です！

    公式リリースが作成される場合、そのリリースには一意のバージョン識別子を割り当てなければなりません。 [OSPS-BR-02.01]
    プロジェクトによって生成される各リリースに、一貫した命名規則または番号付けスキームに従って一意のバージョン識別子を割り当てます。例には、SemVer、CalVer、またはgit commit idが含まれます。

    Each release is an edition identified by its calendar date (YYYY-MM-DD), recorded in the signed public/integrity.json and in a dedicated immutable directory public/integrity/releases/<edition>/. Asset bundles additionally carry an 8-hex content hash.


    バッジには十分です！

    公式リリースが作成される場合、そのリリースには機能的およびセキュリティの変更の記述的なログを含めなければなりません。 [OSPS-BR-04.01]
    すべてのリリースに記述的な変更ログを含めるようにしてください。変更ログが人間が読めるものであり、コミットメッセージだけでなく、セキュリティへの影響や異なるユースケースとの関連性についての説明などの詳細を含めることが推奨されます。機械可読性を確保するために、「## Changelog」などのmarkdownヘッダーの下にコンテンツを配置してください。

    Every workflow sets a top-level permissions: contents: read; jobs needing more (e.g. Scorecard security-events: write) declare it explicitly and narrowly. See .github/workflows/.


    バッジには十分です！

    ビルドとリリースのパイプラインが依存関係を取り込む場合、利用可能な場合は標準化されたツールを使用しなければなりません。 [OSPS-BR-05.01]
    エコシステム用の一般的なツール（パッケージマネージャーや依存関係管理ツールなど）を使用して、ビルド時に依存関係を取り込みます。これには、必要な依存関係を指定するための依存関係ファイル、ロックファイル、またはマニフェストを使用し、ビルドシステムによって取り込まれることが含まれます。

    Python via pip with --require-hashes against compiled .github/requirements/*.txt; JavaScript via npm + lockfile; updates via Dependabot. Standard, language-native tooling throughout.


    バッジには十分です！

    公式リリースが作成される場合、そのリリースには署名するか、各アセットの暗号ハッシュを含む署名付きマニフェストで説明しなければなりません。 [OSPS-BR-06.01]
    ビルド時にすべてのリリースされたソフトウェア アセットを、GPGまたはPGP署名、Sigstore署名、SLSAプロベナンス、またはSLSA VSAなどの暗号署名または証明で署名します。署名付きマニフェストまたはメタデータファイルに各アセットの暗号ハッシュを含めます。

    public/integrity.json maps every published URL to a SHA-256 digest and is covered by a detached PGP signature public/integrity.json.sig, verifiable against the published key. Per-edition archives carry SHA256SUMS + .sig. See docs/TRUST-AND-VERIFICATION.md.


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトのドキュメントには、プロジェクトが依存関係をどのように選択、取得、および追跡するかについての説明を含めなければなりません。 [OSPS-DO-06.01]
    この情報をソースコードリポジトリ、プロジェクトウェブサイト、またはその他のチャネルなどの公開表示可能なリソース上で、プロジェクトの技術および設計ドキュメントと一緒に公開することが推奨されます。

    THIRD_PARTY_NOTICES.md plus .github/requirements/README.md describe how dependencies are chosen, pinned (hash-locked), and tracked (weekly Dependabot). The security stack rationale, including what was deliberately declined, is in docs/github-rulesets.md.


    バッジには十分です！

    プロジェクトのドキュメントには、必要なライブラリ、フレームワーク、SDK、および依存関係を含む、ソフトウェアのビルド方法に関する手順が含まれていなければなりません。 [OSPS-DO-07.01]
    この情報は、CONTRIBUTING.mdや他の開発者タスクドキュメントなど、プロジェクトの貢献者ドキュメントと一緒に公開することが推奨されます。これはまた、Makefileターゲットや他の自動化スクリプトを使用して文書化することもできます。

    README.md (Build section) and docs/BUILD-AND-DEPLOYMENT.md list required tools (Python 3, Bash, GnuPG, optional dev tools) and the build commands.


    バッジには十分です！

    有効な間、プロジェクトのドキュメントには、機密性の高いリソースへのアクセス権を持つプロジェクトメンバーのリストを含めなければなりません。 [OSPS-GV-01.01]
    プロジェクトのソースコードリポジトリ内のmembers.md、governance.md、maintainers.md、または同様のファイルなどのアーティファクトを通じて、プロジェクト参加者とその役割を文書化します。これは、メンテナのリストに名前またはアカウントハンドルを含めるだけの簡単なものでも、プロジェクトのガバナンスに応じてより複雑なものでも構いません。

    GOVERNANCE.md (Roles table) names the sole maintainer who holds signing keys and approves deploys; .github/CODEOWNERS maps the trust-critical surfaces.


    バッジには十分です！

    有効な間、プロジェクトのドキュメントには、プロジェクトのメンバーの役割と責任の説明を含めなければなりません。 [OSPS-GV-01.02]
    プロジェクトのソースコードリポジトリ内のmembers.md、governance.md、maintainers.md、または同様のファイルなどのアーティファクトを通じて、プロジェクト参加者とその役割を文書化します。

    GOVERNANCE.md Roles table sets out Maintainer and Contributor responsibilities; the Decision model and Continuity sections complete the picture.


    バッジには十分です！

    有効な間、プロジェクトのドキュメントには、受け入れ可能な貢献の要件を含むコード貢献者向けのガイドを含めなければなりません。 [OSPS-GV-03.02]
    プロジェクトドキュメントのCONTRIBUTING.mdまたはCONTRIBUTING/の内容を拡張して、コーディング標準、テスト要件、コードコントリビューターのための提出ガイドラインを含む、受け入れ可能な貢献の要件を概説します。このガイドがコントリビューターと承認者の両方にとって信頼できる情報源であることが推奨されます。

    CONTRIBUTING.md states the contribution model and the categories of acceptable issues; PRs are generally declined. Strengthen: add an explicit "requirements for acceptable contributions" line (signed commits, no attribution trailers, gate must pass) drawn from .github/PULL_REQUEST_TEMPLATE.md, so the acceptance bar is stated in prose.


    バッジには十分です！

    アクティブな間、バージョン管理システムは、すべてのコードコントリビューターが、すべてのコミットで関連する貢献を行うことが法的に認められていると主張することを要求する必要があります。 [OSPS-LE-01.01]
    プロジェクトのリポジトリにDCOを含め、コードコントリビューターが、すべてのコミットで関連する貢献を行うことが法的に認められていると主張することを要求します。ステータスチェックを使用して、主張が行われたことを確認します。CLAもこの要件を満たします。GitHubなどの一部のバージョン管理システムでは、これがプラットフォームの利用規約に含まれている場合があります。

    CONTRIBUTING.md states that contributing asserts the right to submit the work under the project's licences, and commits carry the DCO Signed-off-by line via git commit -s. Combined with the required cryptographic commit signature, each commit carries both authorship and the right to contribute.


    バッジには十分です！

    プライマリブランチにコミットが行われる場合、コミットの自動ステータスチェックは、合格するか手動でバイパスされる必要があります。 [OSPS-QA-03.01]
    プロジェクトのバージョン管理システムを設定して、すべての自動ステータスチェックが合格するか、コミットがプライマリブランチにマージされる前に手動確認を要求するようにします。オプションのステータスチェックは、承認者がバイパスしたくなるような合格または不合格の要件として設定しないことが推奨されます。

    The main ruleset requires release-gate, secret-scan, release-gate-main, build-check and signature-verify to pass before merge. See docs/github-rulesets.md.


    バッジには十分です！

    コミットが受け入れられる前に、プロジェクトのCI/CDパイプラインは、変更が期待を満たすことを確認するために少なくとも1つの自動テストスイートを実行する必要があります。 [OSPS-QA-06.01]
    自動テストは、プライマリブランチへのすべてのマージの前に実行される必要があります。テストスイートはCI/CDパイプラインで実行され、結果はすべてのコントリビューターに表示される必要があります。テストスイートは一貫した環境で実行され、コントリビューターがローカルでテストを実行できるような方法で実行される必要があります。テストスイートの例には、ユニットテスト、統合テスト、エンドツーエンドテストが含まれます。

    The source-quality job in .github/workflows/pr-checks.yml runs the unit and property-based test suite on every PR (QUALITY_ENFORCE=1).


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントは、システム内のすべてのアクションとアクターを示す設計ドキュメントを含む必要があります。 [OSPS-SA-01.01]
    プロジェクトドキュメントに、アクションとアクターを説明する設計を含めます。アクターには、システム内の別のセグメントに影響を与えることができるサブシステムまたはエンティティが含まれます。これが新機能や破壊的変更のために更新されることを確認してください。

    docs/ARCHITECTURE.md describes the system and its actors; docs/BUILD-AND-DEPLOYMENT.md documents the numbered publication ceremony (operator, CI, host, reader); docs/ASSURANCE-CASE.md includes a trust-boundary diagram across those actors.


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトドキュメントは、リリースされたソフトウェアアセットのすべての外部ソフトウェアインターフェースの説明を含む必要があります。 [OSPS-SA-02.01]
    リリースされたソフトウェアアセットのすべてのソフトウェアインターフェース（API）を文書化し、ユーザーがソフトウェアとどのように対話できるか、どのようなデータが期待または生成されるかを説明します。これが新機能や破壊的変更のために更新されることを確認してください。

    The site's external surfaces are the public routes and /.well-known/ endpoints, documented in docs/CONTENT-MODEL.md and docs/public-artefact-conventions.md, with the public-exposure allow-list governing what is served.


    バッジには十分です！

    プロジェクトがリリースを行った場合、プロジェクトは、ソフトウェア内で発生する可能性のある最も可能性が高く、影響の大きい潜在的なセキュリティ問題を理解するためにセキュリティ評価を実行する必要があります。 [OSPS-SA-03.01]
    セキュリティ評価を実行することで、プロジェクトメンバーと下流の消費者の両方に、プロジェクトがソフトウェア内で発生する可能性のある問題を理解していることを知らせます。どのような脅威が実現する可能性があるかを理解することは、プロジェクトがリスクを管理および対処するのに役立ちます。この情報は、プロジェクトのセキュリティの能力と実践を示すために、下流の消費者にとって有用です。これが新機能や破壊的変更のために更新されることを確認してください。

    docs/ASSURANCE-CASE.md is a full assurance case: security requirements, threat model table, trust boundaries, design principles and common weaknesses countered. Mechanisms in docs/SECURITY-AND-PRIVACY.md; incident handling in docs/INCIDENT-RESPONSE.md.


    バッジには十分です！

    アクティブな間、プロジェクトドキュメントは、明確な対応期間を持つ協調的脆弱性開示（CVD）のポリシーを含む必要があります。 [OSPS-VM-01.01]
    ディレクトリのルートにSECURITY.mdファイルを作成し、プロジェクトの協調的脆弱性開示のポリシーを概説します。脆弱性を報告する方法を含めます。プロジェクトが報告された問題にどのように対応および対処するかについての期待を設定します。

    SECURITY.md and the RFC 9116 security.txt at https://trentpower.fr/.well-known/security.txt both publish the route. https://github.com/trentpower/trentpower.fr/blob/main/SECURITY.md [vulnerability_report_process]


    バッジには十分です！

    アクティブな間、プロジェクトドキュメントは、プロジェクト内のセキュリティ連絡先に直接脆弱性を非公開で報告する手段を提供する必要があります。 [OSPS-VM-03.01]
    セキュリティ研究者がプロジェクトに非公開で脆弱性を報告する手段を提供します。これは、専用の電子メールアドレス、ウェブフォーム、VCS専用ツール、セキュリティ連絡先の電子メールアドレス、またはその他の方法である可能性があります。

    SECURITY.md provides GitHub private vulnerability reporting and an encrypted email contact via /.well-known/security.txt + PGP key.


    バッジには十分です！

    アクティブな間、プロジェクトドキュメントは、発見された脆弱性に関するデータを公開する必要があります。 [OSPS-VM-04.01]
    CVEエントリ、ブログ投稿、またはその他のメディアなど、予測可能な公開チャネルで既知の脆弱性に関する情報を提供します。可能な限り、この情報には、影響を受けるバージョン、消費者が脆弱かどうかを判断する方法、および緩和または修復の手順が含まれる必要があります。

    Policy and channel exist (GitHub Security Advisories / GHSA); no vulnerabilities have been discovered to date, so there is nothing yet to publish. Strengthen: add a one-line "no advisories to date" statement to SECURITY.md and commit to publishing via GHSA, so the absence is explicit rather than implied.



このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。Trent PowerおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者： Trent Power.
エントリの作成日時 2026-06-12 16:09:19 UTC、 最終更新日 2026-06-13 10:53:16 UTC 最後に2026-06-12 19:45:29 UTCにバッジ合格を達成しました。