PR Metrics

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez afficher votre statut de badge de référence sur la page de votre projet ! Le statut du badge de référence ressemble à ceci : Le niveau du badge de référence pour le projet 11987 est baseline-3 Voici comment intégrer le badge de référence :
Vous pouvez afficher votre statut de badge de référence en incorporant ceci dans votre fichier markdown :
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/11987/baseline)](https://www.bestpractices.dev/projects/11987)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/11987"><img src="https://www.bestpractices.dev/projects/11987/baseline"></a>


Voici les critères du niveau de référence 2. Ces critères proviennent de la version de référence v2025.10.10 avec le texte des critères mis à jour depuis la version v2026.02.19. Les critères nouveaux dans la version v2026.02.19 sont étiquetés « futur » et commenceront à être appliqués à partir du 2026-06-01. Veuillez fournir des réponses aux critères « futur » avant cette date.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

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

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.

 Contrôles 18/19 ●

  • Contrôles


    Assez pour un badge !

    Lorsqu'une tâche CI/CD est exécutée sans permissions spécifiées, le système CI/CD DOIT par défaut définir les permissions de la tâche aux permissions les plus faibles accordées dans le pipeline. [OSPS-AC-04.01]
    Configurez les paramètres du projet pour attribuer les permissions les plus faibles disponibles aux nouveaux pipelines par défaut, en accordant des permissions supplémentaires uniquement lorsque cela est nécessaire pour des tâches spécifiques.

    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.


    Assez pour un badge !

    Lorsqu'une version officielle est créée, cette version DOIT se voir attribuer un identifiant de version unique. [OSPS-BR-02.01]
    Attribuez un identifiant de version unique à chaque version produite par le projet, en suivant une convention de nommage ou un schéma de numérotation cohérent. Les exemples incluent SemVer, CalVer ou l'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.


    Assez pour un badge !

    Lorsqu'une version officielle est créée, cette version DOIT contenir un journal descriptif des modifications fonctionnelles et de sécurité. [OSPS-BR-04.01]
    Assurez-vous que toutes les versions incluent un journal des modifications descriptif. Il est recommandé de s'assurer que le journal des modifications est lisible par l'homme et inclut des détails au-delà des messages de commit, tels que des descriptions de l'impact sur la sécurité ou la pertinence pour différents cas d'utilisation. Pour garantir la lisibilité par la machine, placez le contenu sous un en-tête markdown tel que « ## 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.


    Assez pour un badge !

    Lorsqu'un pipeline de construction et de publication ingère des dépendances, il DOIT utiliser des outils standardisés lorsqu'ils sont disponibles. [OSPS-BR-05.01]
    Utilisez un outil commun pour votre écosystème, tel que des gestionnaires de paquets ou des outils de gestion des dépendances pour ingérer les dépendances au moment de la construction. Cela peut inclure l'utilisation d'un fichier de dépendances, d'un fichier de verrouillage ou d'un manifeste pour spécifier les dépendances requises, qui sont ensuite intégrées par le système de construction.

    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.


    Assez pour un badge !

    Lorsqu'une version officielle est créée, cette version DOIT être signée ou comptabilisée dans un manifeste signé incluant les hachages cryptographiques de chaque ressource. [OSPS-BR-06.01]
    Signez toutes les ressources logicielles publiées au moment de la construction avec une signature cryptographique ou des attestations, telles qu'une signature GPG ou PGP, des signatures Sigstore, une provenance SLSA ou des VSA SLSA. Incluez les hachages cryptographiques de chaque ressource dans un manifeste signé ou un fichier de métadonnées.

    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).


    Assez pour un badge !

    Lorsque le projet a publié une version, la documentation du projet DOIT inclure une description de la façon dont le projet sélectionne, obtient et suit ses dépendances. [OSPS-DO-06.01]
    Il est recommandé de publier ces informations aux côtés de la documentation technique et de conception du projet sur une ressource publiquement accessible telle que le dépôt de code source, le site Web du projet ou un autre 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.


    Informations inconnues requises, pas assez pour un badge.

    (Critère futur) La documentation du projet DOIT inclure des instructions sur la façon de compiler le logiciel, y compris les bibliothèques, les frameworks, les SDK et les dépendances requis. [OSPS-DO-07.01]
    Il est recommandé de publier ces informations aux côtés de la documentation destinée aux contributeurs du projet, par exemple dans CONTRIBUTING.md ou d'autres documentations de tâches pour les développeurs. Ces informations peuvent également être documentées à l'aide de cibles Makefile ou d'autres scripts d'automatisation.

    Assez pour un badge !

    Lorsqu'il est actif, la documentation du projet DOIT inclure une liste des membres du projet ayant accès aux ressources sensibles. [OSPS-GV-01.01]
    Documentez les participants au projet et leurs rôles à travers des artefacts tels que members.md, governance.md, maintainers.md ou un fichier similaire dans le dépôt de code source du projet. Cela peut être aussi simple que d'inclure des noms ou des identifiants de compte dans une liste de mainteneurs, ou plus complexe selon la gouvernance du projet.

    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.


    Assez pour un badge !

    Lorsqu'il est actif, la documentation du projet DOIT inclure des descriptions des rôles et des responsabilités pour les membres du projet. [OSPS-GV-01.02]
    Documentez les participants au projet et leurs rôles à travers des artefacts tels que members.md, governance.md, maintainers.md ou un fichier similaire dans le dépôt de code source du projet.

    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.


    Assez pour un badge !

    Lorsqu'il est actif, la documentation du projet DOIT inclure un guide pour les contributeurs de code qui inclut les exigences pour les contributions acceptables. [OSPS-GV-03.02]
    Étendez le contenu de CONTRIBUTING.md ou CONTRIBUTING/ dans la documentation du projet pour décrire les exigences pour les contributions acceptables, y compris les normes de codage, les exigences de test et les directives de soumission pour les contributeurs de code. Il est recommandé que ce guide soit la source de vérité pour les contributeurs et les approbateurs.

    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.


    Assez pour un badge !

    Lorsqu'il est actif, le système de contrôle de version DOIT exiger que tous les contributeurs de code affirment qu'ils sont légalement autorisés à effectuer les contributions associées sur chaque commit. [OSPS-LE-01.01]
    Incluez un DCO dans le dépôt du projet, exigeant que les contributeurs de code affirment qu'ils sont légalement autorisés à valider les contributions associées sur chaque commit. Utilisez un contrôle de statut pour assurer que l'affirmation est faite. Un CLA satisfait également cette exigence. Certains systèmes de contrôle de version, tels que GitHub, peuvent inclure cela dans les conditions d'utilisation de la plateforme.

    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).


    Assez pour un badge !

    Lorsqu'un commit est effectué sur la branche principale, tous les contrôles de statut automatisés pour les commits DOIVENT réussir ou être contournés manuellement. [OSPS-QA-03.01]
    Configurez le système de contrôle de version du projet pour exiger que tous les contrôles de statut automatisés réussissent ou nécessitent une reconnaissance manuelle avant qu'un commit puisse être fusionné dans la branche principale. Il est recommandé que tous les contrôles de statut facultatifs ne soient PAS configurés comme une exigence de réussite ou d'échec que les approbateurs pourraient être tentés de contourner.

    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.


    Assez pour un badge !

    Avant qu'un commit ne soit accepté, les pipelines CI/CD du projet DOIVENT exécuter au moins une suite de tests automatisée pour s'assurer que les modifications répondent aux attentes. [OSPS-QA-06.01]
    Les tests automatisés devraient être exécutés avant chaque fusion dans la branche principale. La suite de tests devrait être exécutée dans un pipeline CI/CD et les résultats devraient être visibles pour tous les contributeurs. La suite de tests devrait être exécutée dans un environnement cohérent et devrait être exécutée de manière à permettre aux contributeurs d'exécuter les tests localement. Des exemples de suites de tests incluent les tests unitaires, les tests d'intégration et les tests de bout en bout.

    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.


    Assez pour un badge !

    Lorsque le projet a publié une version, la documentation du projet DOIT inclure une documentation de conception démontrant toutes les actions et acteurs au sein du système. [OSPS-SA-01.01]
    Incluez des conceptions dans la documentation du projet qui expliquent les actions et les acteurs. Les acteurs incluent tout sous-système ou entité qui peut influencer un autre segment du système. Assurez-vous que cela est mis à jour pour les nouvelles fonctionnalités ou les modifications importantes.

    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.


    Assez pour un badge !

    Lorsque le projet a fait une version, la documentation du projet DOIT inclure les descriptions de toutes les interfaces logicielles externes des actifs logiciels publiés. [OSPS-SA-02.01]
    Documentez toutes les interfaces logicielles (APIs) des actifs logiciels publiés, en expliquant comment les utilisateurs peuvent interagir avec le logiciel et quelles données sont attendues ou produites. Assurez-vous que ceci est mis à jour pour les nouvelles fonctionnalités ou les changements majeurs.

    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.


    Assez pour un badge !

    Lorsque le projet a fait une version, le projet DOIT effectuer une évaluation de sécurité pour comprendre les problèmes de sécurité potentiels les plus probables et les plus impactants qui pourraient se produire dans le logiciel. [OSPS-SA-03.01]
    Effectuer une évaluation de sécurité informe à la fois les membres du projet ainsi que les consommateurs en aval que le projet comprend quels problèmes pourraient survenir dans le logiciel. Comprendre quelles menaces pourraient se réaliser aide le projet à gérer et traiter le risque. Cette information est utile aux consommateurs en aval pour démontrer la compétence et les pratiques de sécurité du projet. Assurez-vous que ceci est mis à jour pour les nouvelles fonctionnalités ou les changements majeurs.

    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.


    Assez pour un badge !

    Lorsqu'il est actif, la documentation du projet DOIT inclure une politique pour la divulgation coordonnée de vulnérabilités (CVD), avec un délai clair pour la réponse. [OSPS-VM-01.01]
    Créez un fichier SECURITY.md à la racine du répertoire, décrivant la politique du projet pour la divulgation coordonnée de vulnérabilités. Incluez une méthode pour signaler les vulnérabilités. Définissez les attentes sur la façon dont le projet répondra et traitera les problèmes signalés.

    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."


    Assez pour un badge !

    Lorsqu'il est actif, la documentation du projet DOIT fournir un moyen de signaler les vulnérabilités de façon privée directement aux contacts de sécurité du projet. [OSPS-VM-03.01]
    Fournissez un moyen pour les chercheurs de sécurité de signaler les vulnérabilités de manière privée au projet. Cela peut être une adresse email dédiée, un formulaire web, des outils spécialisés du système de gestion de version, des adresses email pour les contacts de sécurité, ou d'autres méthodes.

    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.


    Assez pour un badge !

    Lorsqu'il est actif, la documentation du projet DOIT publier publiquement les données sur les vulnérabilités découvertes. [OSPS-VM-04.01]
    Fournissez des informations sur les vulnérabilités connues dans un canal public prévisible, tel qu'une entrée CVE, un article de blog ou un autre moyen. Dans la mesure du possible, ces informations doivent inclure la ou les version(s) affectée(s), comment un consommateur peut déterminer s'il est vulnérable, et des instructions pour l'atténuation ou la correction.

    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.



Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Muiris Woulfe et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Muiris Woulfe.
Soumission créée le 2026-02-19 17:32:37 UTC, dernière mise à jour le 2026-02-27 19:06:06 UTC. Le dernier badge perdu l'a été le 2026-02-23 14:15:17 UTC. Le dernier badge obtenu l'a été le 2026-02-23 14:43:51 UTC.