PR Metrics

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo básico na página do seu projeto! O status do selo básico se parece com isto: O nível do selo básico para o projeto 11987 é baseline-3 Aqui está como incorporar o selo básico:
Você pode mostrar o status do seu selo básico incorporando isto no seu arquivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/11987/baseline)](https://www.bestpractices.dev/projects/11987)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/11987"><img src="https://www.bestpractices.dev/projects/11987/baseline"></a>


Estes são os critérios de Nível Básico 2. Estes critérios são da versão de referência v2025.10.10 com texto de critérios atualizado da versão v2026.02.19. Os critérios novos na versão v2026.02.19 são rotulados como "futuros" e começarão a ser aplicados a partir de 2026-06-01. Por favor, forneça respostas para os critérios "futuros" antes dessa data.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

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

    Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.
    Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".
    O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

 Controles 18/19 ●

  • Controles


    Suficiente para um badge!

    Quando uma tarefa de CI/CD é executada sem permissões especificadas, o sistema de CI/CD DEVE definir como padrão as permissões da tarefa para as menores permissões concedidas no pipeline. [OSPS-AC-04.01]
    Configure as definições do projeto para atribuir as menores permissões disponíveis a novos pipelines por padrão, concedendo permissões adicionais somente quando necessário para tarefas específicas.

    All three GitHub Actions workflow files (build.yml at https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml, release-initiate.yml at https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/release-initiate.yml, release-publish.yml at https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/release-publish.yml) set permissions: {} at the top level, defaulting all jobs to no permissions. Individual jobs escalate only the specific permissions they require (e.g., pull-requests: write, attestations: write). This ensures that any job without an explicit permissions block receives the lowest available permissions.


    Suficiente para um badge!

    Quando um lançamento oficial é criado, esse lançamento DEVE receber um identificador de versão único. [OSPS-BR-02.01]
    Atribua um identificador de versão único a cada versão de lançamento produzida pelo projeto, seguindo uma convenção de nomenclatura ou esquema de numeração consistente. Exemplos incluem SemVer, CalVer ou id de commit git.

    Each release is assigned a unique Semantic Versioning (https://semver.org/) identifier (e.g., v1.7.11). The version is maintained consistently across package.json (https://github.com/microsoft/PR-Metrics/blob/main/package.json), task.json (https://github.com/microsoft/PR-Metrics/blob/main/src/task/task.json), and vss-extension.json (https://github.com/microsoft/PR-Metrics/blob/main/src/vss-extension.json). The Update-Version.ps1 script (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflow-scripts/Update-Version.ps1) ensures all version references are updated atomically during the release process.


    Suficiente para um badge!

    Quando um lançamento oficial é criado, esse lançamento DEVE conter um registro descritivo de modificações funcionais e de segurança. [OSPS-BR-04.01]
    Certifique-se de que todos os lançamentos incluam um registro de alterações descritivo. É recomendado garantir que o registro de alterações seja legível por humanos e inclua detalhes além das mensagens de commit, como descrições do impacto de segurança ou relevância para diferentes casos de uso. Para garantir a legibilidade por máquina, coloque o conteúdo sob um cabeçalho markdown como \"## Changelog\"."

    GitHub Releases include auto-generated change logs listing all merged pull requests with descriptive titles, author attributions, and links to full PR discussions. For example, the v1.7.11 release (https://github.com/microsoft/PR-Metrics/releases/tag/v1.7.11) includes a "What's Changed" section enumerating each functional modification and a "Full Changelog" comparison link between versions.


    Suficiente para um badge!

    Quando um pipeline de compilação e lançamento ingere dependências, ele DEVE usar ferramentas padronizadas quando disponíveis. [OSPS-BR-05.01]
    Use ferramentas comuns para o seu ecossistema, como gerenciadores de pacotes ou ferramentas de gerenciamento de dependências para ingerir dependências no momento da compilação. Isso pode incluir o uso de um arquivo de dependências, arquivo de bloqueio ou manifesto para especificar as dependências necessárias, que são então incorporadas pelo sistema de compilação.

    The project uses npm (https://www.npmjs.com/), the standard package manager for the Node.js ecosystem, to manage dependencies. package.json (https://github.com/microsoft/PR-Metrics/blob/main/package.json) declares direct dependencies, and package-lock.json (https://github.com/microsoft/PR-Metrics/blob/main/package-lock.json) pins the full transitive dependency tree for deterministic builds. Dependencies are resolved from the npm public registry via HTTPS.


    Suficiente para um badge!

    Quando um lançamento oficial é criado, esse lançamento DEVE ser assinado ou contabilizado em um manifesto assinado incluindo os hashes criptográficos de cada ativo. [OSPS-BR-06.01]
    Assine todos os ativos de software lançados no momento da construção com uma assinatura criptográfica ou atestados, como assinatura GPG ou PGP, assinaturas Sigstore, proveniência SLSA ou VSAs SLSA. Inclua os hashes criptográficos de cada ativo em um manifesto assinado ou arquivo de metadados.

    Release artefacts are signed using Sigstore (https://www.sigstore.dev/) keyless signing via cosign (https://github.com/sigstore/cosign), producing a .sigstore.json signature bundle alongside each VSIX release. Additionally, SLSA build provenance attestations (https://slsa.dev/) are generated using actions/attest-build-provenance (https://github.com/actions/attest-build-provenance), linking each artefact to a specific workflow run and commit. Verification instructions are documented in docs/verification.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/verification.md).


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir uma descrição de como o projeto seleciona, obtém e rastreia suas dependências. [OSPS-DO-06.01]
    É recomendado publicar essas informações juntamente com a documentação técnica e de design do projeto em um recurso publicamente visível, como o repositório de código-fonte, site do projeto ou outro canal.

    The project documents its dependency management practices in docs/dependency-management.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/dependency-management.md), covering how dependencies are selected, obtained from the npm registry, tracked via package.json and package-lock.json, updated through Dependabot (GitHub Actions) and npm-check-updates (npm packages), and scanned for security vulnerabilities via CodeQL and Dependabot alerts.


    Informações obrigatórias desconhecidas, insuficiente para um badge.

    (Critério futuro) A documentação do projeto DEVE incluir instruções sobre como compilar o software, incluindo bibliotecas, frameworks, SDKs e dependências necessários. [OSPS-DO-07.01]
    Recomenda-se publicar essas informações junto com a documentação de colaboradores do projeto, como em CONTRIBUTING.md ou outra documentação de tarefas de desenvolvimento. Isso também pode ser documentado usando alvos de Makefile ou outros scripts de automação.

    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE incluir uma lista de membros do projeto com acesso a recursos sensíveis. [OSPS-GV-01.01]
    Documente os participantes do projeto e seus papéis através de artefatos como members.md, governance.md, maintainers.md ou arquivo similar dentro do repositório de código-fonte do projeto. Isso pode ser tão simples quanto incluir nomes ou identificadores de conta em uma lista de mantenedores, ou mais complexo dependendo da governança do projeto.

    The GOVERNANCE.md file (https://github.com/microsoft/PR-Metrics/blob/main/GOVERNANCE.md) lists project members and teams with access to sensitive resources, including the @microsoft/omex code-owning team, the primary maintainer (@muiriswoulfe), repository maintainers, and automation accounts (Dependabot, CLA bot). The document describes the specific sensitive resources each role can access, such as release initiation, CI/CD configuration, and repository administration.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE incluir descrições dos papéis e responsabilidades dos membros do projeto. [OSPS-GV-01.02]
    Documente os participantes do projeto e seus papéis através de artefatos como members.md, governance.md, maintainers.md ou arquivo similar dentro do repositório de código-fonte do projeto.

    The GOVERNANCE.md file (https://github.com/microsoft/PR-Metrics/blob/main/GOVERNANCE.md) describes the roles within the project (Maintainer, Contributor, Automation) and their corresponding responsibilities, including PR review, release management, issue triage, security response, and automated dependency updates.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE incluir um guia para contribuidores de código que inclui requisitos para contribuições aceitáveis. [OSPS-GV-03.02]
    Estenda o conteúdo de CONTRIBUTING.md ou CONTRIBUTING/ na documentação do projeto para delinear os requisitos para contribuições aceitáveis, incluindo padrões de codificação, requisitos de testes e diretrizes de submissão para contribuidores de código. É recomendado que este guia seja a fonte da verdade tanto para contribuidores quanto para aprovadores.

    The CONTRIBUTING.md file (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md) outlines requirements for acceptable contributions, including the Contributor License Agreement (CLA) (https://opensource.microsoft.com/cla) requirement, coding style guidelines referencing the .editorconfig file (https://github.com/microsoft/PR-Metrics/blob/main/.editorconfig), Semantic Versioning requirements for version updates, the requirement to discuss new extensions via GitHub Issues before implementation, and submission guidelines. A pull request template (https://github.com/microsoft/PR-Metrics/blob/main/.github/pull_request_template.md) enforces structured submissions with testing checklists.


    Suficiente para um badge!

    Enquanto ativo, o sistema de controle de versão DEVE exigir que todos os contribuidores de código afirmem que estão legalmente autorizados a fazer as contribuições associadas em cada commit. [OSPS-LE-01.01]
    Inclua um DCO no repositório do projeto, exigindo que os contribuidores de código afirmem que estão legalmente autorizados a confirmar as contribuições associadas em cada commit. Use uma verificação de status para garantir que a afirmação seja feita. Um CLA também satisfaz este requisito. Alguns sistemas de controle de versão, como o GitHub, podem incluir isso nos termos de serviço da plataforma.

    The project requires all contributors to sign the Microsoft Contributor License Agreement (CLA) (https://opensource.microsoft.com/cla) before contributions are accepted. A CLA bot automatically checks each pull request and blocks merging until the agreement is signed. Per CONTRIBUTING.md (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md): "a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately." The CLA satisfies this requirement as an alternative to a Developer Certificate of Origin (DCO).


    Suficiente para um badge!

    Quando um commit é feito na branch primária, quaisquer verificações de status automatizadas para commits DEVEM passar ou ser manualmente ignoradas. [OSPS-QA-03.01]
    Configure o sistema de controle de versão do projeto para exigir que todas as verificações de status automatizadas passem ou exijam reconhecimento manual antes que um commit possa ser mesclado na branch primária. É recomendado que quaisquer verificações de status opcionais NÃO sejam configuradas como um requisito de aprovação ou reprovação que os aprovadores possam ser tentados a ignorar.

    The repository is protected by multiple rulesets (default-ruleset, microsoft-production-ruleset) that prevent direct commits to the main branch and require pull request reviews. CI/CD workflows (build.yml at https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml) run automated status checks on every pull request, including unit tests, linting, CodeQL analysis, and Super-Linter validation. These checks must pass before a pull request can be merged. See repository rulesets at https://github.com/microsoft/PR-Metrics/rules.


    Suficiente para um badge!

    Antes de um commit ser aceito, os pipelines de CI/CD do projeto DEVEM executar pelo menos um conjunto de testes automatizados para garantir que as alterações atendam às expectativas. [OSPS-QA-06.01]
    Testes automatizados devem ser executados antes de cada mesclagem na branch primária. O conjunto de testes deve ser executado em um pipeline de CI/CD e os resultados devem ser visíveis a todos os contribuidores. O conjunto de testes deve ser executado em um ambiente consistente e deve ser executado de uma maneira que permita aos contribuidores executar os testes localmente. Exemplos de conjuntos de testes incluem testes unitários, testes de integração e testes de ponta a ponta.

    The build.yml workflow (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml) runs a comprehensive automated test suite on every pull request to the main branch. The test suite uses Mocha (https://mochajs.org/) for unit testing with c8 (https://github.com/bcoe/c8) code coverage reporting. Tests can be run locally via "npm test" from the src/task folder, as documented in docs/development.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/development.md). Additional CI checks include CodeQL security analysis, ESLint, and Super-Linter.


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir documentação de design demonstrando todas as ações e atores dentro do sistema. [OSPS-SA-01.01]
    Inclua designs na documentação do projeto que expliquem as ações e atores. Atores incluem qualquer subsistema ou entidade que possa influenciar outro segmento no sistema. Certifique-se de que isso seja atualizado para novos recursos ou mudanças que quebrem compatibilidade.

    The project includes comprehensive design documentation: docs/cross-platform-architecture.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/cross-platform-architecture.md) contains a Mermaid diagram illustrating the system's actors (PR Metrics, API wrappers, Azure DevOps APIs, GitHub APIs) and the flow of API calls between them, and describes how platform abstraction layers route requests to the appropriate platform implementation. docs/development.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/development.md) explains the internal architecture, including the repos and runners wrapper abstractions, dependency injection patterns, and the build process. AGENTS.md (https://github.com/microsoft/PR-Metrics/blob/main/AGENTS.md) provides a detailed architectural overview of all core components, their interactions, and integration points.


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, a documentação do projeto DEVE incluir descrições de todas as interfaces de software externas dos ativos de software lançados. [OSPS-SA-02.01]
    Documente todas as interfaces de software (APIs) dos ativos de software lançados, explicando como os usuários podem interagir com o software e quais dados são esperados ou produzidos. Certifique-se de que isso seja atualizado para novos recursos ou mudanças que quebrem compatibilidade.

    All external software interfaces are documented: The README.md (https://github.com/microsoft/PR-Metrics/blob/main/README.md) documents all input parameters (base-size, growth-rate, test-factor, file-matching-patterns, test-matching-patterns, code-file-extensions), their default values, and usage examples for both GitHub Actions and Azure DevOps Pipelines. action.yml (https://github.com/microsoft/PR-Metrics/blob/main/action.yml) formally defines the GitHub Action's input interface. src/task/task.json (https://github.com/microsoft/PR-Metrics/blob/main/src/task/task.json) formally defines the Azure DevOps task's input interface. docs/azure-pipelines-task.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/azure-pipelines-task.md) provides platform-specific configuration and authentication documentation.


    Suficiente para um badge!

    Quando o projeto tiver feito um lançamento, o projeto DEVE realizar uma avaliação de segurança para compreender os problemas de segurança potenciais mais prováveis e impactantes que poderiam ocorrer dentro do software. [OSPS-SA-03.01]
    Realizar uma avaliação de segurança informa tanto os membros do projeto quanto os consumidores a jusante que o projeto compreende quais problemas poderiam surgir dentro do software. Compreender quais ameaças poderiam se concretizar ajuda o projeto a gerenciar e tratar riscos. Essa informação é útil para os consumidores a jusante demonstrarem a perspicácia e as práticas de segurança do projeto. Certifique-se de que isso seja atualizado para novos recursos ou mudanças disruptivas.

    A security assessment is documented in docs/security-assessment.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/security-assessment.md), which identifies the system's trust boundaries, sensitive assets, and the most likely and impactful security threats, including access token exposure, injection via untrusted PR content, supply chain attacks on dependencies, CI/CD permission escalation, and Git command injection. Each threat includes a likelihood and impact rating, along with the specific mitigations in place.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE incluir uma política para divulgação coordenada de vulnerabilidades (CVD), com um prazo claro para resposta. [OSPS-VM-01.01]
    Crie um arquivo SECURITY.md na raiz do diretório, descrevendo a política do projeto para divulgação coordenada de vulnerabilidades. Inclua um método para relatar vulnerabilidades. Estabeleça expectativas sobre como o projeto responderá e tratará problemas relatados.

    The SECURITY.md file (https://github.com/microsoft/PR-Metrics/blob/main/SECURITY.md) documents the project's coordinated vulnerability disclosure (CVD) policy, following Microsoft's CVD principles (https://www.microsoft.com/msrc/cvd). The policy directs reporters to the Microsoft Security Response Center (MSRC) (https://msrc.microsoft.com/create-report) and includes a clear response timeframe: "You should receive a response within 24 hours."


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE fornecer um meio para relato privado de vulnerabilidades diretamente aos contatos de segurança dentro do projeto. [OSPS-VM-03.01]
    Forneça um meio para que pesquisadores de segurança relatem vulnerabilidades privadamente ao projeto. Isso pode ser um endereço de e-mail dedicado, um formulário web, ferramentas especializadas do VCS, endereços de e-mail para contatos de segurança ou outros métodos.

    The SECURITY.md file (https://github.com/microsoft/PR-Metrics/blob/main/SECURITY.md) provides two mechanisms for private vulnerability reporting: The MSRC web form (https://msrc.microsoft.com/create-report) for authenticated submissions. Email to secure@microsoft.com with optional PGP encryption using the MSRC PGP key (https://aka.ms/opensource/security/pgpkey). Both methods ensure that vulnerability details remain confidential until a fix is available.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE publicar publicamente dados sobre vulnerabilidades descobertas. [OSPS-VM-04.01]
    Forneça informações sobre vulnerabilidades conhecidas em um canal público previsível, como uma entrada CVE, postagem em blog ou outro meio. Na medida do possível, essa informação deve incluir versão(ões) afetada(s), como um consumidor pode determinar se está vulnerável e instruções para mitigação ou remediação.

    The project uses GitHub Security Advisories (https://github.com/microsoft/PR-Metrics/security/advisories) as the public channel for publishing data about discovered vulnerabilities. Microsoft also publishes security information through the MSRC portal (https://msrc.microsoft.com/). No vulnerabilities have been discovered or disclosed for this project to date; however, the infrastructure for publishing advisory data is in place and operational.



Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Muiris Woulfe e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Muiris Woulfe.
Entrada criada em 2026-02-19 17:32:37 UTC, última atualização em 2026-02-27 19:06:06 UTC. Selo de aprovação perdido pela última vez em 2026-02-23 14:15:17 UTC. Selo de aprovação alcançado pela última vez em 2026-02-23 14:43:51 UTC.