PR Metrics

Проекты, которые следуют приведенным ниже лучшим практикам, могут добровольно и самостоятельно оценить себя и продемонстрировать, что они получили значок Open Source Security Foundation (OpenSSF).

Не существует набора практик, гарантирующего, что у программного обеспечения никогда не будет недостатков или уязвимостей; даже формальные методы могут не помочь, если спецификации или допущения ошибочны. Также не существует какой-либо практики, которая могла бы гарантировать, что проект будет поддерживать здоровое и хорошо функционирующее сообщество разработчиков. Однако следующие хорошие правила могут помочь улучшить результаты проектов. Например, некоторые правила описывают ревью несколькими участниками перед выпуском, что может помочь найти технические уязвимости, которые было бы сложно найти другим способом, и помочь построить доверие и желание дальнейшего взаимодействия между разработчиками из разных компаний. Чтобы получить значок, нужно выполнить все критерии с ключевыми словами "НЕОБХОДИМО"/"ОБЯЗАН"/"НЕДОПУСТИМО", все критерии со словом "СЛЕДУЕТ" либо должны удовлетворяться, либо должно быть приведено обоснование их невыполнения, и все критерии со словом "ЖЕЛАТЕЛЬНО" могут быть удовлетворены ИЛИ неудовлетворены (желательно, чтобы они были хотя бы рассмотрены). Если вы хотите ввести общий комментарий вместо объяснения, почему текущая ситуация приемлема, начните текст с '//' и пробела. Приветствуется обратная связь через сайт на GitHub в виде issues или pull requests. Существует также список рассылки для общих вопросов.

Мы с удовольствием предоставляем информацию на нескольких языках, однако, если есть какой-либо конфликт или несоответствие между переводами, английская версия является авторитетной.
Если это ваш проект, пожалуйста, отобразите статус вашего базового значка на странице проекта! Статус базового значка выглядит так: Базовый уровень значка для проекта 11987 - baseline-3 Вот как встроить базовый значок:
Вы можете показать статус базового значка, вставив это в ваш файл markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/11987/baseline)](https://www.bestpractices.dev/projects/11987)
или вставив это в ваш HTML:
<a href="https://www.bestpractices.dev/projects/11987"><img src="https://www.bestpractices.dev/projects/11987/baseline"></a>


Это критерии Базового Уровня 2. Эти критерии относятся к базовой версии v2025.10.10 с обновлённым текстом критериев из версии v2026.02.19. Критерии, новые в версии v2026.02.19, помечены как «будущие» и начнут применяться с 2026-06-01. Пожалуйста, предоставьте ответы на «будущие» критерии до этой даты.

Baseline Series: Базовый уровень 1 Базовый Уровень 2 Базовый Уровень 3

        

 Основы

  • Общая

    Обратите внимание, что другие проекты могут использовать то же имя.

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

    Используйте формат выражения лицензии SPDX; примеры включают «Apache-2.0», «BSD-2-Clause», «BSD-3-Clause», «GPL-2.0+», «LGPL-3.0+», «MIT» и «(BSD-2-Clause OR Ruby)».
    Если используется более одного языка, перечислите их через запятую (пробелы необязательны), и отсортируйте их от наиболее до наименее используемого. Если список длинный, пожалуйста, перечислите по крайней мере три наиболее распространенных. Если языка нет (например, это проект только для документации или только для тестирования), используйте один символ «-» (минус). Для каждого языка используйте общепринятую капитализацию названия, например «JavaScript».
    Common Platform Enumeration (CPE) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

 Элементы управления 18/19 ●

  • Элементы управления


    Достаточно для значка!

    Когда задача CI/CD выполняется без указания прав доступа, система CI/CD ОБЯЗАНА по умолчанию назначать задаче минимальные права, предоставленные в конвейере. [OSPS-AC-04.01]
    Настройте параметры проекта для назначения минимальных доступных прав новым конвейерам по умолчанию, предоставляя дополнительные права только при необходимости для конкретных задач.

    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.


    Достаточно для значка!

    Когда создается официальный выпуск, этому выпуску ОБЯЗАН быть назначен уникальный идентификатор версии. [OSPS-BR-02.01]
    Присваивайте уникальный идентификатор версии каждому выпуску, создаваемому проектом, следуя согласованному соглашению о наименовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор коммита 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.


    Достаточно для значка!

    Когда создается официальный выпуск, этот выпуск ОБЯЗАН содержать описательный журнал функциональных изменений и изменений безопасности. [OSPS-BR-04.01]
    Убедитесь, что все выпуски содержат описательный журнал изменений. Рекомендуется обеспечить, чтобы журнал изменений был читаемым человеком и содержал более подробные сведения, чем сообщения коммитов, такие как описания влияния на безопасность или релевантность для различных сценариев использования. Для обеспечения машиночитаемости размещайте содержимое под заголовком markdown, таким как "## 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.


    Достаточно для значка!

    Когда конвейер сборки и выпуска загружает зависимости, он ОБЯЗАН использовать стандартизированные инструменты, где они доступны. [OSPS-BR-05.01]
    Используйте общие инструменты для вашей экосистемы, такие как менеджеры пакетов или инструменты управления зависимостями для загрузки зависимостей во время сборки. Это может включать использование файла зависимостей, lock-файла или манифеста для указания требуемых зависимостей, которые затем подключаются системой сборки.

    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.


    Достаточно для значка!

    Когда создается официальный выпуск, этот выпуск ОБЯЗАН быть подписан или учтен в подписанном манифесте, включающем криптографические хеши каждого актива. [OSPS-BR-06.01]
    Подписывайте все выпущенные программные активы во время сборки с использованием криптографической подписи или аттестаций, таких как подпись GPG или PGP, подписи Sigstore, происхождение SLSA или SLSA VSA. Включите криптографические хеши каждого актива в подписанный манифест или файл метаданных.

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


    Достаточно для значка!

    Когда проект создал выпуск, документация проекта ОБЯЗАНА включать описание того, как проект выбирает, получает и отслеживает свои зависимости. [OSPS-DO-06.01]
    Рекомендуется публиковать эту информацию вместе с технической документацией и документацией по дизайну проекта в общедоступном ресурсе, таком как репозиторий исходного кода, веб-сайт проекта или другой канал.

    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.


    Не хватает обязательной информации, недостаточно для значка.

    (Будущий критерий) Документация проекта ДОЛЖНА включать инструкции по сборке программного обеспечения, включая необходимые библиотеки, фреймворки, SDK и зависимости. [OSPS-DO-07.01]
    Рекомендуется публиковать эту информацию вместе с документацией для участников проекта, например в файле CONTRIBUTING.md или другой документации по задачам разработчика. Это также может быть задокументировано с помощью целей Makefile или других сценариев автоматизации.

    Достаточно для значка!

    Пока проект активен, документация проекта ОБЯЗАНА включать список членов проекта с доступом к критическим ресурсам. [OSPS-GV-01.01]
    Документируйте участников проекта и их роли с помощью таких артефактов, как members.md, governance.md, maintainers.md или аналогичного файла в репозитории исходного кода проекта. Это может быть просто включение имен или учетных записей в список сопровождающих или более сложное в зависимости от управления проектом.

    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.


    Достаточно для значка!

    Пока проект активен, документация проекта ОБЯЗАНА включать описания ролей и обязанностей для членов проекта. [OSPS-GV-01.02]
    Документируйте участников проекта и их роли с помощью таких артефактов, как members.md, governance.md, maintainers.md или аналогичного файла в репозитории исходного кода проекта.

    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.


    Достаточно для значка!

    Пока проект активен, документация проекта ОБЯЗАНА включать руководство для участников кода, которое включает требования к приемлемым вкладам. [OSPS-GV-03.02]
    Расширьте содержимое CONTRIBUTING.md или CONTRIBUTING/ в документации проекта, чтобы изложить требования к приемлемым вкладам, включая стандарты кодирования, требования к тестированию и руководства по отправке для участников кода. Рекомендуется, чтобы это руководство было источником истины как для участников, так и для утверждающих.

    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.


    Достаточно для значка!

    Пока проект активен, система контроля версий ОБЯЗАНА требовать от всех участников кода утверждать, что они имеют законное право вносить соответствующий вклад в каждом коммите. [OSPS-LE-01.01]
    Включите DCO в репозиторий проекта, требуя от участников кода утверждать, что они имеют законное право вносить соответствующий вклад в каждом коммите. Используйте проверку статуса, чтобы убедиться, что утверждение сделано. CLA также удовлетворяет этому требованию. Некоторые системы контроля версий, такие как GitHub, могут включать это в условия обслуживания платформы.

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


    Достаточно для значка!

    При внесении коммита в основную ветку все автоматические проверки статуса для коммитов ДОЛЖНЫ пройти успешно или быть явно обойдены вручную. [OSPS-QA-03.01]
    Настройте систему контроля версий проекта таким образом, чтобы все автоматические проверки статуса должны были пройти успешно или требовать ручного подтверждения перед тем, как коммит может быть объединен с основной веткой. Рекомендуется НЕ настраивать необязательные проверки статуса как требование успешного прохождения или провала, которые утверждающие могут быть склонны обойти.

    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.


    Достаточно для значка!

    Перед принятием коммита в проекте ДОЛЖЕН выполняться хотя бы один автоматизированный набор тестов в конвейере CI/CD для обеспечения соответствия изменений ожиданиям. [OSPS-QA-06.01]
    Автоматизированные тесты должны выполняться перед каждым объединением с основной веткой. Набор тестов должен выполняться в конвейере CI/CD, и результаты должны быть видны всем участникам. Набор тестов должен выполняться в согласованной среде и таким образом, чтобы участники могли выполнять тесты локально. Примеры наборов тестов включают модульные тесты, интеграционные тесты и сквозные тесты.

    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.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать проектную документацию, демонстрирующую все действия и участников в системе. [OSPS-SA-01.01]
    Включите в документацию проекта проектные описания, объясняющие действия и участников. Участники включают любую подсистему или сущность, которая может повлиять на другой сегмент в системе. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

    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.


    Достаточно для значка!

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описания всех внешних программных интерфейсов выпущенных программных активов. [OSPS-SA-02.01]
    Документируйте все программные интерфейсы (API) выпущенных программных активов, объясняя, как пользователи могут взаимодействовать с программным обеспечением и какие данные ожидаются или производятся. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

    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.


    Достаточно для значка!

    Когда проект выпустил релиз, проект ДОЛЖЕН провести оценку безопасности для понимания наиболее вероятных и значимых потенциальных проблем безопасности, которые могут возникнуть в программном обеспечении. [OSPS-SA-03.01]
    Проведение оценки безопасности информирует как членов проекта, так и конечных потребителей о том, что проект понимает, какие проблемы могут возникнуть в программном обеспечении. Понимание того, какие угрозы могут быть реализованы, помогает проекту управлять рисками и справляться с ними. Эта информация полезна для конечных потребителей для демонстрации компетентности в области безопасности и практик проекта. Убедитесь, что эта информация обновляется для новых функций или критических изменений.

    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.


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА включать политику координированного раскрытия уязвимостей (CVD) с четко определенными сроками ответа. [OSPS-VM-01.01]
    Создайте файл SECURITY.md в корневом каталоге, описывающий политику проекта для координированного раскрытия уязвимостей. Включите метод сообщения об уязвимостях. Установите ожидания относительно того, как проект будет реагировать и решать сообщенные проблемы.

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


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА предоставлять средства для приватного сообщения об уязвимостях непосредственно контактам по безопасности в проекте. [OSPS-VM-03.01]
    Предоставьте средства для того, чтобы исследователи безопасности могли приватно сообщать об уязвимостях в проект. Это может быть специальный адрес электронной почты, веб-форма, специализированные инструменты системы контроля версий, адреса электронной почты контактов по безопасности или другие методы.

    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.


    Достаточно для значка!

    Пока проект активен, документация проекта ДОЛЖНА публично публиковать данные об обнаруженных уязвимостях. [OSPS-VM-04.01]
    Предоставляйте информацию об известных уязвимостях в предсказуемом публичном канале, таком как запись CVE, запись в блоге или другом носителе. По мере возможности эта информация должна включать затронутые версии, как потребитель может определить, уязвим ли он, и инструкции по смягчению последствий или исправлению.

    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.



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Muiris Woulfe и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Muiris Woulfe.
2026-02-19 17:32:37 UTC, последнее изменение сделано 2026-02-27 19:06:06 UTC. Значок последний раз потерян 2026-02-23 14:15:17 UTC. Последний раз условия для получения значка были выполнены 2026-02-23 14:43:51 UTC.