WhitePact

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

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

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


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

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

        

 Основы 1/5 ●

  • Общая

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

    WhitePact is an open-source runtime authority, governance, and assurance layer for autonomous systems. It provides deterministic five-way authorization decisions (ALLOW, ALLOW_WITH_REDACTION, REQUIRE_APPROVAL, DENY, QUARANTINE), policy and risk enforcement, human approval workflows, tamper-evident evidence, MCP governance, trust controls, guardrails, and enterprise integration tooling.

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

  • Предварительные требования


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

    Проект ОБЯЗАН получить серебряный значок. [achieve_silver]

  • Надзор за проектом


    Недостаточно для значка.

    Проект ОБЯЗАН иметь «коэффициент автобуса» 2 или более. (Требуется URL) [bus_factor]
    «Коэффициент автобуса» (или «коэффициент грузовика») - это минимальное количество участников проекта, которые должны внезапно исчезнуть из проекта («попасть под автобус»), чтобы проект заглох из-за отсутствия квалифицированного или компетентного персонала. Инструмент truck-factor может оценить это для проектов на GitHub. Для получения дополнительной информации см. статью Cosentino et al. Assessing the Bus Factor of Git Repositories.

    Unmet. The complete repository history contains commits under one contributor identity, and the repository governance documents identify WhitePact as founder-led with one maintainer. A second maintainer with equivalent project knowledge is not established.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/GOVERNANCE.md


    Недостаточно для значка.

    Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. (Требуется URL) [contributors_unassociated]
    Соавторы связаны, если они оплачиваются работой одной и той же организации (как работник или подрядчик), и организация может выиграть от результатов проекта. Финансовые гранты не считаются находящимися в одной организации, если они проходят через другие организации (например, гранты на науку, выплачиваемые различным организациям из общего правительства или источника НПО, не приводят к тому, что вкладчики могут быть связаны). Соавтор считается значительным, если за последний год он(а) внес(ла) заметный вклад в проект. Примерами хороших показателей значительного соавтора являются: написано не менее 1000 строк кода, внесено 50 коммитов или предоставлено не менее 20 страниц документации.

    Unmet. The public repository history does not show two unassociated significant contributors; commits are attributed to Guruprasath Annadurai under multiple email addresses, and CODEOWNERS lists only the repository owner.

    https://github.com/Guruprasath-Annadurai/Whitepact/graphs/contributors
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/CODEOWNERS


  • Другое


    Недостаточно для значка.

    Проект ОБЯЗАН указывать лицензию в каждом исходном файле. Это МОЖЕТ быть сделано путем включения в комментарий рядом с началом каждого файла следующей строки: SPDX-License-Identifier: [SPDX-выражение лицензии для проекта]. [license_per_file]
    Это МОЖЕТ также быть сделано путем указания лицензии на естественном языке. Проект МОЖЕТ также включать стабильный URL-адрес, указывающий на текст лицензии, или полный текст лицензии. Обратите внимание, что критерий license_location требует помещать лицензию проекта в стандартном расположении. См. этот учебник SPDX для получения дополнительных сведений об SPDX-выражениях лицензии. Обратите внимание на связь с критерием copyright_per_file, содержимое для которого обычно предшествует информации о лицензии.

    Unmet. The current source files do not include per-file license or SPDX-License-Identifier statements. The root MIT LICENSE file does not satisfy this per-file Gold criterion.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/LICENSE


 Управление изменениями 4/4 ●

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


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

    Хранилище проектного исходного кода ОБЯЗАНО использовать типовое ПО для распределенного управления версиями (например, git или mercurial). [repo_distributed]
    Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

    WhitePact's public source repository is hosted on GitHub and uses Git, a distributed version-control system.

    https://github.com/Guruprasath-Annadurai/Whitepact


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

    Проект ОБЯЗАН четко обозначать небольшие задачи, которые могут быть выполнены новыми или случайными участниками. (Требуется URL) [small_tasks]
    Это обозначение обычно делается путем маркировки выбранных проблем в трекере одним или несколькими тегами, которые использует проект для этой цели, например up-for-grabs, «только для новичков», «Небольшое исправление», «микрозадача» или IdealFirstBug. Эти новые задачи не обязательно требуют добавления функциональности; это может быть улучшение документации, добавление тестовых кейсов или что-то еще, что помогает проекту и помогает участнику лучше понять проект.

    STATUS: MET
    EVIDENCE: WhitePact issue #53 defines a bounded starter task to add focused unit tests for the OpenSSF action-pin policy checker, including explicit scope, constraints, and acceptance criteria. The issue is open and requires no runtime behavior change.
    JUSTIFICATION: This is a concrete small task suitable for a new or casual contributor; it is not a fabricated contributor or meaningless compliance issue.
    URL: https://github.com/Guruprasath-Annadurai/Whitepact/issues/53


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

    Проект ОБЯЗАН требовать двухфакторной аутентификации (ДФА) от разработчиков для изменения центрального хранилища или доступа к конфиденциальным данным (например, приватным отчетам об уязвимостях). Этот механизм ДФА МОЖЕТ использовать механизмы без криптографической защиты, такие как SMS, хотя это не рекомендуется. [require_2FA]

    STATUS: MET
    EVIDENCE: On 2026-08-29, the authenticated GitHub owner security page showed two-factor authentication enabled and required for the sole account able to change the central repository and access private vulnerability reports.
    JUSTIFICATION: WhitePact currently has one write-capable maintainer; GitHub requires that account to use 2FA. No additional maintainer or developer access was claimed.
    URL: https://github.com/Guruprasath-Annadurai/Whitepact


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

    При двухфакторной аутентификации (ДФА) проекту СЛЕДУЕТ использовать криптографические механизмы для предотвращения имперсонации. ДФА на основе службы коротких сообщений (SMS) сама по себе НЕ соответствует этому критерию, поскольку короткие сообщения не шифруются. [secure_2FA]
    Механизм ДФА, который соответствует этому критерию, может быть приложением для генерации временных одноразовых паролей (Time-based One-Time Password, TOTP), которое автоматически генерирует код аутентификации, меняющийся через определенный промежуток времени. Обратите внимание, что GitHub поддерживает TOTP.

    STATUS: MET
    EVIDENCE: On 2026-08-29, the authenticated GitHub owner security page showed a configured passkey, an authenticator app, and passkeys selected as the preferred 2FA method.
    JUSTIFICATION: The sole write-capable maintainer uses cryptographic 2FA; this answer does not rely on SMS-only authentication and does not claim any additional maintainers.
    URL: https://github.com/Guruprasath-Annadurai/Whitepact


 Качество 4/7 ●

  • Стандарты кодирования


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

    Проект ОБЯЗАН документировать свои требования по ревью кода, в том числе, как проводится ревью кода, что необходимо проверять и что необходимо для приемлемости кода. (Требуется URL) [code_review_standards]
    См. также критерии two_person_review и contrib_requirements.

    The repository documents its pull-request acceptance requirements, mandatory tests and CI, code style, coverage expectations, security checks, and vulnerability classes reviewers should check. The pull-request template provides the concrete review checklist. This documents the standard; it does not claim that independent review currently occurs.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md#pull-request-guidelines
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/PULL_REQUEST_TEMPLATE.md


    Недостаточно для значка.

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

    Unmet. The repository's own branch-protection evidence records required_approving_review_count: 0 because WhitePact has one maintainer. The merged pull requests inspected do not provide evidence that at least 50% of released modifications were reviewed by a person other than the author. PR and CI gates are not substitutes for independent human review.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/OSPS_BASELINE_BRANCH_PROTECTION.md


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


    Недостаточно для значка.

    Проект ОБЯЗАН обеспечивать воспроизводимую сборку. Если сборка не требуется (например, в случае языков сценариев, где исходный код используется непосредственно вместо компиляции), выберите «N/A». (Требуется URL) [build_reproducible]
    Воспроизводимая сборка означает, что несколько сторон могут независимо повторить процесс генерации информации из исходных файлов и получить аналогичный результат с точностью до бита. В некоторых случаях воспроизводимости можно достичь путем принудительного выставления окружения. Разработчики JavaScript могут рассмотреть возможность использования npm shrinkwrap и webpack OccurenceOrderPlugin. Пользователи GCC и clang могут найти полезной опцию -frandom-seed. Среда сборки (включая набор инструментов) часто может быть определена для внешних сторон путём указания криптографической суммы (hash) для конкретного контейнера или виртуальной машины, которые они могут использовать для пересборки. В проекте Reproducible Builds есть документация о том, как это сделать.

    Unmet. The repository builds wheel and source distributions in CI, but it does not publish a byte-for-byte reproducible-build procedure or independent rebuild comparison demonstrating identical artifacts from the same source. Build success and provenance are not the same as reproducibility.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml


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


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

    Набор тестов ОБЯЗАН запускаться стандартным способом для этого языка. (Требуется URL) [test_invocation]
    Например, «make check», «mvn test» или «rake test» (Ruby).

    The automated suite uses pytest and is invoked with the standard command pytest. CONTRIBUTING.md documents local invocation, and CI invokes pytest against the public tests directory.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/CONTRIBUTING.md#running-tests
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml


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

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

    WhitePact uses GitHub Actions CI on pushes to main/develop and pull requests to main. The workflow runs linting, formatting, type checking, dependency auditing, tests with coverage, a pure branch-coverage gate, distribution builds, and Helm validation.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml


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

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 90% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage90]

    Unknown. The repository does not publish a current, separately calculated statement-coverage result proving at least 90%. Its CI threshold is 80% for coverage.py's blended metric, which is not sufficient evidence for this distinct Gold criterion.


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

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

    The repository records a measured pure branch-coverage result of 80.19% (1469/1832 branches). CI generates coverage.json and runs scripts/check_branch_coverage.py --threshold 80 --fail, making pure branch coverage a hard gate.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/OPENSSF_DYNAMIC_ANALYSIS.md
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml


 Безопасность 5/5 ●

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

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

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

    В ПО, создаваемом проектом, НЕОБХОДИМО поддерживать безопасные протоколы для всех сетевых коммуникаций, такие как SSHv2 или новее, TLS1.2 или новее (HTTPS), IPsec, SFTP и SNMPv3. По умолчанию НЕОБХОДИМО отключать небезопасные протоколы, такие как FTP, HTTP, telnet, SSLv3 или более ранние версии, и SSHv1, и разрешать их только в том случае, если пользователь явным образом это задаёт. Если программное обеспечение, созданное проектом, не поддерживает сетевые коммуникации, выберите «неприменимо» (N/A). [crypto_used_network]

    WhitePact supports secure network communication through HTTPS/TLS for production deployments.

    TLS is terminated by the deployment's trusted reverse proxy, load balancer, ingress, or managed cloud edge. The documented production nginx configuration enables TLS 1.2 and TLS 1.3 with modern authenticated cipher suites.

    Plain HTTP is used for local/internal application transport and development, while public production endpoints are expected to be exposed through TLS.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/DEPLOYMENT.md


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

    Если ПО, создаваемое проектом, поддерживает или использует TLS, НЕОБХОДИМО поддерживать как минимум версию TLS 1.2. Примечание: предшественник TLS называется SSL. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_tls12]

    WhitePact supports TLS 1.2 or later for production network communication.

    The documented production reverse-proxy configuration explicitly enables TLS 1.2 and TLS 1.3. The WhitePact reference deployment has also been verified to negotiate TLS 1.3.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/DEPLOYMENT.md


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


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

    Веб-сайт проекта, репозиторий (если он доступен через Интернет) и сайт загрузки (если он существует отдельно) ОБЯЗАНЫ использовать упрочняющие безопасность (hardening) заголовки с неразрешающими значениями. (Требуется URL) [hardened_site]
    Обратите внимание, что GitHub отвечает этому критерию. Такие сайты как https://securityheaders.io/ могут быстро проверить использование. Ключевыми заголовками для упрочнения являются: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (выставленный в «nosniff»), X-Frame-Options и X-XSS-Protection. Статические веб-сайты без возможности входа в систему через веб-страницы могут опускать упрочняющие HTTP-заголовки CSP и X-XSS-Protection, поскольку в этом случае эти заголовки менее эффективны.

    STATUS: MET
    EVIDENCE: Live HTTP responses tested on 2026-08-29. http://whitepact.com redirects to HTTPS. The canonical https://whitepact.com response includes HSTS (max-age=31536000; includeSubDomains), CSP with default-src self, object-src none and frame-ancestors none, X-Content-Type-Options nosniff, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin, and Permissions-Policy disabling geolocation, microphone, and camera. No Set-Cookie header was emitted by the public homepage. http://www.whitepact.com redirects through HTTPS to the canonical apex. GitHub hosts the repository and release downloads over HTTPS with platform hardening.
    JUSTIFICATION: The project website, public repository, and release/download endpoints use HTTPS; the canonical project site supplies nonpermissive browser hardening headers verified from the actual production response.
    URL: https://whitepact.com https://github.com/Guruprasath-Annadurai/Whitepact


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


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

    Проект ОБЯЗАН иметь проверку безопасности за последние 5 лет. При проверке НЕОБХОДИМО учитывать требования и границы безопасности. [security_review]
    Эта оценка МОЖЕТ быть выполнена членами проекта и/или независимо. Эта оценка МОЖЕТ подкрепляться инструментами статического и динамического анализа, но кроме этого должна быть проверка человеком для выявления проблем (особенно в дизайне), которые инструменты не могут обнаружить.

    WhitePact performed and documented an internal security review on 2026-07-23 using Bandit, pip-audit, and manual review of authentication, authorization, SQL construction, outbound requests, and dangerous functions. It found and fixed SQL-injection-shaped and SSRF issues with regression tests. The review is explicitly self-review, not an independent pentest. The Security Assurance Case and threat model identify security requirements and trust boundaries.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/INTERNAL_SECURITY_REVIEW.md
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/SECURITY_ASSURANCE_CASE.md
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/THREAT_MODEL.md


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

    В ПО, создаваемом проектом, НЕОБХОДИМО использовать механизмы упрочнения безопасности (hardening), чтобы дефекты программного обеспечения с меньшей вероятностью приводили к уязвимостям в безопасности. (Требуется URL) [hardening]
    Механизмы упрочнения могут включать HTTP-заголовки, такие как Content Security Policy (CSP), флаги компилятора для противостояния атакам (например, -fstack-protector) или флаги компилятора, устраняющие неопределенное поведение. Для наших целей политика наименьших привилегий не считается механизмом упрочнения (использовать наименьшие достаточные привилегии важно, но этому посвящён отдельный критерий).

    WhitePact uses defense-in-depth hardening mechanisms to reduce the impact of software defects.

    The dashboard applies security response headers including Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Cache-Control, and Permissions-Policy.

    Additional hardening includes request rate limiting, RBAC, tenant isolation, SSRF defenses, strong secret generation, minimum cryptographic key-strength checks, secure error responses, automated SAST, dependency auditing, and security regression tests.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/src/responsibleai/dashboard/middleware.py


 Анализ 2/2 ●

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


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

    Проект ОБЯЗАН применять хотя бы один инструмент динамического анализа к любой предлагаемой основной версии ПО, создаваемого проектом до её выпуска. [dynamic_analysis]
    Инструмент динамического анализа проверяет программное обеспечение, выполняя его с конкретными входными данными. Например, проект МОЖЕТ использовать инструмент фаззинг-тестирования (например, American Fuzzy Lop) или сканер веб-приложений (например, OWASP ZAP или w3af). В некоторых случаях проект OSS-Fuzz может быть готов применить фаззинг-тестирование к вашему проекту. Для целей этого критерия инструмент динамического анализа должен каким-то образом варьировать исходные данные, чтобы искать проблемы разного рода или быть автоматическим набором тестов с покрытием веток исполнения не менее 80%. Страница Википедии о динамическом анализе и cтраница OWASP о фаззинг-тестировании указывают некоторые инструменты динамического анализа. Использование инструмента/ов анализа МОЖЕТ, но не обязано быть сосредоточено на поиске уязвимостей в безопасности.

    WhitePact applies dynamic analysis through its automated pytest suite. Repository evidence records 80.19% pure branch coverage (1469/1832), and CI enforces that threshold with scripts/check_branch_coverage.py --threshold 80 --fail before release.

    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/compliance/OPENSSF_DYNAMIC_ANALYSIS.md
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml


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

    Проекту СЛЕДУЕТ включать достаточно много утверждений (assertions) времени выполнения в создаваемом им ПО и проверять эти утверждения во время динамического анализа. [dynamic_analysis_enable_assertions]
    Этот критерий не предполагает включения утверждений на этапе эксплуатации; решение об этом полностью лежит на проекте и его пользователях. Вместо этого критерий направлен на улучшение обнаружения ошибок во время динамического анализа перед развертыванием. Использование утверждений при эксплуатации полностью отличается от такового во время динамического анализа (например, при тестировании). В некоторых случаях включать утверждения при эксплуатации крайне неразумно (особенно в компонентах с высокой степенью целостности). Существует множество аргументов против включения утверждений в выпускаемых сборках: например, библиотеки не должны вызывать сбой при вызове, присутствие утверждений может привести к отклонению магазинами приложений и/или активация их при рабочем использовании может привести к раскрытию частных данных, таких как закрытые ключи. Помните, что во многих дистрибутивах Linux NDEBUG не определен, поэтому C/C++assert() в таких рабочих средах по умолчанию будет включен. Может быть важно использовать другой механизм утверждений или определить NDEBUG для эксплуатации в этих средах.

    The public pytest suite contains runtime assertions across governance, authorization, security, API, MCP, persistence, and integration behavior, and CI executes those assertions on every qualifying push and pull request.

    https://github.com/Guruprasath-Annadurai/Whitepact/tree/main/tests
    https://github.com/Guruprasath-Annadurai/Whitepact/blob/main/.github/workflows/ci.yml



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/14112/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Смотрите нашу систему автоматизированных предложений о том, как это сделать. Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Guruprasath Annadurai и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Guruprasath Annadurai.
2026-08-17 09:21:34 UTC, последнее изменение сделано 2026-08-29 04:45:45 UTC. Последний раз условия для получения значка были выполнены 2026-08-17 11:38:17 UTC.