platformlabeler-plugin

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

Если это ваш проект, пожалуйста, покажите свой значок на странице проекта! Статус значка выглядит следующим образом: Уровень значка для проекта 3537 - passing Вот как вставить его:

Это критерии уровня Passing. Вы также можете просмотреть критерии уровня Silver или Gold.

        

 Основы 13/13 ●

  • Идентификация

    Jenkins Platform Labeler plugin

    Какие языки программирования используются для реализации проекта?

  • Основная информация на веб-сайте проекта


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

    Веб-сайт проекта ОБЯЗАН кратко описывать, что делает программное обеспечение (какую проблему решает?). [description_good]

    https://github.com/jenkinsci/platformlabeler-plugin/blob/master/README.md describes the purpose of the plugin


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

    Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. [interact]

    https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md


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

    В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). (Требуется URL) [contribution]

    Non-trivial contribution file in repository: https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md.


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

    В информацию о том, как внести вклад, СЛЕДУЕТ включать требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]

    https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md includes items for:

    https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md#code-coverage - code coverage https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md#code-formatting - code formatting


  • Свободная лицензия

    Под какой/какими лицензией/ями выпускается проект?


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

    ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. [floss_license]

    The MIT license is approved by the Open Source Initiative (OSI).


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

    ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). [floss_license_osi]

    The MIT license is approved by the Open Source Initiative (OSI).


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

    Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. (Требуется URL) [license_location]

    Non-trivial license location file in repository: https://github.com/jenkinsci/platformlabeler-plugin/blob/master/LICENSE.txt.


  • Документация


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

    Проект ОБЯЗАН предоставлять базовую документацию для программного обеспечения, создаваемого проектом. [documentation_basics]

    // No appropriate folder found for documentation basics.

    See the README which provides basic documentation at https://github.com/jenkinsci/platformlabeler-plugin/blob/master/README.md


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

    Проект ОБЯЗАН предоставлять справочную документацию, описывающую внешний интерфейс (как входной, так и выходной) программного обеспечения, создаваемого проектом. [documentation_interface]

    Project intentionally does not provide a programmatic interface for either input or output. See https://github.com/jenkinsci/platformlabeler-plugin/blob/e761afbeb0137703418f802b706d4c8dcbed6f58/pom.xml#L45 for the comment stating that intentn


  • Другое


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

    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]

    Given only https: URLs.


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

    Проект ОБЯЗАН иметь один или несколько механизмов для обсуждения (включая предлагаемые изменения и проблемы), которые доступны для поиска, позволяют ссылаться на сообщения и темы по URL, позволяют новым людям участвовать в некоторых обсуждениях и не требуют установки на стороне клиента проприетарного программного обеспечения. [discussion]

    GitHub supports discussions on issues and pull requests.


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

    Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. [english]

    Bug reports accepted at https://issues.jenkins-ci.org/secure/Dashboard.jspa for the platformlabeler-plugin component.


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

    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]


(Дополнительно) Какие другие пользователи имеют дополнительные права на редактирование этой записи значка? В настоящее время: []



  • Публичное хранилище исходного кода с поддержкой версий


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

    Проект ОБЯЗАН иметь репозиторий (хранилище) исходного кода с управлением версиями, который является общедоступным и имеет URL. [repo_public]

    Repository on GitHub, which provides public git repositories with URLs.


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

    Проектный репозиторий исходного кода ОБЯЗАН отслеживать, какие изменения были внесены, кто внес изменения и когда изменения были сделаны. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


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

    Чтобы обеспечить возможность для проверки другими участниками, проектный репозиторий исходного кода ОБЯЗАН включать промежуточные версии для проверки между релизами; НЕДОПУСТИМО хранить в репозитории лишь финальные версии. [repo_interim]

    Project creates interim versions on https://ci.jenkins.io/job/Plugins/job/platformlabeler-plugin/view/change-requests/ and encourages reviewers to use those versions for evaluation.

    Project does not place those interim versions in the source repository. If the requirement of this best practice is that the interim versions is not satisfied by those interim versions being stored outside the source repository, then this criterion should be marked as "Unmet".


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

    Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). [repo_distributed]

    Repository on GitHub, which uses git. git is distributed.


  • Уникальная нумерация версий


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

    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]

    https://github.com/jenkinsci/platformlabeler-plugin/releases shows the release notes for the versions and documentation related to those releases.


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

    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]

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

    Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. [version_tags]

    https://github.com/jenkinsci/platformlabeler-plugin/releases shows the tags that are used for each release.


  • Примечания к выпуску


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

    Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). (Требуется URL) [release_notes]

    https://github.com/jenkinsci/platformlabeler-plugin/releases shows the release notes for each release.


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

    В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". [release_notes_vulns]

    When CVE's are published, they are identified in the release notes by CVE


  • Процесс сообщения об ошибках


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

    Проект ОБЯЗАН предоставить пользователям возможность отправлять сообщения об ошибках (например, используя систему отслеживания ошибок или список рассылки). (Требуется URL) [report_process]

    https://issues.jenkins-ci.org/secure/Dashboard.jspa using the component platformlabeler-plugin


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

    СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    See https://issues.jenkins-ci.org/browse/JENKINS-9586 as an example of an issue tracked, or https://issues.jenkins-ci.org/browse/JENKINS-9586 as an issue tracked and resolved.


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

    Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. [report_responses]

    All bug reports are assigned to the maintainer by default. The maintainer acknowledges the bug report by commenting on the bug report and by unassigning the bug report to show that the report has been reviewed.

    Bug reports which are being actively investigated are assigned to a person. Once investigation is complete, they are unassigned.


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

    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]

    Refer to https://issues.jenkins-ci.org/issues/?jql=project%20%3D%20JENKINS%20AND%20component%20%3D%20platformlabeler-plugin for the evidence that more than 50% of enhancement requests in the last 2-12 months have received a response. In this case, 80% or more of the enhancement requests have been implemented in the last 2-12 months.


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

    Проект ОБЯЗАН иметь общедоступный архив для отчетов и ответов для последующего поиска. (Требуется URL) [report_archive]

    https://issues.jenkins-ci.org/issues/?jql=project%20%3D%20JENKINS%20AND%20component%20%3D%20platformlabeler-plugin


  • Процесс отчета об уязвимостях


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

    Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. (Требуется URL) [vulnerability_report_process]

    https://jenkins.io/security/reporting/ provides instructions for reporting vulnerabilities on all Jenkins components. Link to that page is included in the CONTRIBUTING file for the project


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

    Если поддерживаются приватные отчеты об уязвимости, проект ОБЯЗАН включить описание того, как отправлять сведения конфиденциальным способом. (Требуется URL) [vulnerability_report_private]

    https://jenkins.io/security/reporting/


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

    Проект ОБЯЗАН обеспечивать время первоначального отклика на любой отчет об уязвимости, полученный за последние 6 месяцев, в пределах 14 дней или меньше. [vulnerability_report_response]

    No vulnerability reports for this project in the last 6 months.


  • Рабочая система сборки


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

    Если программное обеспечение, создаваемое проектом, требует сборки для использования, проект ОБЯЗАН предоставить рабочую систему сборки, которая может автоматически пересобирать программное обеспечение из исходного кода. [build]

    Non-trivial build file in repository: https://github.com/jenkinsci/platformlabeler-plugin/blob/master/pom.xml.

    https://ci.jenkins.io/job/Plugins/job/platformlabeler-plugin/view/change-requests/ hosts the builds


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

    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]

    Non-trivial build file in repository: https://github.com/jenkinsci/platformlabeler-plugin/blob/master/pom.xml.

    Apache maven with builds on every commit as provided by https://ci.jenkins.io/job/Plugins/job/platformlabeler-plugin/view/change-requests/


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

    Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. [build_floss_tools]

    Apache maven and Jenkins are FLOSS tools


  • Набор автотестов


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

    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]

    Tests are stored in the src/tests directory tree


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

    Запуск набора тестов СЛЕДУЕТ реализовывать стандартным способом для этого языка. [test_invocation]

    Tests are run using standard maven goals (like verify)


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

    ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. [test_most]

    Coverage is over 90% of statements and branches.


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

    ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). [test_continuous_integration]

    https://ci.jenkins.io/job/Plugins/job/platformlabeler-plugin/view/change-requests/ provides continuous integration


  • Тестирование новых функций


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

    Проект ОБЯЗАН иметь общую политику (формальную или нет), обязывающую добавлять тесты в набор автоматических тестов по мере добавления новых функциональных возможностей к программному обеспечению, создаваемому проектом. [test_policy]

    https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md#code-coverage encourages submitters to add tests when they add new capabilities.


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

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

    Code coverage reports are monitored and confirmed that coverage remains over 90%.


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

    ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. [tests_documented_added]

    Pull request template includes a checkbox "I have added tests that verify my changes. See https://github.com/jenkinsci/platformlabeler-plugin/blob/master/CONTRIBUTING.md#code-coverage and https://github.com/jenkinsci/platformlabeler-plugin/blob/master/.github/pull_request_template.md


  • Флаги предупреждений


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

    Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. [warnings]

    The spotbugs, checkstyle, tidy, and fmt-maven-plugin tools are used to check for code quality errors and common mistakes.


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

    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]

    Едва достаточно для значка.

    ЖЕЛАТЕЛЬНО, чтобы проекты использовали самый строгий режим предупреждений в производимом ПО, где это целесообразно. [warnings_strict]

    The checkstyle warnings at maximum strictness are excessive.


  • Знание безопасной разработки


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

    По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). [know_secure_design]

    Maintainer has been on the project for 18 months, has contributed significant commits to improve the project, and has delivered many releases.


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

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

  • Основы правильного использования криптографии

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

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

    Программное обеспечение, созданное проектом, ОБЯЗАНО использовать по умолчанию только публикуемые криптографические протоколы и алгоритмы, которые анализируются экспертами (если используются криптографические протоколы и алгоритмы). [crypto_published]

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

    Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. [crypto_call]

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

    Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. [crypto_floss]

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

    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. [crypto_keylength]

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

    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. [crypto_working]

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

    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕ СЛЕДУЕТ делать зависимыми от криптографических алгоритмов или режимов с известными серьезными слабостями (например, криптографический алгоритм хеширования SHA-1 или режим CBC в SSH). [crypto_weaknesses]

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

    В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. [crypto_pfs]

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

    Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). [crypto_password_storage]

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

    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]

  • Доставка, защищенная от атак посредника (MITM)


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

    Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. [delivery_mitm]

    Jenkins update center is currently delivering over http rather than https but Jenkins artifactory provides https secured access to the same binary files that could be used to verify the http delivered binary is unharmed.


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

    НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. [delivery_unsigned]

    Crytpographic hashes (SHA-256, SHA-1, MD5) are available from the https secure Jenkins artifactory but are not checked from that source. The source which checks them is reading the files through http rather than https.

    See https://repo.jenkins-ci.org/webapp/#/artifacts/browse/tree/General/releases/org/jvnet/hudson/plugins/platformlabeler/5.4/platformlabeler-5.4.hpi for an example page that shows the checksums.


  • Исправление обнародованных уязвимостей


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

    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]

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

    Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. [vulnerabilities_critical_fixed]

  • Другие вопросы безопасности


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

    НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. [no_leaked_credentials]

  • Статический анализ кода


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

    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]

    spotbugs, checkstyle, tidy, and fmt-maven-plugin are all used for various forms of static code analysis


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

    ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. [static_analysis_common_vulnerabilities]

    Spotbugs is run regularly and results are reported. If any warnings are reported, the build is marked as 'failed'. No warnings in current code.


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

    Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. [static_analysis_fixed]

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

    ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. [static_analysis_often]

    The spotbugs analysis is included on each commit, visible through https://ci.jenkins.io/job/Plugins/job/platformlabeler-plugin/job/master/lastBuild/console


  • Динамический анализ кода


    Едва достаточно для значка.

    ЖЕЛАТЕЛЬНО применять по крайней мере один инструмент динамического анализа к любой предлагаемой основной (major) версии программного обеспечения перед ее выпуском . [dynamic_analysis]

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

    ЖЕЛАТЕЛЬНО регулярно использовать по меньшей мере один динамический инструмент (например, fuzzer или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера, если программное обеспечение, создаваемое проектом, включает части, написанные на небезопасном языке (например, C или C++). Если проект не создает программное обеспечение, написанное на небезопасном языке, выберите «неприменимо» (N/A). [dynamic_analysis_unsafe]

    Едва достаточно для значка.

    ЖЕЛАТЕЛЬНО включать в ПО, создаваемое проектом, достаточно много утверждений (assertions) времени выполнения, проверяемых при динамическом анализе. Во многих случаях эти утверждения не должны попадать в сборки под эксплуатацию (production). [dynamic_analysis_enable_assertions]

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

    Проект ОБЯЗАН своевременно исправлять все уязвимости средней и выше степени серьезности, обнаруженные при динамическом анализе кода, после их подтверждения. [dynamic_analysis_fixed]

    Not running dynamic code analysis and thus have not found any vulnerabilities this way.



Эти данные доступны под лицензией Creative Commons Attribution версии 3.0 или более поздней (CC-BY-3.0+). Все могут свободно делиться и адаптировать эти данные, но должны указывать соответствующие ссылки. При распространении, пожалуйста, указывайте "Mark Waite and the OpenSSF Best Practices badge contributors".

Владелец анкеты на значок проекта: Mark Waite.
2019-12-26 14:20:57 UTC, последнее изменение сделано 2022-03-26 03:07:52 UTC. Последний раз условия для получения значка были выполнены 2020-01-07 22:36:34 UTC.

Назад