wdm

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

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

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


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

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

        

 基本

  • 常规

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

    Webnestify Docker Manager

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

    wdm is a Go CLI/TUI for managing a curated set of Docker Compose self-hosting templates. The project is maintained in the public GitHub repository at
    https://github.com/wnstify/wdm, with releases, verification instructions, security policy, contributor guidance, CI, CodeQL, govulncheck, Scorecard, and signed release
    assets.

 控制 21/21 ●

  • 控制


    足够获得徽章！

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

    GitHub Actions permissions are explicitly scoped per workflow/job. The default workflow permission is contents: read; privileged permissions such as contents: write, id-token: write, and attestations: write are limited to the tag-gated signed-release job that needs them to publish release assets, mint provenance, and
    create the GitHub Release.


    足够获得徽章！

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

    The release workflow validates trusted collaborator-provided tag input before using it for version stamping or release creation. Tag releases must match the supported
    vMAJOR.MINOR.PATCH format, and publishing is gated to push events on refs/tags/v* in wnstify/wdm. See:
    https://github.com/wnstify/wdm/blob/main/.github/workflows/release.yml


    足够获得徽章！

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

    Release assets are published under a unique Git tag such as v1.0.0. The binary is stamped with the tag version, the GitHub Release is created with that tag, and the
    release assets are tied together by SHA256SUMS, SHA256SUMS.sig, SHA256SUMS.cosign.bundle, provenance, and the changelog entry for that release.


    足够获得徽章！

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

    SECURITY.md defines the secrets and credentials policy, including what must not be committed, where repository and release credentials are stored, which jobs can access
    release signing material, and when secrets must be rotated. See: https://github.com/wnstify/wdm/blob/main/SECURITY.md#secrets-and-credentials


    足够获得徽章！

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

    SECURITY.md documents how to verify release integrity and authenticity using the signed SHA256SUMS, the detached Ed25519 signature, the cosign bundle, checksum
    verification, and the SLSA provenance attestation.


    足够获得徽章！

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

    SECURITY.md documents the expected release identity: source repository wnstify/wdm, OIDC issuer https://token.actions.githubusercontent.com, release workflow
    .github/workflows/release.yml, and the tag-scoped certificate identity for releases.


    足够获得徽章！

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

    README.md documents the release support lifecycle. Each stable release is supported until the next stable release is published, and the support scope covers the wdm
    binary, release verification assets, catalog bundle, and curated templates. See: https://github.com/wnstify/wdm/blob/main/README.md#release-support-lifecycle


    足够获得徽章！

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

    README.md states that only the latest stable release receives security fixes and that older releases become unsupported when a newer stable release is published. See:
    https://github.com/wnstify/wdm/blob/main/README.md#release-support-lifecycle


    足够获得徽章！

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

    SECURITY-DESIGN.md documents collaborator access review before granting write, admin, release, secret, or ruleset access. It requires least privilege and removal of
    escalated access when no longer needed. See: https://github.com/wnstify/wdm/blob/main/SECURITY-DESIGN.md#collaborator-access-review


    足够获得徽章！

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

    The release workflow generates an SPDX 2.3 JSON SBOM for the compiled wdm-linux-amd64 binary and publishes it as wdm-linux-amd64.spdx.json. SECURITY.md lists it as
    one of the release assets. See: https://github.com/wnstify/wdm/blob/main/.github/workflows/release.yml and
    https://github.com/wnstify/wdm/blob/main/SECURITY.md#artifacts


    足够获得徽章！

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

    The project release is built from a single source repository, wnstify/wdm. There are no release subprojects spread across multiple source code repositories, so this
    control does not apply. Repository: https://github.com/wnstify/wdm


    足够获得徽章！

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

    CONTRIBUTING.md documents how tests are run locally and explains that GitHub Actions run required unit, lint, vulnerability, static-analysis, and DCO checks on pull
    requests and pushes. See: https://github.com/wnstify/wdm/blob/main/CONTRIBUTING.md#build-and-test


    足够获得徽章！

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

    CONTRIBUTING.md requires major functional changes to add or update automated tests for the changed behavior, or explain why automated coverage is not practical and
    describe manual verification. See: https://github.com/wnstify/wdm/blob/main/CONTRIBUTING.md#build-and-test


    足够获得徽章！

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

    The project is currently maintained by a single human maintainer, so there is no eligible non-author human reviewer with project write access. The main branch is still protected: direct commits are blocked, required status checks must pass, commits must be signed, DCO signoff is required, and review threads must be resolved before merge.


    足够获得徽章！

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

    SECURITY-DESIGN.md documents threat modeling and attack surface analysis, including actors, actions, external interfaces, trust boundaries, critical paths, likely
    risks, and mitigations. It also states when the model must be updated. See:
    https://github.com/wnstify/wdm/blob/main/SECURITY-DESIGN.md#threat-modeling-and-attack-surface-analysis


    足够获得徽章！

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

    SECURITY.md requires vulnerabilities in components that do not affect wdm to be documented as VEX statements, including component, version, vulnerability identifier,
    affected version or commit range, status, and justification. See: https://github.com/wnstify/wdm/blob/main/SECURITY.md#dependency-and-static-analysis-findings


    足够获得徽章！

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

    SECURITY.md defines SCA and license remediation thresholds. go mod verify, go mod tidy -diff, Dependabot alerts, and govulncheck are treated as SCA inputs;
    reachable govulncheck findings, module verification failures, unexpected module drift, and incompatible or unknown direct/runtime dependency licenses block merge or
    release until resolved or documented. See: https://github.com/wnstify/wdm/blob/main/SECURITY.md#dependency-and-static-analysis-findings


    足够获得徽章！

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

    SECURITY.md states that no official release may be cut while required security checks are failing or while unresolved release-blocking SCA, malicious-dependency, or
    license findings affect the release. See: https://github.com/wnstify/wdm/blob/main/SECURITY.md#dependency-and-static-analysis-findings


    足够获得徽章！

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

    Dependency changes are automatically evaluated by CI through go mod verify, go mod tidy -diff, and govulncheck; required branch checks block merge when these
    checks fail. The documented policy requires release-blocking findings to be fixed or documented as non-exploitable. See:
    https://github.com/wnstify/wdm/blob/main/.github/workflows/lint.yml, https://github.com/wnstify/wdm/blob/main/.github/workflows/security.yml, and
    https://github.com/wnstify/wdm/blob/main/SECURITY.md#dependency-and-static-analysis-findings


    足够获得徽章！

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

    SECURITY.md defines the SAST remediation threshold. CodeQL and security-relevant linter findings are SAST inputs; critical SAST findings block merge and release, while
    high and medium findings must be fixed, downgraded with written rationale, or tracked before the next stable release. See:
    https://github.com/wnstify/wdm/blob/main/SECURITY.md#dependency-and-static-analysis-findings


    足够获得徽章！

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

    Changes are automatically evaluated by CodeQL and security-relevant linting in GitHub Actions. The main branch requires the CodeQL analyze-go check, and SECURITY.md
    documents that release-blocking SAST findings must be fixed or narrowly documented before merge or release. See:
    https://github.com/wnstify/wdm/blob/main/.github/workflows/codeql.yml, https://github.com/wnstify/wdm/blob/main/.github/workflows/lint.yml, and
    https://github.com/wnstify/wdm/blob/main/SECURITY.md#dependency-and-static-analysis-findings



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

项目徽章条目拥有者： Simon Gajdosik.
最后更新于 2026-06-18 06:21:41 UTC, 最后更新于 2026-06-22 16:56:13 UTC。 最后在 2026-06-18 07:31:42 UTC 获得通过徽章。