PR Metrics

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia base en la página de su proyecto. El estado de la insignia base se ve así: El nivel de insignia base para el proyecto 11987 es baseline-3 Aquí se explica cómo insertar la insignia base:
Puede mostrar el estado de su insignia base insertando esto en su archivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/11987/baseline)](https://www.bestpractices.dev/projects/11987)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/11987"><img src="https://www.bestpractices.dev/projects/11987/baseline"></a>


Estos son los criterios de Nivel Base 2. Estos criterios son de la versión base v2025.10.10 con texto de criterios actualizado de la versión v2026.02.19. Los criterios que son nuevos en la versión v2026.02.19 están etiquetados como "futuros" y comenzarán a aplicarse a partir del 2026-06-01. Por favor, proporcione respuestas a los criterios "futuros" antes de esa fecha.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

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

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

 Controles 18/19 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando una tarea de CI/CD se ejecuta sin permisos especificados, el sistema de CI/CD DEBE establecer por defecto los permisos de la tarea a los permisos más bajos otorgados en el pipeline. [OSPS-AC-04.01]
    Configure las configuraciones del proyecto para asignar los permisos más bajos disponibles a nuevos pipelines por defecto, otorgando permisos adicionales solo cuando sea necesario para tareas 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 una insignia!

    Cuando se crea un lanzamiento oficial, ese lanzamiento DEBE ser asignado un identificador de versión único. [OSPS-BR-02.01]
    Asigne un identificador de versión único a cada lanzamiento producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Los ejemplos incluyen SemVer, CalVer o ID de commit de 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 una insignia!

    Cuando se crea un lanzamiento oficial, ese lanzamiento DEBE contener un registro descriptivo de modificaciones funcionales y de seguridad. [OSPS-BR-04.01]
    Asegúrese de que todos los lanzamientos incluyan un registro de cambios descriptivo. Se recomienda asegurar que el registro de cambios sea legible por humanos e incluya detalles más allá de los mensajes de commit, como descripciones del impacto de seguridad o relevancia para diferentes casos de uso. Para asegurar la legibilidad automática, coloque el contenido bajo un encabezado 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 una insignia!

    Cuando un pipeline de construcción y lanzamiento ingiere dependencias, DEBE usar herramientas estandarizadas donde estén disponibles. [OSPS-BR-05.01]
    Use herramientas comunes para su ecosistema, como gestores de paquetes o herramientas de gestión de dependencias para ingerir dependencias en tiempo de construcción. Esto puede incluir usar un archivo de dependencias, archivo de bloqueo o manifiesto para especificar las dependencias requeridas, que luego son incorporadas por el sistema de construcción.

    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 una insignia!

    Cuando se crea un lanzamiento oficial, ese lanzamiento DEBE estar firmado o registrado en un manifiesto firmado que incluya los hashes criptográficos de cada activo. [OSPS-BR-06.01]
    Firme todos los activos de software lanzados en tiempo de construcción con una firma criptográfica o atestaciones, como firma GPG o PGP, firmas Sigstore, proveniencia SLSA, o VSAs SLSA. Incluya los hashes criptográficos de cada activo en un manifiesto firmado o archivo de metadatos.

    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 una insignia!

    Cuando el proyecto ha realizado un lanzamiento, la documentación del proyecto DEBE incluir una descripción de cómo el proyecto selecciona, obtiene y rastrea sus dependencias. [OSPS-DO-06.01]
    Se recomienda publicar esta información junto con la documentación técnica y de diseño del proyecto en un recurso públicamente visible como el repositorio de código fuente, sitio web del proyecto u otro 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.


    Información requerida desconocida, no es suficiente para una insignia.

    (Criterio futuro) La documentación del proyecto DEBE incluir instrucciones sobre cómo compilar el software, incluyendo las bibliotecas, marcos, SDK y dependencias necesarias. [OSPS-DO-07.01]
    Se recomienda publicar esta información junto con la documentación para colaboradores del proyecto, por ejemplo en CONTRIBUTING.md u otra documentación de tareas para desarrolladores. También puede documentarse utilizando objetivos de Makefile u otros scripts de automatización.

    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una lista de miembros del proyecto con acceso a recursos sensibles. [OSPS-GV-01.01]
    Documente los participantes del proyecto y sus roles a través de artefactos tales como members.md, governance.md, maintainers.md, o archivo similar dentro del repositorio de código fuente del proyecto. Esto puede ser tan simple como incluir nombres o identificadores de cuenta en una lista de mantenedores, o más complejo dependiendo de la gobernanza del proyecto.

    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 una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir descripciones de los roles y responsabilidades para los miembros del proyecto. [OSPS-GV-01.02]
    Documente los participantes del proyecto y sus roles a través de artefactos tales como members.md, governance.md, maintainers.md, o archivo similar dentro del repositorio de código fuente del proyecto.

    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 una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una guía para contribuidores de código que incluya requisitos para contribuciones aceptables. [OSPS-GV-03.02]
    Extienda el CONTRIBUTING.md o los contenidos de CONTRIBUTING/ en la documentación del proyecto para delinear los requisitos para contribuciones aceptables, incluyendo estándares de codificación, requisitos de pruebas y pautas de envío para contribuidores de código. Se recomienda que esta guía sea la fuente de verdad tanto para contribuidores como para aprobadores.

    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 una insignia!

    Mientras esté activo, el sistema de control de versiones DEBE requerir que todos los contribuidores de código afirmen que están legalmente autorizados para hacer las contribuciones asociadas en cada commit. [OSPS-LE-01.01]
    Incluya un DCO en el repositorio del proyecto, requiriendo que los contribuidores de código afirmen que están legalmente autorizados para confirmar las contribuciones asociadas en cada commit. Use una verificación de estado para asegurar que se haga la afirmación. Un CLA también satisface este requisito. Algunos sistemas de control de versiones, como GitHub, pueden incluir esto en los términos de servicio de la 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 una insignia!

    Cuando se realiza un commit a la rama principal, cualquier verificación de estado automatizada para commits DEBE pasar o ser omitida manualmente. [OSPS-QA-03.01]
    Configure el sistema de control de versiones del proyecto para requerir que todas las verificaciones de estado automatizadas pasen o requieran reconocimiento manual antes de que un commit pueda fusionarse en la rama principal. Se recomienda que cualquier verificación de estado opcional NO esté configurada como un requisito de pasar o fallar que los aprobadores puedan estar tentados a omitir.

    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 una insignia!

    Antes de que se acepte un commit, los pipelines de CI/CD del proyecto DEBEN ejecutar al menos un conjunto de pruebas automatizado para asegurar que los cambios cumplan las expectativas. [OSPS-QA-06.01]
    Las pruebas automatizadas deben ejecutarse antes de cada fusión en la rama principal. El conjunto de pruebas debe ejecutarse en un pipeline de CI/CD y los resultados deben ser visibles para todos los contribuidores. El conjunto de pruebas debe ejecutarse en un entorno consistente y debe ejecutarse de manera que permita a los contribuidores ejecutar las pruebas localmente. Ejemplos de conjuntos de pruebas incluyen pruebas unitarias, pruebas de integración y pruebas de extremo a extremo.

    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 una insignia!

    Cuando el proyecto ha realizado un lanzamiento, la documentación del proyecto DEBE incluir documentación de diseño que demuestre todas las acciones y actores dentro del sistema. [OSPS-SA-01.01]
    Incluya diseños en la documentación del proyecto que expliquen las acciones y los actores. Los actores incluyen cualquier subsistema o entidad que pueda influir en otro segmento del sistema. Asegúrese de que esto se actualice para nuevas características o cambios 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.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir descripciones de todas las interfaces de software externas de los activos de software liberados. [OSPS-SA-02.01]
    Documente todas las interfaces de software (APIs) de los activos de software liberados, explicando cómo los usuarios pueden interactuar con el software y qué datos se esperan o se producen. Asegúrese de que esto se actualice para nuevas funcionalidades o cambios incompatibles.

    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 una insignia!

    Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar una evaluación de seguridad para comprender los problemas de seguridad potenciales más probables e impactantes que podrían ocurrir dentro del software. [OSPS-SA-03.01]
    Realizar una evaluación de seguridad informa tanto a los miembros del proyecto como a los consumidores posteriores que el proyecto comprende qué problemas podrían surgir dentro del software. Comprender qué amenazas podrían materializarse ayuda al proyecto a gestionar y abordar el riesgo. Esta información es útil para los consumidores posteriores para demostrar la competencia y prácticas de seguridad del proyecto. Asegúrese de que esto se actualice para nuevas funcionalidades o cambios incompatibles.

    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 una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política para la divulgación coordinada de vulnerabilidades (CVD), con un plazo de tiempo claro para la respuesta. [OSPS-VM-01.01]
    Cree un archivo SECURITY.md en la raíz del directorio, describiendo la política del proyecto para la divulgación coordinada de vulnerabilidades. Incluya un método para reportar vulnerabilidades. Establezca expectativas sobre cómo el proyecto responderá y abordará los problemas reportados.

    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 una insignia!

    Mientras esté activo, la documentación del proyecto DEBE proporcionar un medio para el reporte privado de vulnerabilidades directamente a los contactos de seguridad dentro del proyecto. [OSPS-VM-03.01]
    Proporcione un medio para que los investigadores de seguridad reporten vulnerabilidades de forma privada al proyecto. Esto puede ser una dirección de correo electrónico dedicada, un formulario web, herramientas especializadas del VCS, direcciones de correo electrónico para contactos de seguridad, u otros 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 una insignia!

    Mientras esté activo, la documentación del proyecto DEBE publicar públicamente datos sobre las vulnerabilidades descubiertas. [OSPS-VM-04.01]
    Proporcione información sobre vulnerabilidades conocidas en un canal público predecible, como una entrada CVE, publicación de blog u otro medio. En la medida de lo posible, esta información debe incluir la(s) versión(es) afectada(s), cómo un consumidor puede determinar si es vulnerable, e instrucciones para la mitigación o remediación.

    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.



Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Muiris Woulfe y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Muiris Woulfe.
Entrada creada el 2026-02-19 17:32:37 UTC, última actualización el 2026-02-27 19:06:06 UTC. Última pérdida de la insignia de nivel básico el 2026-02-23 14:15:17 UTC. Última obtención de la insignia de nivel básico el 2026-02-23 14:43:51 UTC.