flask-todolist

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

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

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


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

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

        

 基本的情報

  • 一般

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

    Personal Flask to-do app built to production discipline — v2.3.0 (AGPL-3.0, DOI-archived): 114 machine-checked gates, 78 ADRs, 27 recorded governance audits · OpenSSF Silver badge, PR-only main, signed releases with SLSA provenance, ASVS 5.0 L2 assessed, 27 required checks against real services

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

 管理策 19/19 ●

  • 管理策


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

    The repository default for GITHUB_TOKEN is read-only (default_workflow_permissions=read, and workflows cannot approve pull requests); every job additionally declares its own permissions block. OpenSSF Scorecard scores Token-Permissions 10/10.



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

    Every release carries a unique SemVer git tag (v1.0.0 through v2.3.0); the version is also asserted in app/init.py and a test fails if the tag, the code and CHANGELOG.md disagree.



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

    CHANGELOG.md follows Keep a Changelog with a section per release, and release notes repeat it. Releases that fix published CVEs name them explicitly — v1.5.0 lists all seven cryptography advisories.



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

    Dependencies are ingested with standard tooling only: pipenv with a hash-pinned Pipfile.lock for the application, pip --require-hashes for CI tools under pins/, and npm ci for the JavaScript tooling. A test fails the build if any workflow installs without hashes.



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

    Every asset attached to a release is signed keyless with cosign/sigstore — each SBOM ships with its .sigstore.json bundle — and the build carries SLSA provenance verified with gh attestation verify before the assets are published (ADR 0058). Note: GitHub's auto-generated source archives and the git tags themselves are not separately signed; ADR 0058 records that decision and the condition for revisiting it.



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

    docs/SUPPLY-CHAIN.md documents how dependencies are selected, obtained and tracked across every layer (application, CI tooling, container base image, service images), including the pinning rules and the two-way CVE registers. ADR 0025 documents how plugin dependencies are kept separable.



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

    README.md and CONTRIBUTING.md give the full build path: Python 3.13, pipenv sync --dev, the plugin dependency categories, and the single preflight command that runs what CI runs. docs/OPERATIONS.md covers container and compose builds.



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

    CONTRIBUTING.md section 'Who holds what' lists every member with access to sensitive resources: a single maintainer (@sayam) who is the only account with write access, administration rights and repository secrets. There are no teams or service accounts with write access.



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

    The same section describes the roles and their responsibilities, and ADR 0053 records the compensating controls that stand in for separation of duties in a single-maintainer project, together with the condition that ends the arrangement.



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

    CONTRIBUTING.md states what an acceptable contribution must satisfy: pull-request-only flow, Conventional Commits with a 72-character subject, ruff and mypy clean, mutation proof for every new test, registration of new test files in gates.yaml, and an ADR for any new decision.



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

    Every commit must carry a Signed-off-by line (Developer Certificate of Origin 1.1), added by git commit -s. The commit-msg hook rejects an unsigned commit on the contributor's machine and the commit-lint CI job checks every commit a pull request adds, including pull requests from forks. ADR 0073 records the decision, including the deliberate choice not to rewrite history that predates the rule.



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

    main is protected: 27 required status checks must pass before merge and enforce_admins is on, so the maintainer cannot bypass them either. The posture job compares the live settings with ADR 0053 on every push.



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

    Every pull request runs the full test suite (1,773 tests) plus the same suite against MySQL and MariaDB, an authenticated DAST scan, an accessibility scan and a real compose stack — 27 required checks in total.



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

    docs/ARCHITECTURE.md is an ISO/IEC 42010 style description: system context, stakeholders and their concerns, viewpoints and views, and correspondence rules between them. docs/DESIGN.md covers the user-facing side, and every decision links back to an ADR.



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

    docs/openapi.json describes the HTTP API and is generated from the code, with CI failing if it drifts. The CLI surface is documented in CONTRIBUTING.md and docs/OPERATIONS.md, and the plugin interfaces are specified in the ADRs they were introduced by.



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

    docs/RISK-ASSESSMENT.md holds a risk register with a documented likelihood x impact method and a machine-checked level formula. It sits alongside a full ASVS 5.0 L2 self-assessment (253 requirements) and an ISO/IEC 27001:2022 self-assessment (116 controls).



    プロジェクトの文書には、明確な対応期限を伴う、協調的な脆弱性開示(CVD)のポリシーを含めなければなりません(MUST)。 [OSPS-VM-01.01]
    ディレクトリのルートにSECURITY.mdファイルを作成し、プロジェクトの協調的脆弱性開示のポリシーを概説します。脆弱性を報告する方法を含めます。プロジェクトが報告された問題にどのように対応および対処するかについての期待を設定します。

    SECURITY.md is a coordinated disclosure policy with explicit timeframes: acknowledgement within 7 days, initial assessment within 14, and fixes within 7/30/90 days by severity. A test fails CI when a scheduled security review is overdue.



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

    GitHub private vulnerability reporting is enabled and SECURITY.md points to it as the primary channel, giving the reporter a private thread with the maintainer.



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

    Fixed vulnerabilities are published in CHANGELOG.md and in the release notes, naming each advisory; accepted-but-unfixed advisories are published with their reasoning in pins/accepted-advisories.txt, app/plugins/accepted-advisories.txt and deploy/accepted-image-advisories.txt, all of which CI checks in both directions.



ツールやAIシステムを使って、https://www.bestpractices.dev/ja/projects/14085/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforcedのような簡単なURLで変更を提案できます。その方法については、自動化提案システムをご覧ください。 このデータは、Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0)のもとで利用可能です。これは、データ受領者が、データ受領者がこの契約のテキストを共有データとともに利用可能にする限り、変更の有無にかかわらずデータを共有できることを意味します。SayamおよびOpenSSFベストプラクティスバッジのコントリビューターにクレジットを表示してください。

プロジェクト バッジ登録の所有者: Sayam.
エントリの作成日時 2026-08-15 04:13:43 UTC、 最終更新日 2026-08-29 02:24:01 UTC 最後に2026-08-16 00:34:59 UTCにバッジ合格を達成しました。