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>


Это критерии Базового Уровня 1. Эти критерии относятся к базовой версии 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) - это структурированная схема именования для информационных систем, программного обеспечения и пакетов. Она используется в ряде систем и баз данных для отчетов об уязвимостях.

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

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


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

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

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


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

    При добавлении нового соавтора система контроля версий ДОЛЖНА требовать ручного назначения прав доступа или по умолчанию ограничивать права доступа соавтора до минимально доступных привилегий. [OSPS-AC-02.01]
    Большинство публичных систем контроля версий настроены таким образом. Убедитесь, что система контроля версий проекта всегда назначает минимально доступные права доступа соавторам по умолчанию при добавлении, предоставляя дополнительные права доступа только при необходимости.

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


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

    При попытке прямого коммита в основную ветку проекта механизм принудительного исполнения ДОЛЖЕН предотвращать применение изменения. [OSPS-AC-03.01]
    Если VCS централизована, установите защиту ветки на основную ветку в VCS проекта. В качестве альтернативы используйте децентрализованный подход, как в ядре Linux, где изменения сначала предлагаются в другом репозитории, а слияние изменений в основной репозиторий требует специального отдельного действия.

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


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

    Когда предпринимается попытка удалить основную ветку проекта, система контроля версий ОБЯЗАНА рассматривать это как деликатное действие и требовать явного подтверждения намерения. [OSPS-AC-03.02]
    Установите защиту ветки на основную ветку в системе контроля версий проекта для предотвращения удаления.

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


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

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

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


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

    (Будущий критерий) Когда конвейер CI/CD работает с недоверенными снимками кода, он ДОЛЖЕН запрещать доступ к привилегированным учётным данным и ресурсам CI/CD. [OSPS-BR-01.03]
    Конвейеры CI/CD должны изолировать недоверенные снимки кода от привилегированных учётных данных и ресурсов. В частности, проекты должны следить за тем, чтобы рабочие процессы, выполняющие сборку или запуск кода до его проверки коллаборатором, не имели доступа к учётным данным CI/CD.

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

    Когда проект указывает URI как официальный канал проекта, этот URI ОБЯЗАН передаваться исключительно с использованием зашифрованных каналов. [OSPS-BR-03.01]
    Настройте веб-сайты и системы контроля версий проекта на использование зашифрованных каналов, таких как SSH или HTTPS для передачи данных. Убедитесь, что все инструменты и домены, на которые ссылается документация проекта, доступны только через зашифрованные каналы.

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


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

    Когда проект указывает URI как официальный канал распространения, этот URI ОБЯЗАН передаваться исключительно с использованием зашифрованных каналов. [OSPS-BR-03.02]
    Настройте конвейер выпуска проекта так, чтобы он получал данные только с веб-сайтов, API-ответов и других служб, которые используют зашифрованные каналы, такие как SSH или HTTPS для передачи данных.

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


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

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

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


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

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

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


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

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

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


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

    Пока проект активен, он ОБЯЗАН иметь один или несколько механизмов для публичных обсуждений предлагаемых изменений и препятствий в использовании. [OSPS-GV-02.01]
    Создайте один или несколько механизмов для публичных обсуждений в рамках проекта, таких как списки рассылки, мгновенные сообщения или трекеры задач, чтобы облегчить открытое общение и обратную связь.

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


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

    Пока проект активен, документация проекта ОБЯЗАНА включать объяснение процесса внесения вклада. [OSPS-GV-03.01]
    Создайте файл CONTRIBUTING.md или директорию CONTRIBUTING/ для описания процесса внесения вклада, включая шаги для отправки изменений и взаимодействия с сопровождающими проекта.

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


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

    Пока проект активен, лицензия на исходный код ОБЯЗАНА соответствовать определению Open Source от OSI или определению свободного программного обеспечения от FSF. [OSPS-LE-02.01]
    Добавьте файл LICENSE в репозиторий проекта с лицензией, которая является одобренной лицензией Open Source Initiative (OSI), или свободной лицензией, одобренной Фондом свободного программного обеспечения (FSF). Примеры таких лицензий включают MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) и GNU General Public License (GPL). Выпуск в публичное достояние соответствует этому контролю, если нет других ограничений, таких как патенты.

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


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

    Пока активен, лицензия для выпущенных программных активов ОБЯЗАНА соответствовать определению открытого ПО по OSI или определению свободного ПО по FSF. [OSPS-LE-02.02]
    Если с выпущенными программными активами включена другая лицензия, убедитесь, что это одобренная лицензия Open Source Initiative (OSI) или свободная лицензия, одобренная Free Software Foundation (FSF). Примеры таких лицензий включают MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL) и GNU General Public License (GPL). Обратите внимание, что лицензия для выпущенных программных активов может отличаться от лицензии для исходного кода.

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


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

    Пока активен, лицензия для исходного кода ОБЯЗАНА поддерживаться в файле LICENSE, файле COPYING или директории LICENSE/ соответствующего репозитория. [OSPS-LE-03.01]
    Включите лицензию исходного кода проекта в файл LICENSE проекта, файл COPYING или директорию LICENSE/, чтобы обеспечить видимость и ясность условий лицензирования. Имя файла МОЖЕТ иметь расширение. Если у проекта несколько репозиториев, убедитесь, что каждый репозиторий включает файл лицензии.

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


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

    Пока активен, лицензия для выпущенных программных активов ОБЯЗАНА быть включена в выпущенный исходный код или в файл LICENSE, файл COPYING или директорию LICENSE/ рядом с соответствующими выпущенными активами. [OSPS-LE-03.02]
    Включите лицензию выпущенных программных активов проекта в выпущенный исходный код или в файл LICENSE, файл COPYING или директорию LICENSE/ рядом с соответствующими выпущенными активами, чтобы обеспечить видимость и ясность условий лицензирования. Имя файла МОЖЕТ иметь расширение. Если у проекта несколько репозиториев, убедитесь, что каждый репозиторий включает файл лицензии.

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


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

    Пока активен, репозиторий исходного кода проекта ОБЯЗАН быть общедоступным для чтения по статическому URL. [OSPS-QA-01.01]
    Используйте общую систему контроля версий (VCS), такую как GitHub, GitLab или Bitbucket. Убедитесь, что репозиторий доступен для публичного чтения. Избегайте дублирования или зеркалирования репозиториев, если только хорошо видимая документация не разъясняет первичный источник. Избегайте частых изменений репозитория, которые могут повлиять на URL репозитория. Убедитесь, что репозиторий публичный.

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


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

    Система контроля версий ОБЯЗАНА содержать общедоступную запись всех внесенных изменений, кто внес изменения и когда были внесены изменения. [OSPS-QA-01.02]
    Используйте общую VCS, такую как GitHub, GitLab или Bitbucket, для поддержания публично доступной истории коммитов. Избегайте сжатия или перезаписи коммитов таким образом, чтобы это скрывало автора любых коммитов.

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


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

    Когда система управления пакетами это поддерживает, репозиторий исходного кода ОБЯЗАН содержать список зависимостей, учитывающий прямые языковые зависимости. [OSPS-QA-02.01]
    Это может быть в виде файла менеджера пакетов или файла языковых зависимостей, перечисляющего все прямые зависимости, такие как package.json, Gemfile или go.mod.

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


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

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

    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.


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

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

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


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

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

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


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

    Пока активна, документация проекта ОБЯЗАНА содержать контакты по вопросам безопасности. [OSPS-VM-02.01]
    Создайте файл security.md (или с аналогичным именем), который содержит контакты по вопросам безопасности для проекта.

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


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

    (Устаревший критерий) Когда конвейер CI/CD использует имя ветки в своей функциональности, это значение имени ОБЯЗАНО быть очищено и проверено перед использованием в конвейере. [OSPS-BR-01.02]

    Where CI/CD workflows reference branch names in shell commands, values are passed through environment variables rather than direct expression interpolation. For example, in build.yml (https://github.com/microsoft/PR-Metrics/blob/main/.github/workflows/build.yml), github.head_ref is assigned to env.HEAD_REF and accessed via $Env:HEAD_REF in PowerShell, preventing script injection. Branch names used in action with: parameters (e.g., actions/checkout ref) are not subject to shell injection.



Эти данные доступны по лицензии 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.