PR Metrics

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

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

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目11987的徽章级别为silver 这里是如何嵌入它：
您可以通过将其嵌入在您的Markdown文件中：
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/11987/badge)](https://www.bestpractices.dev/projects/11987)
或将其嵌入到HTML中来显示您的徽章状态：
<a href="https://www.bestpractices.dev/projects/11987"><img src="https://www.bestpractices.dev/projects/11987/badge"></a>


这些是黄金级别条款。您还可以查看通过或白银级别条款。

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

        

 基本 4/5 ●

  • 常规

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

    A GitHub Action & Azure Pipelines task for augmenting pull request titles to let reviewers quickly determine PR size and test coverage.

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

  • 先决条件


    足够获得徽章！

    该项目必须拥有银级徽章。 [achieve_silver]

  • 项目监督


    足够获得徽章！

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]
    “公交车系数”（又名“卡车因子”）是指最少数量的项目成员，如果突然离开项目（“被公交车撞了”），项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息，请参阅Cosentino等人的评估Git存储库的卡车因子。

    Hosted under the microsoft GitHub organisation with the @microsoft/omex team designated as code owners, providing team-level access rather than individual dependency. See https://github.com/microsoft/PR-Metrics.


    不足以获得徽章。

    该项目必须至少有两个不相关的重要贡献者。 (需要网址) [contributors_unassociated]
    如果同一组织（作为雇员或承包商）支付工作费用，并且组织将从项目的结果中受益，则贡献者是相关联的。如果通过其他组织得到财务补助（例如，源自政府或非政府组织，支付给不同组织的科学补助金不会导致捐助者关联），不视为来自同一组织。重要贡献者定义为过去一年对项目做出了不平凡的贡献。一个重要贡献者的良好指标的例子是：编写至少1,000行代码，贡献50个提交或至少提交20页的文档。

    The project does not have at least two unassociated significant contributors. The primary contributor is a Microsoft employee, and the project resides under the Microsoft GitHub organisation (https://github.com/microsoft/PR-Metrics). One external contributor (Gordon Beeming from SSW) has made contributions, but with only 1 commit, this does not meet the threshold of a "significant contributor" (e.g., at least 50 commits or 1,000 lines of code in the past year).


  • 其他


    足够获得徽章！

    项目必须在每个源文件中包含许可证声明。这可以通过在每个文件开头附近的注释中加入以下内容来实现： SPDX-License-Identifier: [SPDX license expression for project]。 [license_per_file]
    这可以通过在自然语言中包含许可证标识来完成。该项目还可以包括完整许可证文本，或者指向许可证文本的稳定URL。请注意，license_location条款要求项目许可证在标准位置。有关SPDX许可证表达式的更多信息，请参阅SPDX教程。请注意与 copyright_per_file 的关系，其内容通常在许可证信息之前。

    All source files include a license statement identifying the MIT License: "Licensed under the MIT License." This is present in all TypeScript source and test files, all GitHub Actions workflow YAML files, and all configuration files. See, for example, src/task/src/pullRequestMetrics.ts (https://github.com/microsoft/PR-Metrics/blob/main/src/task/src/pullRequestMetrics.ts) and .github/workflows/build.yml (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml).


 变更控制 4/4 ●

  • 公开的版本控制的源代码存储库


    足够获得徽章！

    必须使用通用的分布式版本控制软件（例如，git，mercurial）作为项目的源代码存储库。 [repo_distributed]
    Git不是必须，项目在合适场景可以使用集中版本控制软件（如subversion）。

    The project is hosted on GitHub (https://github.com/microsoft/PR-Metrics), which uses Git, a distributed version control system.


    足够获得徽章！

    该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 (需要网址) [small_tasks]
    此标识通常通过在项目使用的一个或多个标签的问题跟踪器中标记所选问题来完成，例如 up- for-grabs ，仅限第一时间，“小修复”，微任务或IdealFirstBug。这些新任务不需要添加功能；他们可以改进文档，添加测试用例或其他有助于项目的内容，并帮助贡献者更了解项目。

    The project uses the "good first issue" (https://github.com/microsoft/PR-Metrics/labels/good%20first%20issue) and "help wanted" (https://github.com/microsoft/PR-Metrics/labels/help%20wanted) labels to identify tasks suitable for new or casual contributors.


    足够获得徽章！

    项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如SMS（短消息），尽管不推荐。 [require_2FA]

    The project is hosted under the Microsoft GitHub organisation (https://github.com/microsoft), which enforces two-factor authentication for all members. GitHub requires 2FA for all contributors to public repositories in organisations that enforce this policy.


    足够获得徽章！

    项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 [secure_2FA]
    满足此条款的2FA机制将是一种基于时间的一次性密码（TOTP）应用程序，可自动生成在一段时间后更改的验证码。请注意， GitHub支持TOTP 。

    GitHub supports and recommends cryptographic 2FA mechanisms, including TOTP (Time-based One-Time Password) applications and hardware security keys (e.g., FIDO2/WebAuthn). The Microsoft GitHub organisation enforces 2FA, and GitHub's 2FA implementation supports cryptographic mechanisms. SMS-only 2FA is not the default.


 质量 7/7 ●

  • 编码标准


    足够获得徽章！

    该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 (需要网址) [code_review_standards]
    另请参阅 two_person_review 和contribution_requirements 条款。

    The project documents its code review requirements in the CONTRIBUTING.md file (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md), which specifies coding style requirements (via .editorconfig at https://github.com/microsoft/PR-Metrics/blob/main/.editorconfig) and contribution workflows. Additionally, the AGENTS.md file (https://github.com/microsoft/PR-Metrics/blob/main/AGENTS.md) documents detailed code standards including strict ESLint rules, explicit type requirements, member ordering, and testing patterns. The CODEOWNERS file (https://github.com/microsoft/PR-Metrics/blob/main/.github/CODEOWNERS) ensures that the @microsoft/omex team reviews all changes.


    足够获得徽章！

    该项目必须至少有50％的修改（作者之外的人提出的）在发布之前审查，以确定是否是一个有价值的修改，并且没有已知的问题，会反对其包含 [two_person_review]

    All changes are reviewed by someone other than the author and this requirement is enforced via GitHub settings.


  • 可工作的构建系统


    足够获得徽章！

    该项目必须具有可重复构建。如果没有发生构建（例如，直接使用源代码而不是编译的脚本语言），请选择“不适用”（N/A）。 (需要网址) [build_reproducible]
    可重复的构建意味着多方可以独立地重做从源文件生成信息的过程，并获得每比特完全相同的结果。在某些情况下，这可以通过强制某种排序来解决。 JavaScript开发人员可能会考虑使用npm shrinkwrap和webpack的OccurenceOrderPlugin。 GCC和clang用户可能会发现-frandom-seed选项有用。通常可以通过指定可用于重新构建的特定容器或虚拟机的加密散列来为外部方定义构建环境（包括工具集）。 可重复构建项目具有文档指导如何执行此操作。

    The project uses npm ci (which installs exact versions from package-lock.json at https://github.com/microsoft/PR-Metrics/blob/main/package-lock.json) and pins a specific Node.js version (20.17.0) in CI. The build process uses @vercel/ncc (https://github.com/vercel/ncc) to bundle the output deterministically. All GitHub Actions dependencies are pinned to exact commit SHAs. See .github/workflows/build.yml (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml).


  • 自动测试套件


    足够获得徽章！

    测试套件必须以该语言的标准方式进行调用。 (需要网址) [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

    The test suite is invocable via the standard "npm run test" command, as defined in package.json (https://github.com/microsoft/PR-Metrics/blob/main/package.json). Tests use Mocha (https://mochajs.org/) as the test framework with c8 (https://github.com/bcoe/c8) for code coverage.


    足够获得徽章！

    该项目必须实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 (需要网址) [test_continuous_integration]
    在大多数情况下，这意味着每个在项目上全职工作的开发人员至少每天都会整合。

    The project implements continuous integration via GitHub Actions (https://github.com/microsoft/PR-Metrics/actions). The build.yml workflow (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml) runs on every push to main, on all pull requests to main, on a weekly schedule, and on manual dispatch. It executes the full build and test suite.


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少90％语句覆盖率。 [test_statement_coverage90]

    The project enforces 100% statement coverage via .c8rc.json (https://github.com/microsoft/PR-Metrics/blob/main/.c8rc.json), which sets "statements": 100. The CI build fails if this threshold is not met. c8 is a FLOSS tool capable of measuring statement coverage for TypeScript/JavaScript.


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少80％分支覆盖率。 [test_branch_coverage80]

    The project enforces 100% branch coverage via .c8rc.json (https://github.com/microsoft/PR-Metrics/blob/main/.c8rc.json), which sets "branches": 100. The CI build fails if this threshold is not met. c8 is a FLOSS tool capable of measuring branch coverage for TypeScript/JavaScript.


 安全 5/5 ●

  • 使用基础的良好加密实践

    请注意，某些软件不需要使用加密机制。

    足够获得徽章！

    项目生成的软件必须支持所有网络通信的安全协议，如SSHv2或更高版本，TLS1.2或更高版本（HTTPS），IPsec，SFTP和SNMPv3。默认情况下，FTP，HTTP，Telnet，SSLv3或更早版本以及SSHv1等不安全协议必须被禁用，只有在用户专门配置时才启用。如果项目生成的软件不支持网络通信，请选择“不适用”（N/A）。 [crypto_used_network]

    All network communications use HTTPS. The project uses axios and Octokit libraries, which default to HTTPS for GitHub and Azure DevOps API calls.


    足够获得徽章！

    由项目生成的软件必须，如果支持或使用TLS，至少支持TLS版本1.2。请注意，TLS的前身称为SSL。如果软件不使用TLS，请选择“不适用”（N/A）。 [crypto_tls12]

    The project requires Node.js 20.17.0+, which supports TLS 1.2 and later by default.


  • 安全交付防御中间人（MITM）的攻击


    足够获得徽章！

    项目网站，存储库（如果可通过网络访问）和下载站点（如果单独）必须包括具有非允许值的密钥加固头。 (需要网址) [hardened_site]
    请注意，GitHub是已知满足的。 https://securityheaders.io/ 等网站可以快速查看。主要头加固包含：内容安全策略（CSP），HTTP严格传输安全性（HSTS），X-Content-Type-Options（“nosniff”），X-Frame-Options和X-XSS-Protection。

    The project is hosted on GitHub (https://github.com/microsoft/PR-Metrics), which includes all required security hardening headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (nosniff), and X-Frame-Options. GitHub is known to meet this criterion (https://www.bestpractices.dev/en/criteria?details=true&rationale=true#0.hardened_site).


  • 其他安全问题


    足够获得徽章！

    该项目必须在过去5年内进行安全审查。此审查必须考虑安全需求和安全边界。 [security_review]
    这可以由项目成员完成和/或独立评估。此评估可能由静态和动态分析工具支持，但还必须进行人工审查，以确定工具无法检测到的问题（特别是设计问题）。

    A human-led formal security review was undertaken for the project. In addition, the project uses automated security analysis tools (CodeQL with security-extended queries, Gitleaks for secret scanning, Dependabot for dependency vulnerabilities).


    足够获得徽章！

    加固机制必须用于项目生产的软件，以便软件缺陷不太可能导致安全漏洞。 (需要网址) [hardening]
    加固机制可能包括HTTP头，如内容安全策略（CSP），用于减轻攻击的编译器标志（如-fstack-protector）或用以消除未定义行为的编译器标志。对于此条款的目的，最小权限不被认为是一种加固机制（最少权限是重要的，但是另有条款）。

    The project employs several hardening mechanisms: Input validation – all external inputs (environment variables, user inputs) are validated via the validator.ts module (https://github.com/microsoft/PR-Metrics/blob/main/src/task/src/utilities/validator.ts) before use, including in Git command construction (gitInvoker.ts at https://github.com/microsoft/PR-Metrics/blob/main/src/task/src/git/gitInvoker.ts). Strict TypeScript – the project uses strictTypeChecked ESLint rules and strict TypeScript compiler settings, reducing the risk of type-related vulnerabilities. Dependency pinning – all GitHub Actions dependencies are pinned to exact commit SHAs in workflow files, preventing supply chain attacks via tag mutation. Minimal permissions – GitHub Actions workflows use permissions: {} at the workflow level and grant only the minimum required permissions per job. Secret scanning – Gitleaks is configured to detect accidentally committed secrets. Signed releases – releases are signed with cosign (https://github.com/sigstore/cosign) and include build provenance attestation via actions/attest-build-provenance (https://github.com/actions/attest-build-provenance).


 分析 2/2 ●

  • 动态代码分析


    足够获得徽章！

    必须在发布之前，至少将一个动态分析工具应用于软件任何候选发布的主要生产版本。 [dynamic_analysis]
    动态分析工具通过执行特定输入来检查软件。例如，项目可以使用模糊工具（例如， American Fuzzy Lop ）或Web应用扫描程序（例如， ZAP 或 w3af ）。在某些情况下， OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款，动态分析工具需要以某种方式改变输入，以寻找各种问题，或者将其作为一个具有至少80％分支覆盖率的自动测试套件。 动态分析维基百科页面和 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞，但这不是必需的。

    Property-based testing with fast-check (a fuzzing/property-based testing framework) is run as part of the test suite on every build. The test suite achieves 100% branch coverage, exceeding the 80% threshold for this criterion.


    足够获得徽章！

    项目应该在其生成的软件中包含许多运行时断言，并在动态分析期间检查这些断言。 [dynamic_analysis_enable_assertions]
    这个标准并不建议使生产过程中的断言;这完全取决于项目及其用户的决定。该标准的重点是在部署之前的动态分析过程中改善故障检测。在生产使用中启用断言与在动态分析（例如测试）期间启用断言完全不同。在某些情况下，在生产中使用断言是极其不明智的（尤其是在高完整性组件中）。存在许多反对在生产环境中启用断言的论点，例如，库不应使调用程序崩溃，它们的存在可能会导致应用商店拒绝，和/或在生产环境中激活断言可能会暴露诸如私钥之类的私有数据。请注意，在许多Linux发行版中都未定义NDEBUG ，因此C / C ++缺省情况下，assert（）将在这些环境中启用生产。对于那些环境中的生产，使用不同的断言机制或定义NDEBUG可能很重要。

    The test suite includes extensive assertions via Mocha/assert. Property-based tests with fast-check generate diverse inputs and assert invariants. TypeScript strict mode and runtime input validation provide additional assertion-like checks.



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

项目徽章条目拥有者： Muiris Woulfe.
最后更新于 2026-02-19 17:32:37 UTC, 最后更新于 2026-07-20 12:02:23 UTC。 最后在2026-02-23 14:15:17 UTC丢失通过徽章。 最后在 2026-02-23 14:43:51 UTC 获得通过徽章。