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 1. Estes são critérios da versão v2026.02.19.

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 23/24 ●

  • Controles


    Suficiente para um badge!

    Quando um usuário tentar ler ou modificar um recurso sensível no repositório autorizado do projeto, o sistema DEVE exigir que o usuário complete um processo de autenticação multifator. [OSPS-AC-01.01]
    Imponha autenticação multifator para o sistema de controle de versão do projeto, exigindo que os colaboradores forneçam uma segunda forma de autenticação ao acessar dados sensíveis ou modificar configurações do repositório. Passkeys são aceitáveis para este controle.

    GitHub has required two-factor authentication for all contributors since March 2023. The Microsoft GitHub organisation enforces additional authentication policies. See GitHub's 2FA requirement announcement: https://github.blog/news-insights/product-news/raising-the-bar-for-software-security-github-2fa-begins-march-13/.


    Suficiente para um badge!

    Quando um novo colaborador for adicionado, o sistema de controle de versão DEVE exigir atribuição manual de permissão, ou restringir as permissões do colaborador aos menores privilégios disponíveis por padrão. [OSPS-AC-02.01]
    A maioria dos sistemas públicos de controle de versão são configurados desta maneira. Certifique-se de que o sistema de controle de versão do projeto sempre atribua as menores permissões disponíveis aos colaboradores por padrão quando adicionados, concedendo permissões adicionais somente quando necessário.

    GitHub assigns read-only access by default to new collaborators on public repositories. The Microsoft GitHub organisation enforces least-privilege policies for collaborator access. Additional permissions require manual assignment by repository administrators.


    Suficiente para um badge!

    Quando uma confirmação direta for tentada no ramo principal do projeto, um mecanismo de aplicação DEVE impedir que a mudança seja aplicada. [OSPS-AC-03.01]
    Se o VCS for centralizado, defina proteção de ramo no ramo principal no VCS do projeto. Alternativamente, use uma abordagem descentralizada, como a do kernel Linux, onde as mudanças são primeiro propostas em outro repositório, e mesclar mudanças no repositório principal requer um ato separado específico.

    The repository has multiple rulesets protecting the main branch (default-ruleset, microsoft-production-ruleset), which prevent direct commits and require pull request reviews. See repository rulesets: https://github.com/microsoft/PR-Metrics/rules.


    Suficiente para um badge!

    Quando for feita uma tentativa de excluir o ramo principal do projeto, o sistema de controle de versão DEVE tratar isso como uma atividade sensível e exigir confirmação explícita de intenção. [OSPS-AC-03.02]
    Defina proteção de ramo no ramo principal no sistema de controle de versão do projeto para evitar exclusão.

    The GitHub rulesets protecting the main branch prevent branch deletion. GitHub treats branch deletion of protected branches as a sensitive activity requiring explicit administrator override. See repository rulesets: https://github.com/microsoft/PR-Metrics/rules.


    Suficiente para um badge!

    Quando um pipeline de CI/CD aceitar um parâmetro de entrada, esse parâmetro DEVE ser sanitizado e validado antes de ser usado no pipeline. [OSPS-BR-01.01]
    Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de metadados que correspondam a fontes não confiáveis. Isso inclui dados como nomes de branch, mensagens de commit, tags, títulos de pull requests e informações de autoria.

    The project's CI/CD workflows (build.yml, release-initiate.yml, release-publish.yml) do not define any user-controllable input parameters via workflow_dispatch inputs. All workflow triggers use event-based activation with no externally supplied parameters.


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

    Quando um pipeline de CI/CD opera em snapshots de código não confiável, ele DEVE impedir o acesso a credenciais e ativos privilegiados de CI/CD. [OSPS-BR-01.03]
    Os pipelines de CI/CD devem isolar snapshots de código não confiável de credenciais e ativos privilegiados. Em particular, os projetos devem ter cuidado para garantir que os workflows que compilam ou executam código antes da revisão por um colaborador não tenham acesso às credenciais de CI/CD.

    Suficiente para um badge!

    Quando o projeto listar um URI como um canal oficial do projeto, esse URI DEVE ser entregue exclusivamente usando canais criptografados. [OSPS-BR-03.01]
    Configure os sites do projeto e os sistemas de controle de versão para usar canais criptografados como SSH ou HTTPS para transmissão de dados. Certifique-se de que todas as ferramentas e domínios referenciados na documentação do projeto só possam ser acessados por meio de canais criptografados.

    All URIs referenced in project documentation, README, and configuration files use HTTPS exclusively. The project's GitHub repository URL is https://github.com/microsoft/PR-Metrics. All external links (e.g., aka.ms redirects, Microsoft documentation) use HTTPS.


    Suficiente para um badge!

    Quando o projeto listar um URI como um canal oficial de distribuição, esse URI DEVE ser entregue exclusivamente usando canais criptografados. [OSPS-BR-03.02]
    Configure o pipeline de lançamento do projeto para buscar dados apenas de sites, respostas de API e outros serviços que usam canais criptografados como SSH ou HTTPS para transmissão de dados.

    The release pipeline fetches all dependencies and tools via HTTPS (npm registry, GitHub API, GitHub Actions). Release artefacts are published via GitHub Releases and the Visual Studio Marketplace, both of which use HTTPS exclusively. Artefacts include build provenance attestations (https://github.com/microsoft/PR-Metrics/blob/main/docs/verification.md) and Sigstore cosign signatures.


    Suficiente para um badge!

    O projeto DEVE impedir o armazenamento não intencional de dados sensíveis não criptografados, como segredos e credenciais, no sistema de controle de versão. [OSPS-BR-07.01]
    Configure .gitignore ou equivalente para excluir arquivos que possam conter informações sensíveis. Use hooks de pré-commit e ferramentas de varredura automatizadas para detectar e prevenir a inclusão de dados sensíveis em commits.

    The .gitignore file excludes environment files (.env, .env.local, .env.*.local). The CI/CD pipeline includes gitleaks (https://github.com/microsoft/PR-Metrics/blob/main/.github/linters/gitleaks.toml) secret scanning via Super-Linter. No credentials or secrets are tracked in the repository. Access tokens are managed exclusively through GitHub Secrets.


    Suficiente para um badge!

    Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir guias do usuário para todas as funcionalidades básicas. [OSPS-DO-01.01]
    Crie guias do usuário ou documentação para todas as funcionalidades básicas do projeto, explicando como instalar, configurar e usar os recursos do projeto. Se houver quaisquer ações perigosas ou destrutivas conhecidas disponíveis, inclua avisos altamente visíveis.

    The README.md (https://github.com/microsoft/PR-Metrics/blob/main/README.md) provides comprehensive documentation covering installation, configuration inputs, usage examples for both GitHub Actions and Azure DevOps Pipelines, and detailed descriptions of all parameters. Additional documentation is available in the docs/ folder (https://github.com/microsoft/PR-Metrics/tree/main/docs), including troubleshooting and platform-specific guides.


    Suficiente para um badge!

    Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir um guia para relatar defeitos. [OSPS-DO-02.01]
    É recomendado que os projetos usem o rastreador de issues padrão do seu VCS. Se uma fonte externa for usada, certifique-se de que a documentação do projeto e o guia de contribuição expliquem de forma clara e visível como usar o sistema de relatório. É recomendado que a documentação do projeto também estabeleça expectativas sobre como os defeitos serão triados e resolvidos.

    The project uses GitHub Issues with structured templates for bug reports (https://github.com/microsoft/PR-Metrics/blob/main/.github/ISSUE_TEMPLATE/bug_report.md) and feature requests (https://github.com/microsoft/PR-Metrics/blob/main/.github/ISSUE_TEMPLATE/feature-request.md). The CONTRIBUTING.md (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md) directs contributors to use GitHub Issues for reporting defects and communicating with the team.


    Suficiente para um badge!

    Enquanto ativo, o projeto DEVE ter um ou mais mecanismos para discussões públicas sobre mudanças propostas e obstáculos de uso. [OSPS-GV-02.01]
    Estabeleça um ou mais mecanismos para discussões públicas dentro do projeto, como listas de discussão, mensagens instantâneas ou rastreadores de issues, para facilitar a comunicação aberta e feedback.

    The project provides multiple public discussion channels: GitHub Issues (https://github.com/microsoft/PR-Metrics/issues) for bug reports and feature requests, GitHub Pull Requests (https://github.com/microsoft/PR-Metrics/pulls) for proposed changes, and GitHub Discussions (https://github.com/microsoft/PR-Metrics/discussions) for general community conversation. All channels are publicly accessible.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE incluir uma explicação do processo de contribuição. [OSPS-GV-03.01]
    Crie um CONTRIBUTING.md ou diretório CONTRIBUTING/ para delinear o processo de contribuição incluindo as etapas para enviar mudanças e se engajar com os mantenedores do projeto.

    The CONTRIBUTING.md (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md) file documents the contribution process, including the Contributor License Agreement (CLA) requirement, coding style guidelines, instructions for updating and adding extensions, and how to communicate with the team. A pull request template (https://github.com/microsoft/PR-Metrics/blob/main/.github/pull_request_template.md) is also provided.


    Suficiente para um badge!

    Enquanto ativo, a licença para o código-fonte DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. [OSPS-LE-02.01]
    Adicione um arquivo LICENSE ao repositório do projeto com uma licença que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Lançar para o domínio público atende a este controle se não houver outros obstáculos como patentes.

    The project is licensed under the MIT License (https://github.com/microsoft/PR-Metrics/blob/main/LICENSE), which is approved by the Open Source Initiative (https://opensource.org/licenses/MIT).


    Suficiente para um badge!

    Enquanto ativo, a licença para os ativos de software lançados DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. [OSPS-LE-02.02]
    Se uma licença diferente for incluída com ativos de software lançados, certifique-se de que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Note que a licença para os ativos de software lançados pode ser diferente do código-fonte.

    Released software artefacts are distributed under the same MIT License as the source code. The licence is OSI-approved.


    Suficiente para um badge!

    Enquanto ativo, a licença para o código-fonte DEVE ser mantida no arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ do repositório correspondente. [OSPS-LE-03.01]
    Inclua a licença do código-fonte do projeto no arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ do projeto para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver múltiplos repositórios, certifique-se de que cada repositório inclua o arquivo de licença.

    The LICENSE file (https://github.com/microsoft/PR-Metrics/blob/main/LICENSE) is present in the repository root, containing the full MIT License text with the Microsoft Corporation copyright notice.


    Suficiente para um badge!

    Enquanto ativo, a licença para os ativos de software lançados DEVE ser incluída no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ ao lado dos ativos de versão correspondentes. [OSPS-LE-03.02]
    Inclua a licença dos ativos de software lançados do projeto no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ ao lado dos ativos de versão correspondentes para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver múltiplos repositórios, certifique-se de que cada repositório inclua o arquivo de licença.

    The release pipeline processes a LICENSE.txt for inclusion with release artefacts (via Update-Licenses.ps1). GitHub Releases automatically include the source code (with the LICENSE file) as downloadable archives alongside the VSIX artefact.


    Suficiente para um badge!

    Enquanto ativo, o repositório de código-fonte do projeto DEVE ser publicamente legível em uma URL estática. [OSPS-QA-01.01]
    Use um VCS comum como GitHub, GitLab ou Bitbucket. Certifique-se de que o repositório seja publicamente legível. Evite duplicação ou espelhamento de repositórios a menos que documentação altamente visível esclareça a fonte primária. Evite mudanças frequentes no repositório que impactariam a URL do repositório. Certifique-se de que o repositório seja público.

    The source code is publicly available at https://github.com/microsoft/PR-Metrics, a stable URL on GitHub.


    Suficiente para um badge!

    O sistema de controle de versão DEVE conter um registro publicamente legível de todas as alterações feitas, quem fez as alterações e quando as alterações foram feitas. [OSPS-QA-01.02]
    Use um VCS comum como GitHub, GitLab ou Bitbucket para manter um histórico de commits publicamente legível. Evite esmagar ou reescrever commits de uma forma que obscureça o autor de quaisquer commits.

    The full Git commit history is publicly readable at https://github.com/microsoft/PR-Metrics, including author, date, and commit message for every change. Pull request history with review discussions is also publicly accessible.


    Suficiente para um badge!

    Quando o sistema de gerenciamento de pacotes suportar, o repositório de código-fonte DEVE conter uma lista de dependências que representa as dependências diretas da linguagem. [OSPS-QA-02.01]
    Isso pode assumir a forma de um arquivo de dependências de gerenciador de pacotes ou linguagem que enumera todas as dependências diretas, como package.json, Gemfile ou go.mod.

    The package.json (https://github.com/microsoft/PR-Metrics/blob/main/package.json) and package-lock.json (https://github.com/microsoft/PR-Metrics/blob/main/package-lock.json) files enumerate all direct and transitive npm dependencies for the project.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE conter uma lista de quaisquer bases de código que sejam consideradas subprojetos. [OSPS-QA-04.01]
    Documente quaisquer repositórios de código de subprojetos adicionais produzidos pelo projeto e compilados em uma versão de lançamento. Esta documentação deve incluir o status e a intenção da respectiva base de código.

    The project does not have any subprojects. It is a single codebase that produces artefacts for both GitHub Actions and Azure DevOps Pipelines via shared source code with platform-specific abstraction layers.


    Suficiente para um badge!

    Enquanto ativo, o sistema de controle de versão NÃO DEVE conter artefatos executáveis gerados. [OSPS-QA-05.01]
    Remova artefatos executáveis gerados no sistema de controle de versão do projeto. É recomendado que qualquer cenário em que um artefato executável gerado apareça como crítico para um processo, como testes, ele deve ser gerado no momento da compilação ou armazenado separadamente e buscado durante uma etapa de pipeline específica e bem documentada.

    The repository does not contain generated executable binaries (e.g., .exe, .dll, .so, .jar). The dist/ folder contains text-based JavaScript files (index.mjs, exec-child.js) and metadata (lib.json, resources.resjson) required by the GitHub Actions runtime, which mandates committing compiled action code. These files are human-readable and reviewable. Build artefacts such as the VSIX package are generated at build time and published via CI/CD, not stored in version control.


    Suficiente para um badge!

    Enquanto ativo, o sistema de controle de versão NÃO DEVE conter artefatos binários não revisáveis. [OSPS-QA-05.02]
    Não adicione nenhum artefato binário não revisável ao sistema de controle de versão do projeto. Isso inclui binários de aplicativos executáveis, arquivos de biblioteca e artefatos similares. Não inclui recursos como imagens gráficas, arquivos de som ou música e conteúdo similar normalmente armazenado em formato binário.

    The only binary files in the repository are PNG images used for documentation illustrations and UI icons (in docs/images/ and src/images/). These are graphical assets, which are explicitly excluded from this control. No executable binaries, library files, or similar unreviewable artefacts are present.


    Suficiente para um badge!

    Enquanto ativo, a documentação do projeto DEVE conter contatos de segurança. [OSPS-VM-02.01]
    Crie um arquivo security.md (ou com nome similar) que contenha contatos de segurança para o projeto.

    The SECURITY.md (https://github.com/microsoft/PR-Metrics/blob/main/SECURITY.md) file provides security vulnerability reporting instructions, directing reporters to the Microsoft Security Response Center (MSRC) at https://msrc.microsoft.com/create-report or via email at secure@microsoft.com. The file includes guidance on PGP encryption, expected response times, and the information to include in a report.



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.