Cross-Border Stablecoin Register (CBSR)

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

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

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


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

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

        

 Основы 17/17 ●

  • Общая

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

    CBSR is an open, versioned, machine-readable register of stablecoin regulation across twelve jurisdictions, with a deterministic policy engine for evidence-bound cross-border research. Records distinguish claim type, legal status, provenance, source disposition, freshness and independent review. Policy evaluations are decision support only: execution_authorized remains false. The 20 August 2026 snapshot contains 152 records and 46 structural candidates, with 0 strictly citable current-law records; those counts are not verified current-law coverage. The software is Apache-2.0 and the dataset is CC-BY-4.0. Release assets and available archival identifiers are linked from the repository; an archive DOI is not claimed for every tag.

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

    Scope note for reviewers: this project produces two artifacts under two
    licenses. The software (src/cbsr_mcp/, tools/, scripts/, build*.py)
    is Apache-2.0 and is what these criteria are answered against. The dataset
    (*.yaml, dataset.json, analysis/, api/) is CC-BY-4.0; CC-BY-4.0 is not
    OSI-approved and is not claimed as a FLOSS software license. See LICENSING.md.

    The project uses cryptographic hashing (SHA-256) for artifact checksums and
    tamper-evident decision receipts. It performs no encryption, no key agreement,
    no key generation, and no password storage. Receipts detect mutation only;
    they are not signatures. Crypto criteria are answered on that basis.

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


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

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

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


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

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

    CONTRIBUTING.md states the requirements for an acceptable contribution: a
    record must be schema-valid, must cite a primary source with a pinpoint that
    the contributor has verified personally, and must pass the single canonical
    gate python -m tools.verify with no committed-output drift across two
    generation passes. Draft records carrying <VERIFY markers are accepted but are
    merged as drafts, not as verified coverage. Dependency changes additionally
    require a passing Linux Python 3.10-3.13 matrix and a Windows clean-room job.
    The sourcing rule is in METHODOLOGY.md.
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/main/CONTRIBUTING.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 для проекта меньше, чем их преимущества.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CONTRIBUTING.md


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

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

    GOVERNANCE.md documents the project's decision-making model, the accountable maintainer, contributor responsibilities, review and verification stages, merge and release decisions, amendment process, licensing boundary, and conflict-of-interest safeguards. It explicitly distinguishes committed workflow declarations from separately configured repository enforcement.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/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.

    The root CODE_OF_CONDUCT.md requires professional and evidence-based participation, prohibits harassment, discrimination, threats, doxxing and privacy violations, defines maintainer enforcement powers, and provides a confidential reporting route with conflict disclosure and protection against retaliation.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CODE_OF_CONDUCT.md


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

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

    GOVERNANCE.md identifies Yunjie Fan as the accountable maintainer and defines responsibilities for data integrity, verification standards, releases and charter enforcement. It also defines contributor and review responsibilities. CODEOWNERS maps repository areas to the responsible maintainer account; this is a responsibility map, not evidence of a second maintainer or completed independent review.

    Evidence:


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

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

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/GOVERNANCE.md#7-amendment-and-continuity


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

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

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/security/OPENSSF_GOLD.md


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


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

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

    Section 25 of the architecture white paper documents a three-year roadmap: year one addresses official-source, freshness, review and engineering-governance gaps; year two considers reviewed domain packs and authenticated/signed receipts in controlled pilots; year three evaluates adoption, interoperability, redress and longitudinal outcomes. These phases are conditional on evidence and governance approval. The Charter documents continuing non-goals and scope boundaries, including no unsupported claims or predictions and depth before breadth.

    Evidence:


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

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

    Paste-ready justification:

    ADR 0001 documents the high-level architecture and responsibilities of the typed core, offline data loader, evidence and event layers, stablecoin domain pack, canonical serialization, public API projections, tool registry and server composition root. It describes interface versioning, compatibility boundaries and the separation between generic policy models and domain-specific rules.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/adr/0001-modular-mcp-policy-boundaries.md


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

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

    SECURITY.md and the threat model state the software's security requirements and limitations: offline decision support, fail-closed evidence handling, no transaction execution or key custody, and execution_authorized always false. They distinguish mutation-detecting hashes from signatures and document supply-chain checks, release hard stops and residual human-review limitations.

    Evidence:


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

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

    The README provides isolated-environment setup and the canonical verification command. CONNECT_MCP.md provides prerequisites, source installation, copy-paste client configurations and initial example queries, and also describes a zero-setup static JSON API. Platform and hash-lock limitations are explicitly documented.

    Evidence:


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

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

    The project enforces many generated documentation and identifier consistency checks, but known inconsistencies remain. ROADMAP.md still labels v0.10.0 as current, and the compatibility matrix still describes hosted Linux and Windows evidence as unverified despite newer published successful runs. These documents must be corrected or clearly labelled as historical before this criterion is marked Met.

    Evidence:


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

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

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/README.md


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


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

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

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/index.html


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

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

    The software consistently supports UTF-8 input/output and non-UTF-8 console environments, but its user-facing Register interface and many messages remain hard-coded in English without a localization resource layer. Unicode portability and a separate bilingual landing page do not by themselves establish internationalization of the produced software.

    Evidence:


  • Другое


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

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

    CBSR's project-operated website and public data/download interfaces are static and do not implement external-user accounts or store user passwords. Repository and issue-tracker authentication is provided by GitHub, which the official criterion's detailed guidance identifies as meeting this requirement. CBSR does not handle or store GitHub account credentials. This answer covers the project sites and does not assert that CBSR implements its own password-storage system.

    Evidence:


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

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

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


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

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

    The project uses the GitHub issue tracker for individual issues, with issue
    templates configured in .github/ISSUE_TEMPLATE/.
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/issues


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


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

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

    The available public evidence does not establish the complete set of vulnerability reports resolved during the previous 12 months or whether every reporter received the requested credit or anonymity. The maintainer must check the private reporting and remediation records before selecting Met or N/A. An empty public advisory list or a clean dependency audit does not establish that no reports were resolved.

    Evidence:


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

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

    SECURITY.md documents confidential reporting, required report information, a protected-channel fallback, acknowledgement within three business days, initial triage within seven business days, coordinated disclosure with a default 90-day target, and completion checks for regression tests, dependency/security gates, checksums and advisories. These are documented response targets, not a claim that every historical report met them.

    Evidence: https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/SECURITY.md#response-expectations-and-coordinated-disclosure


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

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


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

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

    CONTRIBUTING.md requires Python changes to follow PEP 8, preserve typed interfaces, use explicit text encodings, and avoid broad warning suppression. It also specifies schema and determinism requirements for JSON/YAML and link requirements for Markdown.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CONTRIBUTING.md#style-and-warnings


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

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

    The project documents PEP 8 but does not yet automatically enforce that coding style across its Python source with a configured style checker or formatter in the canonical gate. Schema, identifier, and security checks do not substitute for automatic Python style enforcement.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/verify.py


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


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

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

    CBSR builds a pure-Python wheel and generated data/documentation; it does not compile project-owned native binaries or invoke native compilers/linkers. CC, CFLAGS, CXX, CXXFLAGS, and LDFLAGS therefore do not apply to this project's build.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pyproject.toml


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

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

    The wheel retains the project's Python source files. The build/install process does not strip source, traceback information, assertions, or debugging symbols, and does not use an install-time stripping step.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pyproject.toml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/Makefile


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

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

    A single root build definition packages the Python project with Hatchling. The Makefile does not recursively invoke builds in subdirectories. Generated outputs are produced by an explicitly ordered canonical pipeline, rather than independent recursive subdirectory builds with cross-dependencies.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/Makefile

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/verify.py


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

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

    The canonical verifier repeats generation and compares output hashes. The package smoke check builds the wheel twice from the same source in the same environment with a fixed SOURCE_DATE_EPOCH and rejects unequal SHA-256 hashes. This demonstrates repeatability within that environment; it does not claim independent or cross-platform bit-for-bit reproduction.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/verify.py

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/package_smoke.py


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


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

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

    CBSR uses standard Python packaging and pip installation into an isolated virtual environment. The installed cbsr-mcp distribution can be removed with the standard command python -m pip uninstall cbsr-mcp. A clean-environment installation is exercised by the canonical package smoke check.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/MCP_SERVER.md

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/package_smoke.py


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

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

    Installation uses the standard Python wheel/pip mechanism without a custom installer that hard-codes a system destination. Users select the virtual environment and may use pip's standard destination options, including --target, --prefix, and --root. There is no separate project-specific POSIX installer requiring DESTDIR.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pyproject.toml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/MCP_SERVER.md


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

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

    The documented developer setup uses a Python virtual environment and the committed hash-locked development requirements. make setup installs that graph, builds the local wheel, and installs it with a verified local-wheel hash. python -m pytest -q runs the quick tests; python -m tools.verify runs the complete verification pipeline. A documented PowerShell setup is provided for Windows.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CONTRIBUTING.md

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/Makefile

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/LOCAL_DEPLOY_WINDOWS.md


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


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

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

    Runtime and development dependencies are declared in pyproject.toml and committed machine-readable constraints files. Hash-locked requirements cover runtime, development, measurement, and bootstrap dependencies. Release evidence also includes a CycloneDX SBOM and license inventory.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pyproject.toml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/tree/1131c092f2fb681db5bff8544284faf475abb2f1/constraints


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

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

    Dependabot checks Python and GitHub Actions dependencies monthly. Pull requests run dependency review, and the canonical verifier audits the current locked development/measurement graph and the clean-installed runtime with pip-audit. Release preparation requires successful live audit evidence bound to the current locks; a missing or failed audit is not treated as a clean result.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/.github/dependabot.yml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/.github/workflows/dependency-review.yml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/audit_locked_dependencies.py

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/prepare_release.py


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

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

    Externally maintained components are installed through standard Python packaging rather than embedded as opaque copies. The project documents how to update reviewed direct pins, resolve the transitive graph, regenerate wheel hashes, and run the supported-platform verifier. GitHub Actions references are also explicitly versioned and monitored by Dependabot.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/constraints/README.md

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/refresh_constraints.py

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/.github/dependabot.yml


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

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

    The package declares supported Python 3.10–3.13 and reviewed current dependency ranges, and its installed-wheel smoke test treats warnings as errors. However, these checks do not establish a repository-wide review of deprecated or obsolete APIs. This item remains unknown pending that review, particularly for tools and generator paths outside the smoke scenario.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pyproject.toml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/package_smoke.py


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


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

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

    GitHub Actions runs the canonical verifier on every push to main/master and on pull requests. It tests Linux Python 3.10–3.13 and a Windows Python 3.12 clean-room setup, with an aggregate job that requires all platform jobs to succeed. Logs and machine-readable success/failure evidence are retained as workflow artifacts.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/.github/workflows/build.yml

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/actions/workflows/build.yml


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

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

    CONTRIBUTING.md requires regression tests for bug and security fixes when safe automated reproduction is possible, with a documented alternative otherwise. Regression tests exist, but a complete six-month inventory of fixed bugs mapped to regression tests has not yet been established. Therefore the required percentage cannot currently be substantiated.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CONTRIBUTING.md#tests-and-regressions

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/tree/1131c092f2fb681db5bff8544284faf475abb2f1/tests


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

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

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/actions/runs/36005712510/job/107653206591

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/.coveragerc


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


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

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

    The written acceptance policy requires major new functionality to add automated tests covering success, rejection, and relevant boundary paths. Bug and security fixes must add regression tests when safely reproducible, or explain a reviewer-verifiable alternative.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/CONTRIBUTING.md#tests-and-regressions


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

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

    the policy is documented in CONTRIBUTING.md, which is the instructions file for change proposals.


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


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

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

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/package_smoke.py

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pytest.ini

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/verify.py


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

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


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

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

    The offline policy core applies fail-closed decisions, typed input boundaries, separation of policy evaluation from transaction execution, and least-privilege release stages. However, the distributed Worker deployment example is described as an authenticated proxy while its code forwards every POST with a server-held API key without verifying the caller. CORS response headers are not authorization. This optional deployment boundary must be corrected, with authorization and rejection tests, before claiming secure-design implementation for the complete distributed project.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/security/THREAT_MODEL.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/DEPLOYMENT.md


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

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

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

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

    SHA-1 is not used anywhere; SHA-256 is the sole hash. No SSH CBC mode or comparable weak construction is present.


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

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

    The current canonical receipt and artifact formats use a fixed SHA-256 implementation. They do not expose a tested, versioned choice of alternative digest algorithms or a documented migration procedure. TLS library negotiation does not establish agility for these application-level digests. A future algorithm transition must preserve verification of historical receipts and artifacts; this has not yet been implemented.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/src/cbsr_mcp/serialization/canonical.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/src/cbsr_mcp/receipts.py


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

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

    The offline policy core does not handle passwords or private keys. The optional Worker example does handle an upstream API credential and documents an encrypted provider secret, kept out of frontend code and ordinary configuration and replaceable without recompiling the application. The assessment has not established separate secret-file support, or the complete credential-storage and rotation behavior of every supported deployment. Therefore the project-wide answer is unknown, not N/A. Document and verify the supported secret-store/file boundary and rotation procedure before selecting Met.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/DEPLOYMENT.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/hosted-mcp/README.md


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

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

    The default MCP command uses local stdio, and dependency metadata tooling uses HTTPS. The optional hosted MCP service uses cleartext HTTP internally; the documented container command publishes it only on loopback and requires an authenticated TLS-terminating reverse proxy for remote access. No evidence here establishes the TLS configuration of an actual remote deployment. The standalone hosted launcher also defaults to an all-interface HTTP listener. Verify or constrain each supported remote deployment path before selecting Met. The container's internal bind address alone is not evidence of public exposure.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/src/cbsr_mcp/server.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/hosted-mcp/README.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/hosted-mcp/serve_http.py


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

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

    The project's HTTPS dependency tooling uses Python's standard TLS implementation on supported Python 3.10–3.13, which supports TLS 1.2 and later; it does not replace the SSL context with a legacy protocol implementation. A local check of the supported Python 3.12 environment reported TLSv1_2 as the default context's minimum version. This is a software capability statement, not an attestation about an operator's external reverse proxy.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/pyproject.toml
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/hash_constraints.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 Python HTTPS metadata clients use urllib.request.urlopen with its standard verifying TLS context, without disabling certificate or hostname checks. The optional Worker example uses the platform HTTPS fetch implementation rather than a custom certificate-verification bypass. The examined code does not install an unverified SSL context. This answer concerns the shipped TLS-client defaults; it does not certify a user-modified deployment.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/hash_constraints.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/refresh_constraints.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/DEPLOYMENT.md


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

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

    HTTPS requests are delegated to standard TLS clients, which establish and verify the TLS connection before sending HTTP request headers. The dependency metadata requests carry no private authentication material. The optional Worker sends its server-held API key only to the fixed HTTPS upstream using the platform fetch API; no code sends that header before the TLS handshake or disables verification. The separate missing caller-authorization control in that example is disclosed under implement_secure_design, not treated as a TLS verification failure.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tools/hash_constraints.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/DEPLOYMENT.md


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


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

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

    [osps_do_03_02]


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

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

    https://api.github.com/repos/yunjiefanresearch-hub/cross-border-stablecoin-register/git/ref/tags/v0.11.0.post1


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


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

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

    The policy boundary validates finite numeric values, boolean types, collection shapes, schema versions, identifiers and policy constraints, and returns a non-authorizing failure for invalid or incomplete evidence. Regression and negative tests exercise these boundaries. However, a complete inventory mapping all untrusted input paths to allowlist validation has not been established, including the optional hosted service and the distributed proxy example, which forwards request bodies without project-level validation. These positive core tests are not sufficient to assert complete project-wide coverage of this requirement.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/src/cbsr_mcp/core/models.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/src/cbsr_mcp/policy.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/tests/test_security_boundaries.py
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/DEPLOYMENT.md


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

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

    The hosted-container verification runs the actual packaged service with a read-only root filesystem, all Linux capabilities dropped and a loopback-only published port; writable storage is limited to the required runtime paths. The image also runs as an unprivileged user. The read-only filesystem and capability restrictions are concrete hardening mechanisms beyond the user privilege choice alone, and the successful hosted smoke workflow exercises them. This answer does not claim that every downstream deployment enables these options or that the static website implements all possible security headers.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/.github/workflows/hosted-mcp.yml
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/hosted-mcp/README.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/actions/runs/36005712662


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

    Проект ОБЯЗАН предоставить обоснование того, что требования безопасности соблюдаются проектом. В обоснование НЕОБХОДИМО включить: описание модели угроз, четкое указание границ доверия, доказательство того, что использовались принципы безопасного дизайна, и доказательство того, что слабости в безопасности реализации нейтрализованы. (Требуется 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.

    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/SECURITY.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/security/THREAT_MODEL.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/adr/0001-modular-mcp-policy-boundaries.md
    https://github.com/yunjiefanresearch-hub/cross-border-stablecoin-register/blob/1131c092f2fb681db5bff8544284faf475abb2f1/docs/DEPLOYMENT.md


 Анализ 2/2 ●

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


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

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

    CodeQL's default Python query suite includes rules for common vulnerability classes in the language and environment, including injection, path traversal and unsafe deserialization.


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


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

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

    N/A: the project produces no software written in a memory-unsafe language. The implementation is pure Python.



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

Владелец анкеты на значок проекта: yunjiefanresearch-hub.
2026-08-20 07:54:43 UTC, последнее изменение сделано 2026-09-28 05:52:56 UTC. Последний раз условия для получения значка были выполнены 2026-08-20 10:57:39 UTC.