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 3. 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 20/21 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando se asigna permisos a un trabajo en un pipeline de CI/CD, el código fuente o configuración DEBE asignar solo los privilegios mínimos necesarios para la actividad correspondiente. [OSPS-AC-04.02]
    Configure los pipelines de CI/CD del proyecto para asignar los permisos más bajos disponibles a usuarios y servicios por defecto, elevando los permisos solo cuando sea necesario para tareas específicas. En algunos sistemas de control de versiones, esto puede ser posible a nivel organizacional o de repositorio. Si no es posible, establezca los permisos en el nivel superior del pipeline.

    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. Each job explicitly requests only the specific permissions it requires. For example, the release job in release-publish.yml requests only attestations: write and id-token: write, while the build job in build.yml requests permissions: {} (no permissions). The Azure DevOps pipelines extend the Office.Official.PipelineTemplate and Office.Unofficial.PipelineTemplate templates, which enforce organisational security policies including least-privilege defaults.


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

    (Criterio futuro) Los flujos de CI/CD que aceptan entradas de colaboradores de confianza DEBEN sanear y validar dichas entradas antes de utilizarlas en el flujo. [OSPS-BR-01.04]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de colaboradores en ejecuciones explícitas de flujos de trabajo. Aunque los colaboradores son generalmente de confianza, las entradas manuales a un flujo de trabajo no pueden revisarse y podrían ser abusadas por una toma de control de cuenta o una amenaza interna.

    ¡Suficiente para una insignia!

    Cuando se crea un lanzamiento oficial, todos los activos dentro de ese lanzamiento DEBEN estar claramente asociados con el identificador del lanzamiento u otro identificador único para el activo. [OSPS-BR-02.02]
    Asigne un identificador de versión único a cada activo de software producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Ejemplos incluyen SemVer, CalVer, o git commit id.

    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). Release assets (the VSIX extension, Sigstore signature bundle, and CycloneDX SBOM) are published as part of the GitHub Release (https://github.com/microsoft/PR-Metrics/releases) tagged with the version identifier. The release-publish.yml workflow (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/release-publish.yml) reads the version from release-publish-trigger.txt (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/support/release-publish-trigger.txt) and creates the release with that version tag.


    ¡Suficiente para una insignia!

    El proyecto DEBE definir una política para gestionar secretos y credenciales utilizados por el proyecto. La política debe incluir directrices para almacenar, acceder y rotar secretos y credenciales. [OSPS-BR-07.02]
    Documente cómo se gestionan y utilizan los secretos y credenciales dentro del proyecto. Esto debe incluir detalles sobre cómo se almacenan los secretos (por ejemplo, utilizando una herramienta de gestión de secretos), cómo se controla el acceso y cómo se rotan o actualizan los secretos. Asegúrese de que la información sensible no esté codificada directamente en el código fuente ni almacenada en sistemas de control de versiones.

    The project documents its secrets and credentials management policy in docs/secrets-management.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/secrets-management.md). The policy covers all secrets used by the project (including GITHUB_TOKEN, PR_METRICS_TOKEN, and ESRP service connections), how they are stored (exclusively in GitHub Secrets and Azure DevOps variable groups), how access is controlled (repository-level permissions, fork restrictions, least-privilege workflow permissions), and how secrets are rotated (GITHUB_TOKEN is auto-rotated per workflow run; PATs are reviewed periodically). The policy also describes preventative measures including Gitleaks secret scanning, environment variable usage instead of command-line arguments, and automatic log masking.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la integridad y autenticidad de los activos del lanzamiento. [OSPS-DO-03.01]
    Las instrucciones en el proyecto deben contener información sobre la tecnología utilizada, los comandos a ejecutar y la salida esperada. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    The docs/verification.md file (https://github.com/microsoft/PR-Metrics/blob/main/docs/verification.md) provides comprehensive instructions for verifying release integrity and authenticity using two independent methods: Build provenance attestation, verified via GitHub CLI (gh attestation verify), confirming the artefact was built by the official release workflow and hasn't been tampered with. Cosign signature, verified via Sigstore cosign (cosign verify-blob), confirming cryptographic integrity using keyless signing backed by GitHub's OIDC tokens. The documentation includes prerequisites, step-by-step verification commands, expected output, and troubleshooting guidance. This documentation is maintained in the repository's docs/ folder, separate from the build and release pipeline configuration.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la identidad esperada de la persona o proceso que crea el lanzamiento del software. [OSPS-DO-03.02]
    La identidad esperada puede estar en forma de IDs de clave utilizados para firmar, emisor e identidad de un certificado sigstore, u otras formas similares. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    The docs/verification.md file (https://github.com/microsoft/PR-Metrics/blob/main/docs/verification.md) includes instructions to verify the expected identity of the process authoring the release. The cosign verification command specifies the expected identity via: --certificate-identity-regexp matching ^https://github.com/microsoft/PR-Metrics/.github/workflows/release-publish.yml@refs/heads/main$ and --certificate-oidc-issuer matching https://token.actions.githubusercontent.com. This confirms that the release was authored by the release-publish.yml workflow running on the main branch of the microsoft/PR-Metrics repository, using GitHub's OIDC identity provider. The build provenance attestation additionally links the artefact to a specific workflow run and commit. This documentation is maintained separately from the build and release pipeline.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una declaración descriptiva sobre el alcance y la duración del soporte para cada lanzamiento. [OSPS-DO-04.01]
    Para comunicar el alcance y la duración del soporte para los activos de software lanzados del proyecto, el proyecto debe tener un archivo SUPPORT.md, una sección "Soporte" en SECURITY.md, u otra documentación que explique el ciclo de vida del soporte, incluyendo la duración esperada del soporte para cada lanzamiento, los tipos de soporte proporcionados (por ejemplo, corrección de errores, actualizaciones de seguridad), y cualquier política o procedimiento relevante para obtener soporte.

    The SUPPORT.md file (https://github.com/microsoft/PR-Metrics/blob/main/.github/SUPPORT.md) documents the support lifecycle for the project. It states that PR Metrics follows a rolling release model where only the latest release is actively supported with bug fixes and security updates. Previous releases do not receive patches. The document also describes the end-of-life policy: should the project become inactive, the last published release will remain available but will not receive further updates. Consumers will be notified of any planned end of life through GitHub Discussions.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE proporcionar una declaración descriptiva sobre cuándo los lanzamientos o versiones ya no recibirán actualizaciones de seguridad. [OSPS-DO-05.01]
    Para comunicar el alcance y la duración del soporte para correcciones de seguridad, el proyecto debe tener un SUPPORT.md u otra documentación que explique la política del proyecto para actualizaciones de seguridad.

    The SUPPORT.md file (https://github.com/microsoft/PR-Metrics/blob/main/.github/SUPPORT.md) provides a clear statement on when releases will no longer receive security updates: "Once a new version is published, the previous version no longer receives security updates." The document further states that critical security issues may result in an expedited patch release, and that consumers should always run the latest version. The end-of-life section clarifies that if the project becomes inactive, the last release will remain available but will not receive security patches.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE tener una política que establezca que los colaboradores de código sean revisados antes de otorgarles permisos elevados a recursos sensibles. [OSPS-GV-04.01]
    Publique una política exigible en la documentación del proyecto que requiera que los colaboradores de código sean revisados y aprobados antes de otorgarles permisos elevados a recursos sensibles, como aprobación de fusiones o acceso a secretos. Se recomienda que la verificación incluya establecer un linaje justificable de identidad, como confirmar la asociación del colaborador con una organización confiable conocida.

    The GOVERNANCE.md file (https://github.com/microsoft/PR-Metrics/blob/main/GOVERNANCE.md) includes a "Collaborator Review Policy" section that requires contributors to be reviewed and approved before being granted escalated permissions to sensitive resources. The policy requires nomination by an existing maintainer based on sustained quality contributions, identity verification through association with a known trusted organisation, and approval by at least one existing maintainer. Permissions are granted at the minimum level required for the contributor's role. Access to signing infrastructure is restricted to automated CI/CD pipelines and cannot be granted to individual contributors.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, todos los activos de software compilados lanzados DEBEN ser entregados con una lista de materiales de software. [OSPS-QA-02.02]
    Se recomienda generar automáticamente SBOMs en el momento de la compilación utilizando una herramienta que haya sido verificada para precisión. Esto permite a los usuarios ingerir estos datos en un enfoque estandarizado junto con otros proyectos en su entorno.

    The release-publish.yml workflow (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/release-publish.yml) generates a CycloneDX (https://cyclonedx.org/) Software Bill of Materials (SBOM) using "npm sbom --sbom-format cyclonedx --sbom-type library". The SBOM (ms-omex.PRMetrics.sbom.cdx.json) is included as a release asset alongside the VSIX extension and Sigstore signature bundle on the GitHub Releases page (https://github.com/microsoft/PR-Metrics/releases). This enables consumers to ingest dependency data in a standardised format alongside other projects in their environment.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento que comprenda múltiples repositorios de código fuente, todos los subproyectos DEBEN aplicar requisitos de seguridad que sean tan estrictos o más estrictos que la base de código principal. [OSPS-QA-04.02]
    Cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento debe aplicar requisitos de seguridad según sea aplicable al estado e intención de la base de código respectiva. Además de seguir los requisitos correspondientes de la Línea Base OSPS, esto puede incluir requerir una revisión de seguridad, asegurar que esté libre de vulnerabilidades y asegurar que esté libre de problemas de seguridad conocidos.

    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, as described in docs/cross-platform-architecture.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/cross-platform-architecture.md).


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE documentar claramente cuándo y cómo se ejecutan las pruebas. [OSPS-QA-06.02]
    Agregue una sección a la documentación de contribución que explique cómo ejecutar las pruebas localmente y cómo ejecutar las pruebas en el pipeline de CI/CD. La documentación debe explicar qué están probando las pruebas y cómo interpretar los resultados.

    The project's testing procedures are documented across multiple files: docs/development.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/development.md) contains a "Testing" section explaining how to run tests locally ("npm test"), the test framework (Mocha at https://mochajs.org/ with ts-mockito at https://github.com/NagRock/ts-mockito), the Arrange-Act-Assert pattern used, code coverage reporting via c8 (https://github.com/bcoe/c8), and manual test case instructions. CONTRIBUTING.md (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md) describes how to run tests locally and in CI/CD, what the tests cover, and how to interpret results (pass/fail status and coverage percentages). It also documents that all automated checks in build.yml (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml) (unit tests, CodeQL, Super-Linter) must pass before a pull request can be merged.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política que establezca que todos los cambios importantes al software producido por el proyecto deben agregar o actualizar las pruebas de la funcionalidad en una suite de pruebas automatizada. [OSPS-QA-06.03]
    Agregue una sección a la documentación de contribución que explique la política para agregar o actualizar pruebas. La política debe explicar qué constituye un cambio importante y qué pruebas deben agregarse o actualizarse.

    The CONTRIBUTING.md file (https://github.com/microsoft/PR-Metrics/blob/main/.github/CONTRIBUTING.md) includes a "Test Policy for Major Changes" section requiring that all major changes include corresponding test updates. The policy defines specific requirements for new features (unit tests covering new functionality and edge cases), bug fixes (regression tests), and refactoring (existing tests must continue to pass). A "major change" is defined as any modification that alters extension behaviour, adds configuration parameters, changes metric calculations, or modifies API interactions. The pull request template (https://github.com/microsoft/PR-Metrics/blob/main/.github/pull_request_template.md) includes a testing checklist to enforce compliance.


    ¡Suficiente para una insignia!

    Cuando se realiza un commit a la rama principal, el sistema de control de versiones del proyecto DEBE requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos. [OSPS-QA-07.01]
    Configure el sistema de control de versiones del proyecto para requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos en la rama de lanzamiento o principal. Esto se puede lograr requiriendo que un pull request sea revisado y aprobado por al menos otro colaborador antes de que pueda fusionarse.

    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. At least one non-author approval is required before a pull request can be merged. The CODEOWNERS file (https://github.com/microsoft/PR-Metrics/blob/main/.github/CODEOWNERS) assigns @microsoft/omex as the required reviewer for all files. See repository rulesets at https://github.com/microsoft/PR-Metrics/rules.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar un modelado de amenazas y análisis de superficie de ataque para comprender y protegerse contra ataques en rutas de código críticas, funciones e interacciones dentro del sistema. [OSPS-SA-03.02]
    El modelado de amenazas es una actividad donde el proyecto examina la base de código, procesos asociados e infraestructura, interfaces, componentes clave y "piensa como un hacker" y hace una lluvia de ideas sobre cómo el sistema puede ser vulnerado o comprometido. Cada amenaza identificada se enumera para que el proyecto pueda pensar en cómo evitar proactivamente o cerrar cualquier brecha/vulnerabilidad que pueda surgir. Asegúrese de que esto se actualice para nuevas características o cambios importantes.

    The project maintains a comprehensive security assessment in docs/security-assessment.md (https://github.com/microsoft/PR-Metrics/blob/main/docs/security-assessment.md), which includes a Mermaid diagram of trust boundaries, an asset sensitivity table, and detailed threat analysis covering five threat categories: access token exposure, injection via untrusted PR content, supply chain attacks on dependencies, CI/CD permission escalation, and Git command injection. Each threat includes likelihood and impact ratings with specific mitigations. The assessment also identifies residual risks and specifies a review cadence.


    ¡Suficiente para una insignia!

    Mientras esté activo, cualquier vulnerabilidad en los componentes de software que no afecte al proyecto DEBE ser contabilizada en un documento VEX, aumentando el informe de vulnerabilidad con detalles de no explotabilidad. [OSPS-VM-04.02]
    Establezca un feed VEX comunicando el estado de explotabilidad de vulnerabilidades conocidas, incluyendo detalles de evaluación o cualquier mitigación implementada que impida que el código vulnerable sea ejecutado.

    The docs/security-scanning-policy.md file (https://github.com/microsoft/PR-Metrics/blob/main/docs/security-scanning-policy.md) documents the project's VEX policy. When a vulnerability is identified in a dependency that does not affect PR Metrics (e.g., the vulnerable code path is not reachable), the finding is assessed and documented as non-exploitable via GitHub Security Advisories (https://github.com/microsoft/PR-Metrics/security/advisories) and Dependabot alert dismissals with documented reasons. As of the last assessment, no known vulnerabilities in project dependencies have been identified as non-exploitable requiring VEX documentation; all known vulnerabilities are either resolved through dependency updates or actively being addressed per the documented remediation thresholds.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política que defina un umbral para la remediación de hallazgos de SCA relacionados con vulnerabilidades y licencias. [OSPS-VM-05.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Análisis de Composición de Software (SCA) relacionados con vulnerabilidades y licencias. Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    The docs/security-scanning-policy.md file (https://github.com/microsoft/PR-Metrics/blob/main/docs/security-scanning-policy.md) defines remediation thresholds for SCA findings. Critical and high severity findings must be resolved by the next patch release. Medium and low severity findings must be addressed by the next scheduled release. The policy includes a severity-to-remediation-target mapping table and describes the process for identifying, prioritising, and remediating findings via Dependabot alerts, CodeQL, and Component Governance.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política para abordar violaciones de SCA antes de cualquier lanzamiento. [OSPS-VM-05.02]
    Documente una política en el proyecto para abordar los resultados aplicables del Análisis de Composición de Software antes de cualquier lanzamiento, y agregue verificaciones de estado que comprueben el cumplimiento de esa política antes del lanzamiento.

    The docs/security-scanning-policy.md file (https://github.com/microsoft/PR-Metrics/blob/main/docs/security-scanning-policy.md) documents a pre-release policy requiring that: (1) no unresolved Dependabot alerts of critical or high severity exist; (2) all npm dependencies are updated to their latest compatible versions via the release workflow; (3) Component Governance detection in the Azure DevOps pipeline completes without blocking findings; and (4) non-exploitable findings are documented. The release-initiate.yml workflow (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/release-initiate.yml) enforces dependency updates as part of the release process, and the Azure DevOps pipeline applies the M365 Guardian policy.


    ¡Suficiente para una insignia!

    Mientras esté activo, todos los cambios en la base de código del proyecto DEBEN ser automáticamente evaluados contra una política documentada para dependencias maliciosas y vulnerabilidades conocidas en dependencias, y luego bloqueados en caso de violaciones, excepto cuando se declaren y supriman como no explotables. [OSPS-VM-05.03]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Análisis de Composición de Software en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    All changes to the codebase are automatically evaluated for malicious dependencies and known vulnerabilities: CodeQL (https://codeql.github.com/) runs on every pull request via the Validate job in build.yml (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml), using security-and-quality, security-experimental, and security-extended query sets. Dependabot alerts (https://docs.github.com/code-security/dependabot/dependabot-alerts/about-dependabot-alerts) are configured at the repository level. Component Governance (https://docs.opensource.microsoft.com/tools/cg/) runs dependency detection in the Azure DevOps PR pipeline. The repository rulesets require that all status checks pass before merging. Non-exploitable findings are documented via Dependabot alert dismissals with justification or in the security scanning policy.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política que defina un umbral para la remediación de hallazgos de SAST. [OSPS-VM-06.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Pruebas de Seguridad de Aplicaciones Estáticas (SAST). Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    The docs/security-scanning-policy.md file (https://github.com/microsoft/PR-Metrics/blob/main/docs/security-scanning-policy.md) defines remediation thresholds for SAST findings. Critical and high severity findings block pull request merging via required status checks and must be resolved immediately. Medium severity findings must be resolved before the next release. Low severity findings are addressed on a best-effort basis. The policy covers CodeQL, ESLint, CredScan, and PoliCheck findings, and describes how suppressed findings are documented with justification.


    ¡Suficiente para una insignia!

    Mientras esté activo, todos los cambios en la base de código del proyecto DEBEN ser automáticamente evaluados contra una política documentada para debilidades de seguridad y bloqueados en caso de violaciones excepto cuando se declaren y supriman como no explotables. [OSPS-VM-06.02]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    All changes to the codebase are automatically evaluated for security weaknesses: CodeQL (https://codeql.github.com/) is a required status check on every pull request, running extended security query sets against the JavaScript/TypeScript codebase. Super-Linter (https://github.com/super-linter/super-linter) runs ESLint and Gitleaks (https://github.com/gitleaks/gitleaks) on every pull request. CredScan (https://secdevtools.azurewebsites.net/helpcredscan.html) and Guardian PostAnalysis run in the Azure DevOps PR pipeline, enforcing the M365 security policy. The repository rulesets require that all status checks pass before merging. Suppressed findings are documented with justification in configuration files such as CredScanSuppressions.json (https://github.com/microsoft/PR-Metrics/blob/main/.github/azure-devops/CredScanSuppressions.json) and gitleaks.toml (https://github.com/microsoft/PR-Metrics/blob/main/.github/linters/gitleaks.toml).



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.