flask-todolist

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

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

如果这是您的项目,请在项目页面上显示您的基准徽章状态!基准徽章状态如下所示: 项目14085的基准徽章等级为baseline-2 以下是如何嵌入基准徽章:
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态:
[![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)”。
    如果有多种语言,请将它们列为逗号分隔值(可选空格),并将它们从最多到最少使用。如果有长列表,请至少列出前三个最常见的列表。如果没有语言(例如,这是仅文档或仅测试项目),请使用单个字符“ - ”。请使用每种语言的常规大小写,例如“JavaScript”。
    通用平台枚举(CPE)是用于信息技术系统,软件和软件包的结构化命名方案。在报告漏洞时,它可用于多个系统和数据库。

 控制 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提交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]
    确保所有发布都包含描述性的变更日志。建议确保变更日志是人类可读的,并且包含超出提交消息的详细信息,例如安全影响的描述或与不同用例的相关性。为确保机器可读性,请将内容放在markdown标题下,例如"## Changelog"。

    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.



    项目文档必须包含有权访问敏感资源的项目成员列表。 [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.



    项目文档必须包含对项目成员角色和职责的描述 [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.



    项目文档必须包含面向代码贡献者的指南,其中包含可接受贡献的要求。 [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.



    版本控制系统必须要求所有代码贡献者在每次提交时都声明他们在法律上有权作出相关贡献。 [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管道必须运行至少一个自动化测试套件,以确保更改符合预期。 [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)政策,并明确响应的时间框架。 [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.



    项目文档必须提供一种方式,让贡献者能够直接向项目内的安全联系人私下报告漏洞。 [OSPS-VM-03.01]
    为安全研究人员提供一种方式,以私下向项目报告漏洞。这可能是专用电子邮件地址、Web表单、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.



    项目文档必须公开发布已发现漏洞的相关数据。 [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系统通过简单的URL提交变更建议,例如 https://www.bestpractices.dev/zh-CN/projects/14085/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced。请参阅我们的自动化提案系统,了解具体操作方法。 该数据可在社区数据许可协议 – 许可性,版本 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 获得通过徽章。