btclib-wallet

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

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

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


Это критерии Базового Уровня 3. Это критерии версии v2026.08.28.

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

        

 Основы

  • Общая

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

    Bitcoin wallet functionality built on btclib

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

 Элементы управления 20/21 ●

  • Элементы управления


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

    Когда задаче назначаются разрешения в конвейере CI/CD, исходный код или конфигурация ДОЛЖНЫ назначать только минимальные привилегии, необходимые для соответствующей деятельности. [OSPS-AC-04.02]
    Настройте конвейеры CI/CD проекта так, чтобы по умолчанию назначать пользователям и службам наименьшие доступные разрешения, повышая разрешения только когда это необходимо для конкретных задач. В некоторых системах контроля версий это может быть возможно на уровне организации или репозитория. Если нет, установите разрешения на верхнем уровне конвейера.

    Every workflow sets permissions: contents: read at the top, and a job adds a write scope only where it uses it. zizmor's excessive-permissions audit runs in the required lint check. https://github.com/btclib-org/.github/blob/main/README.md#what-every-workflow-does


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

    Конвейеры CI/CD, принимающие входные данные от доверенных коллабораторов, ДОЛЖНЫ санировать и проверять эти входные данные перед их использованием в конвейере. [OSPS-BR-01.04]
    Конвейеры CI/CD должны санировать (заключать в кавычки, экранировать или завершаться при ожидаемых значениях) все входные данные коллабораторов при явном выполнении рабочих процессов. Хотя коллабораторы в целом являются доверенными, ручные входные данные для рабочего процесса не могут быть проверены и могут быть использованы в злоумышленных целях при захвате учётной записи или угрозе изнутри.

    A workflow_dispatch input is either mutation.yml's profile, a choice from a fixed list, or verified-signatures.yml's before and after, which the called workflow reads through env: and refuses unless they are commit shas. A release tag's name is checked against the package version before anything is built. https://github.com/btclib-org/btclib-wallet/blob/main/.github/workflows/mutation.yml


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

    Когда создается официальный релиз, все активы в этом релизе ДОЛЖНЫ быть четко связаны с идентификатором релиза или другим уникальным идентификатором для актива. [OSPS-BR-02.02]
    Назначьте уникальный идентификатор версии каждому программному активу, произведенному проектом, следуя единообразному соглашению об именовании или схеме нумерации. Примеры включают SemVer, CalVer или идентификатор git-коммита.

    Every release asset carries the version in its file name, and the attestation binds each asset to its digest. https://github.com/btclib-org/btclib-wallet/releases/latest


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

    НЕОБХОДИМО, чтобы проект определил политику управления секретами и учетными данными, используемыми проектом. Политика должна включать руководства по хранению, доступу и ротации секретов и учетных данных. [OSPS-BR-07.02]
    Задокументируйте, как секреты и учетные данные управляются и используются в рамках проекта. Это должно включать подробную информацию о том, как хранятся секреты (например, с использованием инструмента управления секретами), как контролируется доступ, и как секреты ротируются или обновляются. Убедитесь, что конфиденциальная информация не встроена в исходный код и не хранится в системах контроля версий.

    A secret is an environment secret that only the owners reach. A secret kept in any other store is recorded in the REPOSITORY.md of the repository that uses it, and btclib-org/.github's tests/secrets_test.py refuses an unrecorded one. A secret is rotated when an owner changes or an exposure is suspected. The secrets kept outside an environment are rotated before they are a year old, and the list is reviewed yearly. https://github.com/btclib-org/.github/blob/main/README.md#tokens-publishing-scanning


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

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке целостности и подлинности активов релиза. [OSPS-DO-03.01]
    Инструкции в проекте должны содержать информацию об используемой технологии, командах для выполнения и ожидаемом выводе. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    SECURITY.md gives the gh attestation verify command for the release files. RELEASING.md adds the offline --bundle form and a rebuild from the tag that passes only if its digests match the attested ones. https://github.com/btclib-org/btclib-wallet/blob/main/SECURITY.md


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

    Когда проект выпустил релиз, документация проекта ДОЛЖНА содержать инструкции по проверке ожидаемой личности человека или процесса, создающего программный релиз. [OSPS-DO-03.02]
    Ожидаемая личность может быть в форме идентификаторов ключей, используемых для подписи, эмитента и личности из сертификата sigstore или других подобных форм. По возможности избегайте хранения этой документации в том же месте, что и конвейер сборки и выпуска, чтобы избежать компрометации как программного обеспечения, так и документации для проверки целостности программного обеспечения в случае единичного нарушения безопасности.

    SECURITY.md gives the gh attestation verify command, with --owner btclib-org, --signer-workflow naming the organization's reusable-build.yml and --source-ref the release tag, and a compare of the certificate's sourceRepositoryIdentifier with this repository's id, which a rename keeps. https://github.com/btclib-org/btclib-wallet/blob/main/SECURITY.md


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

    Когда проект выпустил релиз, документация проекта ДОЛЖНА включать описательное заявление о масштабе и сроках поддержки для каждого релиза. [OSPS-DO-04.01]
    Для информирования о масштабе и сроках поддержки выпущенных программных активов проекта, проект должен иметь файл SUPPORT.md, раздел "Поддержка" в SECURITY.md или другую документацию, объясняющую жизненный цикл поддержки, включая ожидаемую продолжительность поддержки для каждого релиза, типы предоставляемой поддержки (например, исправления ошибок, обновления безопасности) и любые соответствующие политики или процедуры получения поддержки.

    SECURITY.md's Supported versions: only the latest release is supported, a fix ships as a new release, and nothing is backported. https://github.com/btclib-org/btclib-wallet/blob/main/SECURITY.md


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

    Когда проект выпустил релиз, документация проекта ДОЛЖНА предоставлять описательное заявление о том, когда релизы или версии больше не будут получать обновления безопасности. [OSPS-DO-05.01]
    Для информирования о масштабе и сроках поддержки исправлений безопасности, проект должен иметь SUPPORT.md или другую документацию, объясняющую политику проекта в отношении обновлений безопасности.

    SECURITY.md's Supported versions states that a release stops receiving security updates as soon as the next one is published, since only the latest is supported and nothing is backported. https://github.com/btclib-org/btclib-wallet/blob/main/SECURITY.md


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

    Документация проекта ОБЯЗАНА содержать политику, согласно которой соавторы кода проходят проверку перед предоставлением им расширенных прав доступа к чувствительным ресурсам. [OSPS-GV-04.01]
    Опубликуйте исполняемую политику в документации проекта, которая требует, чтобы участники кода были проверены и одобрены до предоставления повышенных разрешений на доступ к критическим ресурсам, таким как одобрение слияния или доступ к секретам. Рекомендуется, чтобы проверка включала установление обоснованной линии идентичности, такой как подтверждение связи участника с известной доверенной организацией.

    A grant of write or admin, to any repository of the organization, is an issue in btclib-org/.github that states the reason, and an owner other than the one asking approves it there. https://github.com/btclib-org/.github/blob/main/GOVERNANCE.md#how-a-decision-is-made


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

    Когда проект выпустил релиз, все скомпилированные выпущенные программные активы ДОЛЖНЫ поставляться со списком компонентов программного обеспечения (Software Bill of Materials). [OSPS-QA-02.02]
    Рекомендуется автоматически генерировать SBOM во время сборки с использованием инструмента, который был проверен на точность. Это позволяет пользователям получать эти данные стандартизированным способом наряду с другими проектами в их среде.

    Every release attaches a CycloneDX 1.6 SBOM, <name>-<version>.cdx.json, built from the wheel and covered by the release attestation. It lists both files' SHA-256, the license and the declared dependencies. https://github.com/btclib-org/btclib-wallet/releases/latest


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

    Когда проект выпустил релиз, состоящий из нескольких репозиториев исходного кода, все подпроекты ДОЛЖНЫ применять требования безопасности, которые являются столь же строгими или более строгими, чем первичная кодовая база. [OSPS-QA-04.02]
    Любые дополнительные репозитории кода подпроектов, созданные проектом и скомпилированные в релиз, должны применять требования безопасности в соответствии со статусом и целями соответствующей кодовой базы. В дополнение к следованию соответствующим требованиям OSPS Baseline, это может включать требование проверки безопасности, обеспечение отсутствия уязвимостей и обеспечение отсутствия известных проблем безопасности.

    Each release is built from this single repository; the sibling packages it depends on are released separately from their own repositories, which are held to the same standard. https://github.com/btclib-org/btclib-wallet


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

    Документация проекта ОБЯЗАНА четко описывать, когда и как выполняются тесты. [OSPS-QA-06.02]
    Добавьте раздел в документацию по участию в проекте, объясняющий, как запускать тесты локально и как запускать тесты в конвейере CI/CD. Документация должна объяснять, что тестируют тесты и как интерпретировать результаты.

    CONTRIBUTING.md's The environment and the gates gives the command that runs the suite, and What gates a merge, and what only reports gives which workflows run it on every pull request, on main and on a schedule, and which of them gate a merge. https://github.com/btclib-org/btclib-wallet/blob/main/CONTRIBUTING.md


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

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

    The policy is 100% line and branch coverage, stated in CONTRIBUTING.md, and pyproject.toml sets fail_under = 100, so untested new code fails the required test check. https://github.com/btclib-org/btclib-wallet/blob/main/pyproject.toml


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

    Когда совершается коммит в основную ветку, система контроля версий проекта ДОЛЖНА требовать как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием. [OSPS-QA-07.01]
    Настройте систему контроля версий проекта так, чтобы она требовала как минимум одного одобрения изменений человеком, не являющимся автором, перед слиянием в релизную или основную ветку. Это можно достичь, требуя, чтобы запрос на включение изменений был рассмотрен и одобрен как минимум одним другим участником, прежде чем его можно будет объединить.

    The main-self-merge ruleset requires one approving review from somebody other than the author before a merge to main, and dismisses an approval on a new push. Its bypass list holds one actor, fametrano, in pull_request mode, at rest: the organization-wide bypass the maintainer kept on 2026-11-04 (btclib-org/.github#2021 and btclib-org/.github#2040). Read with gh api repos/btclib-org/btclib-wallet/rulesets/23944022 --jq '{name, bypass: [.bypass_actors[] | {actor_id, bypass_mode}], reviews: (.rules[] | select(.type == "pull_request") | .parameters | {required_approving_review_count, dismiss_stale_reviews_on_push})}', with admin rights, on 2026-11-12; actor 3296421 is fametrano (gh api users/fametrano --jq .id). btclib-org/.github's GOVERNANCE.md reserves that bypass for an emergency, and it is used for ordinary work: over the last two releases, 41 of the 46 pull requests merged had no approval from anybody other than their author (v2026.11.12 18 of 22, v2026.11.11 23 of 24). Counted with gh pr list -R btclib-org/btclib-wallet -s merged -L 500 -S 'merged:2026-11-11T12:36:22Z..2026-11-12T05:25:49Z' --json author,reviews -q '[.[] | .author.login as $a | select(any(.reviews[]; .state == "APPROVED" and .author.login != $a) | not)] | length', which prints 18, and the same with 'merged:2026-11-07T03:02:56Z..2026-11-11T12:36:21Z', which prints 23. With -q length in place of the query, the two print 22 and 24. https://github.com/btclib-org/.github/blob/main/GOVERNANCE.md#how-a-decision-is-made


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

    Когда проект выпустил релиз, проект ДОЛЖЕН выполнить моделирование угроз и анализ поверхности атаки для понимания и защиты от атак на критические пути кода, функции и взаимодействия внутри системы. [OSPS-SA-03.02]
    Моделирование угроз - это деятельность, при которой проект рассматривает кодовую базу, связанные процессы и инфраструктуру, интерфейсы, ключевые компоненты и "думает как хакер", проводя мозговой штурм о том, как система может быть взломана или скомпрометирована. Каждая выявленная угроза перечисляется, чтобы проект мог затем подумать о том, как проактивно избежать или закрыть любые бреши/уязвимости, которые могут возникнуть. Убедитесь, что это обновляется для новых функций или критических изменений.

    ASSURANCE_CASE.md's Threat model names the assets, adversaries and what is not defended, and Trust boundaries maps the attack surface where untrusted input enters, each argument naming the file, test or workflow behind it. https://github.com/btclib-org/btclib-wallet/blob/main/ASSURANCE_CASE.md


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

    Любые уязвимости в программных компонентах, не затрагивающие проект, ОБЯЗАНЫ учитываться в документе VEX, дополняющем отчет об уязвимости сведениями о невозможности эксплуатации. [OSPS-VM-04.02]
    Создайте поток VEX, сообщающий о статусе эксплуатируемости известных уязвимостей, включая детали оценки или любые меры по смягчению, препятствующие выполнению уязвимого кода.

    The CycloneDX SBOM a release attaches lists, in its vulnerabilities array, every vulnerability that the tree's .github/vex.toml judges not to affect the release, with the reason. A tree with no such judgement has no vex.toml, and its SBOM has no vulnerabilities key. https://github.com/btclib-org/.github/blob/main/README.md#12-releasing


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

    Документация проекта ОБЯЗАНА включать политику, определяющую порог для устранения проблем, выявленных при анализе состава программного обеспечения (SCA), связанных с уязвимостями и лицензиями. [OSPS-VM-05.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов SCA, связанных с уязвимостями и лицензиями. Включите процесс выявления, приоритизации и устранения этих результатов.

    The standard sets the threshold: actions/dependency-review-action fails a pull request that adds or changes a runtime dependency with an advisory of moderate severity or above, or with a licence outside the allow-list. Its settings are one file, btclib-org/.github's .github/dependency-review.yml. https://github.com/btclib-org/.github/blob/main/.github/dependency-review.yml https://github.com/btclib-org/.github/blob/main/README.md#tokens-publishing-scanning


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

    Документация проекта ОБЯЗАНА включать политику устранения нарушений, выявленных при анализе состава программного обеспечения (SCA), перед каждым выпуском. [OSPS-VM-05.02]
    Задокументируйте в проекте политику для устранения применимых результатов анализа состава программного обеспечения перед любым релизом и добавьте проверки статуса, которые подтверждают соответствие этой политике перед релизом.

    release.yml runs uv audit over every dependency the wheel declares, and every publish job needs it to succeed. An advisory, or a service it cannot reach, stops the release. The only exemption is an id that the tree's own .github/vex.toml, carried into the release's signed SBOM, states as not affecting it. https://github.com/btclib-org/.github/blob/main/README.md#12-releasing


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

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

    The required lint check audits the whole uv.lock, every dependency group, on every pull request: check_audit.py --all-groups runs uv audit, which reads OSV's malicious-package (MAL-) entries as well as advisories. Any such entry fails the check, and so does an OSV that cannot be reached. The audit's only exemption is a .github/vex.toml entry, reviewed like any other change. The required Dependency review check also blocks a change that adds a runtime dependency with an advisory of moderate severity or above, or a licence outside the allow-list. https://github.com/btclib-org/.github/blob/main/README.md#12-releasing https://github.com/btclib-org/.github/blob/main/README.md#tokens-publishing-scanning


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

    Документация проекта ОБЯЗАНА включать политику, определяющую порог для устранения проблем, выявленных статическим анализом кода безопасности (SAST). [OSPS-VM-06.01]
    Задокументируйте в проекте политику, определяющую порог для устранения результатов статического тестирования безопасности приложений (SAST). Включите процесс выявления, приоритизации и устранения этих результатов.

    The standard's section 5 sets a threshold of zero for ruff: select = ALL, bandit's S rules included, and each finding is fixed or suppressed in place with a reason. zizmor holds workflows to the same, in the required lint check. CodeQL runs on every pull request, but the standard sets no threshold for its alerts. https://github.com/btclib-org/.github/blob/main/README.md#5-ruff


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

    Все изменения в кодовой базе проекта ОБЯЗАНЫ автоматически проверяться на соответствие задокументированной политике в отношении слабых мест безопасности и блокироваться при выявлении нарушений, за исключением случаев, когда они заявлены и подавлены как неэксплуатируемые. [OSPS-VM-06.02]
    Создайте проверку статуса в системе контроля версий проекта, которая запускает инструмент статического тестирования безопасности приложений (SAST) для всех изменений в кодовой базе. Требуйте, чтобы проверка статуса проходила успешно, прежде чем изменения могут быть объединены.

    The required lint check runs .pre-commit-config.yaml on every pull request: ruff with the bandit S rules, strict mypy, zizmor and detect-secrets. Any finding blocks the merge unless suppressed at its site with a reason. CodeQL also runs on every pull request, but is not a required check. https://github.com/btclib-org/btclib-wallet/blob/main/.github/workflows/lint.yml



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

Владелец анкеты на значок проекта: Ferdinando Ametrano.
2026-09-24 15:04:06 UTC, последнее изменение сделано 2026-11-12 15:28:40 UTC. Последний раз условия для получения значка были выполнены 2026-09-24 17:43:53 UTC.