Wrangle

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

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

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


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

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

        

 Основы 17/17 ●

  • Общая

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

    Prepare scientific data with native Polars, reusable YAML protocols, a readable CLI and reproducible evidence. Researchers and agents use the same checked preparation engine.

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

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


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

    Проект ОБЯЗАН получить значок уровня Passing. [achieve_passing]

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


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

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

    CONTRIBUTING states acceptable researcher-focused changes, scientific declarations, coding rules, meaningful tests, documentation and review requirements. pyproject.toml specifies the enforced Ruff rules and exceptions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


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


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

    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании Developer Certificate of Origin (DCO), при котором пользователи добавляют строку "signed-off-by" в свои коммиты, а проект ссылается на веб-сайт DCO. Но этот механизм МОЖЕТ быть реализован и в качестве Лицензионного соглашения с участниками (Contributor License Agreement, CLA) или другого правового механизма. (Требуется URL) [dco]
    DCO является рекомендуемым механизмом, потому что его легко реализовать и отслеживать в исходном коде, а git напрямую поддерживает функцию "signed-off" при помощи "commit -s". Для большей эффективности лучше всего, если проектная документация объясняет, что означает "signed-off" для этого проекта. CLA - это юридическое соглашение, которое определяет условия, на которых произведения умственного труда были лицензированы для организации или проекта. Соглашение о назначении участника (contributor assignment agreement, CAA) является юридическим соглашением, которое передает права на произведения умственного труда другой стороне; проекты не обязаны иметь CAA, поскольку CAA увеличивает риск того, что потенциальные участники не будут вносить свой вклад, особенно если получатель является коммерческой организацией. Лицензии CLA от Apache Software Foundation (лицензия отдельного участника и корпоративное соглашение CLA) являются примерами CLA для проектов, считающих, что риски от такого рода CLA для проекта меньше, чем их преимущества.

    The project has no DCO or CLA mechanism for non-trivial contributions. Contributions use the existing MIT license through reviewed pull requests. A compulsory legal-origin attestation is not imposed by this modernization; its absence is a considered SHOULD limitation.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/LICENSE


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

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

    GOVERNANCE documents scope decisions, the lead maintainer, reviewer/contributor roles, release authority, disagreement handling and the process for governance changes.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


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

    Проект ОБЯЗАН определить правила поведения и разместить эти правила в стандартном месте. (Требуется URL) [code_of_conduct]
    Проекты могут повысить цивилизованность их сообщества и установить ожидания относительно приемлемого поведения, приняв правила поведения. Это может помочь избежать проблем до их возникновения и сделать проект более привлекательным местом, поощряющим участие. Правила должны быть сосредоточены только на поведении в сообществе или на рабочем месте проекта. Примерами правил поведения являются правила конфликтов на проекте ядра Linux, Contributor Covenant Code of Conduct, Кодекс поведения Debian, Ubuntu Code of Conduct, Правила поведения проекта Fedora, GNOME Code Of Conduct, KDE Community Code of Conduct">, Python Community Code of Conduct, The Ruby Community Conduct Guideline и The Rust Code of Conduct.

    CODE_OF_CONDUCT defines respectful behavior, prohibited conduct, private reporting, maintainer investigation/enforcement and an appeal route. It applies across project participation spaces.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CODE_OF_CONDUCT.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


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

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

    GOVERNANCE lists responsibilities and assignments for lead, reviewing and backup maintainers, contributors and security reporters. The lead is mikkokotila and the owner-confirmed backup is EnergyGuy3.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


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

    Проект ОБЯЗАН быть в состоянии продолжать работу с минимальным прерыванием, если какой-либо человек окажется недееспособен или убит. В частности, проект ОБЯЗАН быть в состоянии создавать и закрывать вопросы в трекере, принимать предложенные изменения и выпускать версии программного обеспечения через неделю после подтверждения того, что данный человек недееспособен или убит. Это МОЖЕТ быть реализовано через обеспечение кого-то ещё необходимыми ключами, паролами и законными правами для продолжения проекта. Лица, которые запускают проект СПО, МОГУТ сделать это, оставив ключи в сейфе и завещание, передающее все необходимые юридические права (например, для имен DNS). (Требуется URL) [access_continuity]

    The project owner confirms EnergyGuy3 can handle issues, merges and GitHub releases within one week if the lead is unavailable. Existing GitHub administrator access was verified. GOVERNANCE records this affirmation; an independent rehearsal is not claimed or required by this criterion.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security/releases.md


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

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

    The project owner identifies mikkokotila as lead and EnergyGuy3 as a functioning backup with issue/merge/release continuity and secure-development expertise. GOVERNANCE records the two maintainer assignments and owner affirmation.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


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


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

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

    ROADMAP gives dated October 2026 through September 2027 plans for researcher workflows, correctness and data preparation, with explicit excluded neural-network and generic infrastructure scope.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/ROADMAP.md


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

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

    The shipped architecture document describes inspect/draft/prepare, expression compilation, validation, eager/disk execution, publication, evidence and the Python/CLI boundary. The agent entry file links exact engine and manual paths.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/architecture.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/AGENTS.md


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

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

    The shipped security requirements define accepted inputs, allowlists, unresolved-decision gates, integrity/publication guarantees and environment/resource limits. SECURITY defines supported versions and vulnerability handling.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md


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

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

    The README and shipped getting-started guide supply complete CLI and Python examples, expected results and the real-file guided path. Executable examples are verified in CI and against installed distributions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/human_workflow.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/start_workflow.py


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

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

    The generated operation catalog is checked against engine definitions. Public CI executes all eight examples and installed-package workflows; the issue/PR templates match the current native preparation interface.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/build_catalog.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/verify_distribution.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/ISSUE_TEMPLATE/bug-report.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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

    НЕОБХОДИМО размещать ссылку на любые свои достижения, включая этот значок передовой практики, на главной странице проекта и/или веб-сайте в течение 48 часов после открытого признания достижения. (Требуется URL) [documentation_achievements]
    Достижением считается любой набор внешних критериев, над выполнением которых проект специально работал, включая некоторые значки. Эта информация не обязательно должна находиться на главной странице веб-сайта проекта. Проект с использованием GitHub может помещать достижения на главную страницу хранилища кода, добавляя их в файл README.

    The public README links the live OpenSSF Scorecard badge, published within forty-eight hours of assessment. Passing was awarded on 2026-10-01; the Best Practices badge is being published in the same session within its forty-eight-hour window. Evidence: https://github.com/autonomio/wrangle/blob/ae4ea7273889c39f4169ecdf7278f3f56c3be154/README.md https://www.bestpractices.dev/en/projects/15135


  • Общедоступность и интернационализация


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

    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [accessibility_best_practices]
    Для веб-приложений см. Руководство по обеспечению доступности веб-контента (WCAG) 2.0 и его поддерживающий документ Understanding WCAG 2.0; см. также W3C accessibility information. Для приложений с графическим интерфейсом рассмотрите использование соответствующих вашему окружению рекомендаций по обеспечению доступности (таких как GNOME, KDE, XFCE, Android, iOS, Mac и Windows (на русском)). Некоторые приложения с текстовым интерфейсом пользователя (например, программы на ncurses) могут сделать некоторые вещи, чтобы сделать себя более доступными (например, параметр `force-arrow-cursor` в `alpine`). Большинство приложений командной строки довольно общедоступны как они есть. Этот критерий часто неприменим, например, для библиотек программ. Вот несколько примеров действий или проблем, которые следует учитывать:
    • Должны предоставляться текстовые альтернативы для любого нетекстового контента, так чтобы его можно изменить на другие необходимые формы, например крупная печать, шрифт Брайля, озвучка текста, символы или упрощенный язык (Understanding WCAG 2.0 guideline 1.1)
    • Цвет не должен использоваться в качестве единственного визуального средства передачи информации, указания на действие, запрос реакции пользователя или выделения визуальных элементов. (WCAG 2.0 guideline 1.4.1)
    • Визуальное представление текста и изображений текста должно иметь контрастность не менее 4,5:1, за исключением большого текста, случайного текста и логотипов (WCAG 2.0 guideline 1.4.3)
    • Все функциональные возможности должны быть доступны с клавиатуры (WCAG guideline 2.1)
    • GUI или веб-проект ДОЛЖНЫ тестировать, по крайней мере, одно средство чтения экрана на целевой платформе(ах) (например, NVDA, Jaws или WindowEyes в Windows; VoiceOver на Mac и iOS; Orca на Linux/BSD; TalkBack на Android). Программы с текстовым интерфейсом пользователя МОГУТ по возможности сокращать переписывание текста на экране, чтобы предотвратить лишнее чтение средствами чтения экрана.

    The CLI provides keyboard-operated plain-text prompts, named choices, stable readable errors and complete textual guides. Unicode scientific labels are supported and notebook tables have headers. This supports accessible common paths; no unperformed user trial or formal conformance audit is claimed.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_presentation.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/getting_started.md


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

    Проекту СЛЕДУЕТ интернационализировать создаваемое ПО, чтобы обеспечить легкую локализацию под культуру, регион или язык целевой аудитории. Выберите «неприменимо» (N/A), если интернационализация (i18n) не применяется (например, ПО не генерирует текст, предназначенный для конечных пользователей, и не сортирует текст, читаемый человеком), [internationalization]
    Локализация "относится к адаптации продукта, приложения или содержимого документа для соответствия языковым, культурным и другим требованиям конкретного целевого рынка (языковому стандарту)". Интернационализация - это «проектирование и разработка продукта, приложения или содержимого документа, которые позволяют легкую локализацию под целевые аудитории, различающиеся по культуре, региону или языку». (См. «Локализация по сравнению с интернационализацией» на веб-сайте W3C.) Чтобы ПО соответствовало этому критерию, достаточно лишь интернационализации. Не требуется локализация для другого конкретного языка, так как после того, как программное обеспечение было интернационализировано, другие могут работать над локализацией.

    The human CLI and manuals are English and lack a localization framework. The current research workflows prioritize a small consistent interface and language-independent stable error codes; Unicode labels and data are supported. This is a considered SHOULD limitation, not N/A.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_presentation.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/_cli.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md


  • Другое


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

    Если на сайтах проекта (веб-сайт, хранилище и URL-адреса загрузки) хранятся пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с отдельной "солью" для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, Argon2id, Bcrypt, Scrypt или PBKDF2). Выберите «неприменимо» (N/A), если сайты проекта не хранят пароли для этой цели. [sites_password_security]
    Примечание: использование GitHub автоматически выполняет этот критерий. Этот критерий применяется только к паролям, используемым для аутентификации внешних пользователей на сайтах проекта (т.н. входящей аутентификации). Если сайты проекта должны подключаться к другим сайтам (т.н. исходящая аутентификация), им может потребоваться хранить аутентифицирующие данные (пароли, ключи) для этой цели как-то иначе (поскольку хранение контрольной суммы для этой цели бесполезно). В данном случае критерий crypto_password_storage применяется к сайтам проекта, по аналогии с критерием sites_https.

    The website/repository use GitHub, which the official Silver details explicitly state satisfies this password-storage criterion. Wrangle operates no additional password-authentication site.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security.md https://github.com/autonomio/wrangle https://www.bestpractices.dev/en/criteria/1?details=true&rationale=true#1.sites_password_security


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

 Отчеты о проблемах 3/3 ●

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


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

    Проект ОБЯЗАН использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    The public GitHub issue tracker records individual project reports and discussions.
    Evidence: https://github.com/autonomio/wrangle/issues


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


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

    Проект ОБЯЗАН отмечать автора(-ов) всех отчетов об уязвимостях, разрешенных за последние 12 месяцев, за исключением авторов, которые просят об анонимности. Выберите «неприменимо» (N/A), если в течение последних 12 месяцев не было обнаружено никаких уязвимостей. (Требуется URL) [vulnerability_report_credit]

    The project owner confirms every applicable vulnerability report resolved in the last twelve months credited its reporter, except where anonymity was requested. No resolved-report count or absence is inferred. Owner attestation: https://github.com/autonomio/wrangle/blob/6dbd01b69f987030ed9aa8fc2f2d4d298fa03f70/wrangle/docs/security/openssf-evidence.yaml
    Evidence: https://github.com/autonomio/wrangle/blob/6dbd01b69f987030ed9aa8fc2f2d4d298fa03f70/wrangle/docs/security/openssf-evidence.yaml


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

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

    SECURITY documents private reporting, acknowledgment, reproduction, severity, remediation targets, coordinated disclosure, credit and release communication. The lead maintainer owns triage and the owner-confirmed backup covers continuity.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/GOVERNANCE.md


 Качество 19/19 ●

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


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

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

    CONTRIBUTING specifies PEP 8 with deliberate compactness exceptions. pyproject.toml defines the exact selected Ruff correctness/layout rules and local exclusions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


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

    Проект ОБЯЗАН автоматически применять свой выбранный стиль(и) кодирования, если есть хотя бы один инструмент на СПО, который может сделать это на выбранном языке (языках). [coding_standards_enforced]
    Это МОЖЕТ быть реализовано при помощи инструмента(ов) статического анализа и/или путем пропускания кода через средства переформатирования. Во многих случаях конфигурация инструмента включена в репозиторий проекта (так как разные проекты могут выбирать разные конфигурации). Проекты МОГУТ (и, как правило, будут) допускать исключения стиля; там, где происходят исключения, они ОБЯЗАНЫ быть редки и документированы в соответствующих местах кода, чтобы эти исключения можно было пересматривать и инструменты могли автоматически обрабатывать их в будущем. Примеры таких инструментов включают ESLint (JavaScript) и Rubocop (Ruby).

    CI runs Ruff over the production package and scripts and fails on violations of the configured standard. The public quality job passes; this is configured lint enforcement, not an unconfigured formatter claim.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/ci-push.yml https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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


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

    Системы сборки для нативных двоичных файлов ОБЯЗАНЫ учитывать соответствующие переменные (среды) для компилятора и компоновщика, переданные им (например, CC, CFLAGS, CXX, CXXFLAGS и LDFLAGS) и передавать их на вызовы компилятора и компоновщика. Система сборки МОЖЕТ расширять их дополнительными флагами; НЕДОПУСТИМО просто заменять предоставленные значения своими. Выберите «неприменимо» (N/A), если нативные двоичные файлы не создаются. [build_standard_variables]
    Должно быть легко включить специальные функции сборки, такие как Address Sanitizer (ASAN), или выполнить рекомендации по упрочнению от дистрибутивов (например, путем простого включения флагов компилятора для этого).

    Wrangle distributes interpreted Python source and compiles no project-native binaries, so compiler/linker environment-variable requirements are inapplicable. External native dependencies are built by their own projects.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/architecture.md


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

    В системах сборки и установки СЛЕДУЕТ сохранять отладочную информацию, если передаваемые флаги требуют этого (например, не используется «install -s»). Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, для типичных библиотек JavaScript), . [build_preserve_debug]
    Например, установка CFLAGS (C) или CXXFLAGS (C++) должна создавать соответствующую информацию для отладки, если эти языки используются, и ее не следует удалять во время установки. Отладочная информация необходима для поддержки и анализа, а также полезна для того, чтобы определить наличие упрочняющих функций в скомпилированных двоичных файлах.

    The wheel and source archive retain Wrangle Python source. The project performs no stripping of debugging information, and installed-distribution verification exercises the packaged files.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/verify_distribution.py


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

    НЕДОПУСТИМО, чтобы система сборки ПО, создаваемого проектом, рекурсивно собирала подкаталоги, если в подкаталогах есть кросс-зависимости. Выберите «неприменимо» (N/A), если системы сборки или установки нет (например, типичные библиотеки JavaScript). [build_non_recursive]
    Информация о внутренних зависимостях системы сборки проекта должна быть точной, в противном случае изменения в проекте могут быть включены в сборку неправильно. Неправильные сборки могут привести к дефектам (включая уязвимости). Общей ошибкой в ​​больших системах сборки является использование «рекурсивной сборки» или «рекурсивного make», то есть иерархии подкаталогов, содержащих исходные файлы, где каждый подкаталог собирается независимо. Если только каждый из подкаталогов не является полностью независимым, это ошибка, потому что информация о зависимостях неверна.

    Hatchling builds one Python project; there is no recursive make or recursive native-compilation hierarchy.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


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

    Проект ОБЯЗАН быть в состоянии повторить процесс генерации информации из исходных файлов и получить такой же результат с точностью до бита. Выберите «неприменимо» (N/A), если в проекте не используется сборка (например, языки сценариев, в которых исходный код используется непосредственно вместо компиляции), . [build_repeatable]
    Пользователи GCC и clang могут найти полезной опцию -frandom-seed; в некоторых случаях это может быть разрешено путем задания определенного порядка сортировки. Дополнительные предложения можно найти на сайте Reproducible builds.

    The public quality job runs two controlled wheel/source-archive builds and checks identical bytes. SOURCE_DATE_EPOCH and PYTHONHASHSEED are fixed; this establishes same-environment repeatability, not identity across operating systems or arbitrary dependency versions.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/build_catalog.py https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/verify_distribution.py https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687 https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/check_reproducible_build.py


  • Система установки


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

    Проект ОБЯЗАН предоставлять возможность легко установить и удалить ПО, создаваемое проектом, с использованием общепринятых способов. [installation_common]
    Примеры включают использование менеджера пакетов (на уровне системы или языка), «make install/uninstall» (с поддержкой DESTDIR), контейнер в стандартном формате или образ виртуальной машины в стандартном формате. Процесс установки и удаления (например, его упаковка) МОЖЕТ быть реализован третьей стороной, при условии что он построен на СПО.

    Wrangle uses standard Python wheel/source packaging and pip installation/uninstallation. Public CI checks built distributions and exercises the installed wheel.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/README.md https://pypi.org/project/wrangle/


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

    В системе установки для конечных пользователей НЕОБХОДИМО учитывать стандартные соглашения при выборе места, в которое собранные артефакты записываются при установке. Например, если она устанавливает файлы в системе POSIX, НЕОБХОДИМО учитывать переменную окружения DESTDIR. Если установочной системы или стандартного соглашения нет, выберите «неприменимо» (N/A). [installation_standard_variables]

    Installation uses pip and virtual environments, including conventional --target/--prefix placement, rather than a bespoke installer. Compiler-installation variables are inapplicable to project Python source.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/scripts/verify_distribution.py


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

    Проект ОБЯЗАН предоставить возможность потенциальным разработчикам быстро установить все результаты проекта и поддерживать среду, необходимую для внесения изменений, включая тесты и тестовое окружение. Проект ОБЯЗАН использовать для этого общепринятые соглашения. [installation_development_quick]
    Это МОЖЕТ быть реализовано при помощи сгенерированного контейнера или установочных сценариев. Внешние зависимости обычно устанавливаются путем вызова системных и/или языковых пакетов, как описано в критерии external_dependencies.

    CONTRIBUTING gives a complete virtual-environment setup and editable .[dev,excel] installation for development and tests, followed by the exact checks.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md


  • Компоненты, поддерживаемые извне


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

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

    pyproject.toml declares runtime, optional Excel and development/security dependencies in standard computer-processable Python metadata.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


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

    Проекты ОБЯЗАНЫ следить за своими внешними зависимостями или периодически проверять их (включая копии, сделанные для удобства) на предмет известных уязвимостей, а также исправлять уязвимости, которые могут быть использованы, или проверять невозможность их использования. [dependency_monitoring]
    Это можно сделать с помощью средств анализа происхождения/зависимостей, например Dependency-Check от OWASP, Nexus Auditor от Sonatype, Protex от Black Duck , Protecode от Synopsys и Bundler-аудит (для Ruby). Некоторые менеджеры пакетов включают в себя соответствующие механизмы. Допустимо оставлять уязвимость, если ее невозможно использовать, но такой анализ труден, и временами проще просто обновить или исправить эту часть кода.

    Dependabot tracks Python and GitHub Actions dependencies. A weekly/push/PR audit checks runtime, optional and CI requirements; the public audit passes. SECURITY assigns dependency-alert triage and remediation to the maintainer.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/dependabot.yml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/codeql.yml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/dependency-audit.yml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/SECURITY.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/actions/runs/36910861649/job/110532867934


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

    Проект ОБЯЗАН:
    1. позволять легко идентифицировать и обновлять повторно используемые компоненты, поддерживаемые извне; или
    2. использовать стандартные компоненты, предоставляемые системой или языком программирования.
    В этом случае, если уязвимость обнаружена в повторно используемом компоненте, будет легко обновить этот компонент. [updateable_reused_components]
    Типичным способом выполнить этот критерий является использование предоставляемых операционной системой и языком программирования систем управления пакетами. Многие свободные программы распространяются с «подсобными библиотеками», которые являются локальными копиями стандартных библиотек (возможно, форков библиотек). Само по себе это нормально. Однако, если программа *должна* использовать эти локальные копии/форки, то обновление «стандартных» библиотек через системное обновление безопасности оставит эти дополнительные копии по-прежнему уязвимыми. Это особенно актуально для облачных систем; если провайдер облака обновляет свои «стандартные» библиотеки, но программа их не собирается использовать, обновления фактически не помогут. См., например, "Chromium: Why it isn't in Fedora yet as a proper package" от Тома Каллавея.

    Dependencies are standard separately installed Python packages, identified in metadata and updateable independently. The project does not vendor opaque convenience copies.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml


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

    Проекту СЛЕДУЕТ избегать использования нерекомендуемых (deprecated) или устаревших (obsolete) функций и API в тех случаях, когда альтернативы на СПО доступны в используемом наборе технологий («стек технологий» проекта) и для подавляющего большинства пользователей, поддерживаемых проектом (т.е. так чтобы пользователи могли быстро воспользоваться этой альтернативой). [interfaces_current]

    The proposed implementation uses supported Python packaging and native Polars expressions/lazy plans. Its public migration guide explains deliberately unsupported legacy model-building APIs and the current preparation replacements.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/migration.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/ci-push.yml


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


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

    НЕОБХОДИМО применять автоматический набор тестов к каждому коммиту в общий репозиторий по крайней мере для одной ветки. Этот набор тестов ОБЯЗАН создавать отчет об успешном или неудачном тестировании. [automated_integration_testing]
    Это требование можно рассматривать как подмножество test_continuous_integration, но сосредоточенное только на тестировании, без требования непрерывной интеграции.

    Push and pull-request CI builds, tests and executes installed-package workflows. All seven OS/version/minimum-dependency jobs succeeded for the assessed public revision; job outcomes report success or failure.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/ci-push.yml https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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

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

    The six-month inventory identifies twenty behavior corrections and maps every one to a named meaningful regression test, including legacy scientific fixes and Windows newline/timezone/evidence-path/UTF-8 fixes. Twenty of twenty fixes have tests (100%); feature migrations and test-only adjustments are excluded. The assessed 991-test suite passes.
    Evidence: https://github.com/autonomio/wrangle/tree/b6f5354caf3e428ef23325a41e87ac9d1e767eff/tests https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CHANGELOG.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/wrangle/docs/security/regressions.yaml https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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

    Проект ОБЯЗАН иметь автоматические тестовые пакеты на СПО, которые обеспечивают покрытие не менее 80% инструкций кода, если есть хотя бы один инструмент на СПО, который может измерять этот критерий на выбранном языке. [test_statement_coverage80]
    Для измерения тестового покрытия существует множество средств на СПО, включая gcov/lcov, Blanket.js, Istanbul и JCov. Обратите внимание, что соответствие этому критерию не является гарантией того, что тестовый пакет является исчерпывающим; вместо этого, несоответствие этому критерию является сильным индикатором плохого набора тестов.

    The public final quality job at 8f255f379b068410d1a907edbed3b4dbfdbae083 passed 991 tests with 89.59% statement coverage (7252 statements,755 missed), exceeding the enforced 80% threshold. Final 8f and merged b6 have identical source trees. Only duplicated executable documentation is omitted. This is production statement coverage, not a branch result.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/ci-push.yml https://github.com/autonomio/wrangle/tree/b6f5354caf3e428ef23325a41e87ac9d1e767eff/tests https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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


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

    Проект ОБЯЗАН иметь формальную задокументированную политику о том, что при добавлении существенной новой функциональности НЕОБХОДИМО добавлять тесты для новой функциональности в набор автоматических тестов. [test_policy_mandated]

    CONTRIBUTING mandates meaningful automated tests for every major new capability and failure boundary, at least half of fixed bugs in a six-month window, and at least 80% production statement coverage.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md


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

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

    CONTRIBUTING and the PR checklist explicitly require automated tests for every major new capability and meaningful regression coverage for bug fixes.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/PULL_REQUEST_TEMPLATE.md https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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


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

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

    CONTRIBUTING mandates strict checks. CI enforces the configured Ruff rules and pytest warnings-as-errors, with precise recorded exceptions rather than exit-zero warning summaries; the assessed run succeeds.
    Evidence: https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/ci-push.yml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/codeql.yml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/.github/workflows/dependency-audit.yml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/pyproject.toml https://github.com/autonomio/wrangle/blob/b6f5354caf3e428ef23325a41e87ac9d1e767eff/CONTRIBUTING.md https://github.com/autonomio/wrangle/actions/runs/36910861626/job/110532867687


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

 Анализ 2/2 ●


Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/15135/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). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника Mikko Kotila и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: Mikko Kotila.
2026-10-01 15:20:31 UTC, последнее изменение сделано 2026-10-01 19:59:56 UTC. Последний раз условия для получения значка были выполнены 2026-10-01 19:54:19 UTC.