Chances

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

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

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


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

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

        

 Основы 16/17 ●

  • Общая

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

    Scientific randomness from declared protocols, with verified arrays, explicit streams, execution receipts and conditional exact replay.

    Используйте формат выражения лицензии 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 is earned. Silver proposals are grounded in merged source and execution evidence at https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/.bestpractices.json . PR #48 prepares authenticated source/distribution publication. Silver remains unearned: dependency findings, completed signed publication, access continuity, vulnerability-report credit, and the historical regression-test denominator remain unresolved. https://github.com/autonomio/chances/pull/48

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


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

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

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


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

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

    CONTRIBUTING links the constitution, locked development setup, meaningful review brief, and required quality checks. The constitution defines PR acceptance, coding conventions, and the ten merge gates. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CONTRIBUTING.md https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/CLAUDE.md


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


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

    Проекту СЛЕДУЕТ иметь юридический механизм, через который все авторы содержательных взносов в ПО проекта подтверждают, что они имеют законное право на внесение этих взносов. Самый распространенный и легко реализуемый подход для этого заключается в использовании 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 для проекта меньше, чем их преимущества.

    A DCO, CLA, or equivalent contributor authorization mechanism is not currently required or documented. The project retains its MIT license and reviewed contribution process, but those are not represented as developer legal attestations. This SHOULD criterion has been considered; retrospective legal assertions will not be inferred from existing commits, and introducing a contribution-signoff obligation requires an explicit governance decision. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CONTRIBUTING.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/LICENSE https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md


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

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

    GOVERNANCE identifies maintainers as the decision authority for priority, release timing, review requirements, and project scope. MAINTAINERS assigns responsibilities and names the sole approving authority; CLAUDE defines the enforced contribution and review process. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/GOVERNANCE.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.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.

    The standard root CODE_OF_CONDUCT.md states expected and prohibited behavior, moderation consequences, and the route for reporting conduct issues to maintainers. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CODE_OF_CONDUCT.md


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

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

    MAINTAINERS names Mikko Kotila as maintainer and assigns release approval, security triage, issue prioritization, and merge decisions. It separately identifies bit-mis as required reviewing authority, with the review and environment activation process linked. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/CLAUDE.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SETUP.md


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

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

    Unresolved maintainer fact: if either the maintainer or bit-mis becomes unable or unwilling to support the project, can another authorized person create and close issues, accept changes, and release software within one week, including repository/organization administration, release approval, PyPI access, and necessary legal authority? Who owns this continuity role, and where is the recovery procedure documented? Existing admin access alone does not prove publication capability or succession authority. No continuity attestation is inferred. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SETUP.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/.github/CODEOWNERS


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

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

    Only one current maintainer is publicly documented. Review and organization access do not by themselves establish that a second person has the scientific, security, and release knowledge needed to sustain the project. This SHOULD criterion has been considered: the small project currently retains centralized maintainership and its designated review authority, rather than claiming undocumented staffing or changing reviewer policy to satisfy a badge. Access continuity is assessed separately. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/MAINTAINERS.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/GOVERNANCE.md


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


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

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

    The roadmap merged in PR #46 covers 2026-10-02 through 2027-10-31 and documents planned capabilities, maintenance priorities, and excluded scope for at least the next year. This source is on protected master. https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/docs/Roadmap.md https://github.com/autonomio/chances/pull/46


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

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

    The package boundary documents major modules and their responsibilities, and the documentation hub explains the execution sequence from protocol validation through local generation, output checks, publication, verification, and replay. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/README.md


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

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

    The specification/receipt reference documents untrusted literal and array inputs, no pickle/callback execution, resource and output constraints, unsigned receipt integrity, and the exact-replay compatibility boundary. SECURITY and the assurance case distinguish these guarantees from authenticity, scientific suitability, and external compromise. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Specifications-and-Receipts.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Security-Assurance-Case.md


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

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

    The README provides source installation, a bounded normal draw, observable array shape, and a complete save/verify/replay workflow. It explicitly distinguishes the repository 2.0 API from historical 0.1 PyPI releases. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md


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

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

    Canonical prose is maintained against the current API and version; generated installed mirrors and catalogs are checked for drift. Built-wheel documentation examples, portable links/fragments, version metadata, site build, and browser checks run in CI. This is evidence of an ongoing consistency effort, not a claim that documentation can contain no future defect. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Documentation-System.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/tests/package/test_documentation.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/scripts/build_catalog.py https://github.com/autonomio/chances/actions/runs/36921324501


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

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

    The repository README hyperlinks the earned Best Practices entry and live Scorecard evidence. The Passing achievement was added in PR 36 on the same day it was earned, within 48 hours; no Silver award is advertised. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md https://github.com/autonomio/chances/pull/36 https://www.bestpractices.dev/en/projects/15137


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


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

    Проекту (как на сайтах проекта, так и в результатах работы проекта) СЛЕДУЕТ придерживаться передовой практики общедоступности, чтобы люди с ограниченными возможностями могли участвовать в проекте и использовать результаты проекта, где это имеет смысл. [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 library and JSON CLI expose text-based interfaces. Documentation checks exercise keyboard navigation, skip links, light/dark themes, desktop/mobile layouts, and Axe WCAG 2 A/AA checks across representative page roles; images have text alternatives. The recorded CI passed these checks. Automated accessibility checks are not claimed to establish universal accessibility or a completed human screen-reader audit. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs-site/tests/docs.spec.js https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/README.md https://github.com/autonomio/chances/actions/runs/36921324501


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

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

    Human-facing error messages and maintained prose are English; the package has no message-localization framework. This SHOULD criterion has been considered: scientific protocol identifiers, structured error codes, and receipt formats currently prioritize one stable interchange contract, and maintenance remains focused on the documented English audience. Human-facing strings could be localized separately in future without changing those identifiers. Because the CLI does generate user-facing messages, N/A is not claimed. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_errors.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Command-Line.md


  • Другое


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

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

    The repository and project communication use GitHub, which the official Silver criterion details explicitly accept. Chances operates no custom user-password database or authentication website; the documentation output is static. Package distribution uses PyPI rather than a project-operated login system. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs-site/product-docs.json https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances https://pypi.org/project/chances/ https://www.bestpractices.dev/en/criteria/1?details=true


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

  • Предыдущие версии


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

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

    The maintained 2.0 series supplies a migration guide from 0.1 with changed interfaces, explicit scientific choices, examples, compatibility exports, and unavailable remote-provider boundaries. Historical outputs are not falsely claimed equivalent, and supported versions are stated in SECURITY. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Guides/Migration.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md


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

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


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

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

    Users submit defects through the public GitHub issue tracker; the README requests a minimal protocol, package versions, and structured error. Public issue templates support bug and enhancement reports. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/README.md https://github.com/autonomio/chances/issues/new/choose


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


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

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

    Unresolved maintainer fact: between 2025-10-02 and 2026-10-02, were any vulnerability reports resolved, including private reports? If none, N/A is justified; otherwise provide the public fix/release/advisory URLs crediting each reporter who did not request anonymity. SECURITY promises credit, but a future policy and an empty public advisory list do not establish the handling of private historical reports. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md https://github.com/autonomio/chances/security/advisories


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

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

    SECURITY documents private reporting, acknowledgement target, reproduction, impact/version triage, reporter coordination, prioritized critical fixes, disclosure, public fix notes, and reporter credit. These documented response steps are separate from historical response-time attestations. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/SECURITY.md


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

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

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


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

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

    The product implements fail-closed literal/schema validation, bounded resources, no pickle or input-code execution, complete verification of bundle protocol/hash/shape/stream evidence, isolated RNG state, and non-overwriting publication. Repository automation separates untrusted PR execution from approved credentialed publication and grants mutation rights only to the jobs needing them. The accompanying assurance-case proposal documents the principles and remaining assumptions after merge. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_api.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_random.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_publication.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/.github/workflows/pr_publish_pypi.yml https://github.com/autonomio/chances/blob/master/docs/Developer/Security-Assurance-Case.md


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

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

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

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

    Receipt and stream derivation use published SHA-256 through Python hashlib, not a local cryptographic implementation. SHA-256 provides a 256-bit hash with no selectable weaker receipt algorithm. Legacy uniform_crypto uses Python SystemRandom, backed by operating-system randomness. Seeded scientific generators are explicitly outside the cryptographic security boundary. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/chances/_api.py https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/chances/_random.py https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/chances/legacy.py https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/docs/Reference/Specifications-and-Receipts.md


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

    Проекту СЛЕДУЕТ поддерживать несколько криптографических алгоритмов, чтобы пользователи могли быстро переключиться, если один из них поврежден. Общие симметричные ключевые алгоритмы включают AES, Twofish и Serpent. Общие алгоритмы контрольных сумм (хешей) включают SHA-2 (SHA-224, SHA-256, SHA-384 и SHA-512) и SHA-3. [crypto_algorithm_agility]

    The receipt and seed-stream formats currently use one fixed published hash, SHA-256, without algorithm negotiation. This SHOULD criterion has been considered: changing the integrity algorithm requires an explicitly versioned protocol and migration so existing scientific receipts do not silently change identity; the current package therefore prioritizes a stable checked format rather than claiming selectable cryptographic algorithms. Seeded scientific RNG engine selection is not cryptographic agility. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_api.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_random.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Specifications-and-Receipts.md


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

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

    The scientific library and CLI never process authentication credentials or private cryptographic keys. They operate on local protocols, arrays, and unsigned receipts; repository publication secrets belong to separately protected automation rather than the delivered scientific API. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Reference/Specifications-and-Receipts.md


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

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

    The delivered scientific library and CLI perform local computations and artifact operations without network transport. Legacy quantum/ambient provider calls fail explicitly without contacting providers; local SystemRandom is an OS service rather than a network protocol. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/legacy.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Guides/Migration.md


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

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

    The delivered scientific library and CLI use no TLS or other network communications. Project-site HTTPS and release/development tooling are assessed separately from product transport. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/legacy.py


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

    В ПО, создаваемом проектом, НЕОБХОДИМО выполнять проверку сертификата TLS по умолчанию при использовании TLS, в том числе в подресурсах. Если программное обеспечение не использует TLS, выберите «неприменимо» (N/A). [crypto_certificate_verification]
    Обратите внимание, что неправильная проверка сертификата TLS является распространенной ошибкой. Для дальнейших сведений см. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" Мартина Георгиева и др. и "Do you trust this application?" Майкла Катанзаро.

    The delivered scientific library and CLI have no TLS client, server, or subresource transport and therefore perform no product TLS certificate verification. External GitHub/PyPI delivery is outside this product-transport criterion. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/legacy.py


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

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

    The delivered scientific library and CLI send no HTTP requests, private headers, cookies, or authentication information. There is no product TLS exchange preceding such headers. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/__main__.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/legacy.py


  • Безопасный выпуск


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

    Проект ОБЯЗАН криптографически подписывать выпуски результатов проекта, предназначенные для широкого использования, и ОБЯЗАН иметь задокументированный процесс, объясняющий пользователям, как они могут получить общедоступные ключи подписи и проверить подпись(и) выпусков. НЕДОПУСТИМО размещать закрытый ключ для этих подписей на сайте(сайтах), используемом для прямого распространения ПО для общественности. Выберите «неприменимо» (N/A), если выпуски не предназначены для широкого использования. [signed_releases]
    Результаты проекта включают как исходный код, так и любые сгенерированные результаты, если это применимо (например, исполняемые файлы, пакеты и контейнеры). Сгенерированные результаты МОГУТ быть подписаны отдельно от исходного кода. Подписывание МОЖЕТ быть реализовано как подписанные теги git (с использованием криптографических цифровых подписей). Проекты МОГУТ предоставлять генерируемые результаты отдельно от таких инструментов, как git, но в этих случаях отдельные результаты ОБЯЗАНЫ быть отдельно подписаны.

    No completed approved 2.0 release or PyPI publication exists; the latest published version remains 0.1.9. PR #48 prepares full tracked-source signing, public Sigstore bundles, immutable wheel/sdist assets, exact approved-source verification, and consumer trust instructions. Configuration and tests do not establish a published signed release; this MUST criterion remains Unmet until reviewed merge, protected publication, and consumer verification succeed. Annotated Git tags and scientific receipts remain unsigned. https://github.com/autonomio/chances/pull/48 https://github.com/autonomio/chances/releases/tag/v0.1.9 https://github.com/autonomio/chances/actions/workflows/pr_publish_pypi.yml


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

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

    No current important release tag with a published cryptographic signing and verification record was established. The configured create-release script creates an annotated tag with git tag -a but does not request cryptographic signing. This SUGGESTED criterion is considered and not claimed Met; a signed package attestation does not by itself sign a Git tag. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/scripts/create_release.py https://github.com/autonomio/chances/tags


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


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

    В результатах проекта НЕОБХОДИМО проверять любой ввод из потенциально ненадежных источников, чтобы убедиться, что они действительны (*белый список*), и отклонять недействительный ввод, если вообще есть какие-либо ограничения на данные. [input_validation]
    Обратите внимание, что сравнения ввода со списком «плохих форматов» (также известным как *черный список*) обычно недостаточно, потому что злоумышленники часто могут обойти черный список. В частности, числа преобразуются во внутренние форматы, а затем проверяются, находятся ли они между их минимальным и максимальным (включительно), а текстовые строки проверяются, чтобы убедиться, что они являются допустимыми текстовыми шаблонами (например, действительный UTF-8, длина, синтаксис и т. д.). От некоторых данных может требоваться, чтобы они были «хоть чем-нибудь» (например, загрузчик файлов), но такое обычно случается редко.

    The product allowlists operations, parameter keys, native literal/scalar/array types, shapes, domains, encodings, finite values, and resource bounds. Source and bundle loading forbids pickle and callbacks; receipt verification rejects schema, content, protocol, stream-state, and output mismatches. Tests exercise invalid inputs and publication boundaries. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_api.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_random.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_operations.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_distributions.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/tests/package/test_input_boundaries.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/tests/package/test_receipt_validation.py


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

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

    This SHOULD criterion has been considered without claiming least privilege as hardening. The owned scientific product is a Python library/CLI, not a native compiled program or network server, and it supplies no compiler-hardening configuration or proven deployed security-header surface. Memory-safe Python, safe loading, resource validation, and controlled native calls reduce risk, but a separate hardening claim for external NumPy/SciPy binaries or a configured-yet-unproven documentation deployment is not established. Additional platform controls are left to the caller environment and deployment adapter. https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/README.md https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/chances/_publication.py https://github.com/autonomio/chances/blob/3216e3e54cd51e1c32679154a1235033dc89e2e3/docs/Developer/Documentation-System.md


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

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется URL) [assurance_case]
    Обоснованием является «документальное подтверждение, которое дает убедительное и корректное доказательство того, что указанный набор критических заявлений относительно свойств системы адекватно оправдан для данного приложения в данной среде» (перевод выдержки из "Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Границы доверия - это границы, на которых меняется уровень доверия к данным или выполнению кода, например границы сервера в типичном веб-приложении. В обосновании обычно перечисляются принципы безопасного проектирования (такие как Saltzer and Schroeer) и общие слабости безопасности в реализации (такие как OWASP Top 10 или CWE/SANS Top 25), и показывается, как противодействовать каждой из них. Полезным примером может служить обоснование для BadgeApp. Этот критерий связан с documentation_security, documentation_architecture и implement_secure_design.

    The expanded assurance case merged in PR #46 documents threat actors, assets, trust boundaries, secure-design principles, common implementation weaknesses, implementation and test evidence, and residual risks and external assumptions. https://github.com/autonomio/chances/blob/066fe51e4762d2be1b282fff115ec1784e6a3cfd/docs/Developer/Security-Assurance-Case.md https://github.com/autonomio/chances/pull/46


 Анализ 2/2 ●

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


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

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

    CodeQL Python analysis runs on master pushes, pull requests, and a weekly schedule. The proposed Chances 2.0 major release has passed this analysis before publication; the PR required the CodeQL status. Public ruleset and typing analysis provide additional static checks. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/.github/workflows/pr_checks_codeql.yml https://github.com/autonomio/chances/actions/runs/36887139299


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


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

    Если ПО, создаваемое проектом, включает ПО, написанное с использованием небезопасного языка (например, C или C++), тогда проект ОБЯЗАН регулярно использовать хотя бы один динамический инструмент (например, фаззер или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера. Выберите «неприменимо» (N/A), если проект не создает ПО, написанное на небезопасном языке. [dynamic_analysis_unsafe]
    Примерами механизмов обнаружения проблем безопасности памяти являются Address Sanitizer (ASAN) (доступен в GCC и LLVM), Memory Sanitizer и valgrind. Другие потенциально используемые инструменты включают Thread Sanitizer и Undefined Behavior Sanitizer. Достаточно широкое использование утверждений (assertions) тоже может быть приемлемо.

    The project-authored product code is Python, with JavaScript used by documentation tooling; the project does not produce C or C++ source. NumPy/SciPy and platform native publication APIs are external dependencies, not project-authored memory-unsafe-language source. https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/pyproject.toml https://github.com/autonomio/chances/blob/ee6ab1725bcc60bff78ad45b561dbb3d0b9632da/chances/_publication.py



Вы можете использовать инструменты и системы ИИ для предложения изменений через простой URL, например https://www.bestpractices.dev/ru/projects/15137/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:58:41 UTC, последнее изменение сделано 2026-10-03 08:29:52 UTC. Последний раз условия для получения значка были выполнены 2026-10-01 16:42:28 UTC.