go-derive

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

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

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


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

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

        

 Основы 13/13

  • Общая

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

    Go SDK for the Derive exchange — REST + WebSocket, EIP-712 signing, typed errors, full JSON-RPC coverage.

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

    go-derive is a Go SDK for the Derive (formerly Lyra) crypto-derivatives exchange.

    The project is currently solo-maintained and pre-1.0.
    First release: v0.1.0 (2026-05-05)
    Current version: v0.2.7

    Security features:

    • CycloneDX and SPDX SBOMs for every release
    • Cosign keyless OIDC signatures
    • SLSA Level 3 provenance

    CI and security tooling:

    • CodeQL
    • gosec
    • Semgrep
    • Trivy
    • Codacy
    • osv-scanner
    • govulncheck
    • gitleaks
    • TruffleHog
    • OpenSSF Scorecard

    Repository protections:

    • PR-only workflow
    • Linear history
    • Signed squash merges
    • 14 required status checks
    • GitHub Rulesets enforcement

    Release process:

    • Fully automated with release-please
    • Conventional Commits based
  • Основная информация на веб-сайте проекта


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

    go-derive is a Go SDK for the Derive exchange (formerly Lyra), a layer-2 derivatives venue supporting perps, options, and spot markets.

    Supported features:

    • REST public and private APIs
    • WebSocket public and private APIs
    • Subscription streams
    • EIP-712 order signing
    • Session key support

    The SDK provides programmatic access to Derive market data and trading APIs from Go, including built-in EIP-712 signing so users do not need to implement the signing flow themselves.



    Веб-сайт проекта ОБЯЗАН предоставлять информацию о том, как: получать и предоставлять обратную связь (например, отчеты об ошибках или улучшения) и вносить свой вклад в программное обеспечение. [interact]

    Install:

    • go get github.com/amiwrpremium/go-derive
    • README includes a working Quick Start example

    Feedback:

    • Structured GitHub issue templates for bug reports and feature requests
    • Contact links configured through .github/ISSUE_TEMPLATE/config.yml

    Contributing:

    • CONTRIBUTING.md documents:
      • Conventional Commits requirements
      • commit type → semantic version bump mapping
      • branch protection rules
      • automated release-please workflow

    The README Contributing section and "PRs Welcome" badge both link to CONTRIBUTING.md.



    В описании того, как сделать вклад, НЕОБХОДИМО объяснить процесс внесения вклада (например, используются ли pull request'ы). (Требуется URL) [contribution]
    Мы предполагаем, что проекты на GitHub используют issues и pull requests, если не указано иное. Описание может быть кратким, например, указывать, что проект использует pull requests, issue tracker или сообщения в список рассылки (какой?).

    Non-trivial contribution file in repository: https://github.com/amiwrpremium/go-derive/blob/master/CONTRIBUTING.md.



    В информацию о том, как внести вклад, СЛЕДУЕТ включать требования к приемлемым взносам (например, ссылку на любой требуемый стандарт кодирования). (Требуется URL) [contribution_requirements]
  • Свободная лицензия


    ПО, создаваемое проектом, ОБЯЗАНО быть выпущено под свободной лицензией. [floss_license]
    Свободное ПО (далее СПО) - это программное обеспечение, которое соответствует Определению Открытого ПО (официальный текст на англ.) или Определению Свободного Программного Обеспечения. Примеры таких лицензий включают CC0, MIT, BSD 2-Clause, BSD 3-Clause, Apache 2.0, Меньшая стандартная общественная лицензия GNU (LGPL) и Стандартная общественная лицензия GNU (GPL). Для наших целей это означает, что лицензия ОБЯЗАНА быть: ПО МОЖЕТ одновременно лицензироваться на других условиях (например, приемлема комбинация «GPLv2 или закрытая лицензия»).

    The MIT license is approved by the Open Source Initiative (OSI).



    ЖЕЛАТЕЛЬНО, чтобы все лицензии для ПО, создаваемого проектом, были одобрены Open Source Initiative (OSI). [floss_license_osi]
    Для одобрения OSI используется строгий процесс, чтобы определить, какие лицензии соответствуют Открытому ПО.

    The MIT license is approved by the Open Source Initiative (OSI).



    Проект ОБЯЗАН публиковать лицензию или лицензии своих результатов в стандартном расположении в своем репозитории исходного кода. (Требуется URL) [license_location]
    Например, в качестве файла верхнего уровня с именем LICENSE или COPYING. Имена файлов лицензии МОГУТ сопровождаться расширением, таким как «.txt» или «.md». Другим соглашением может быть наличие каталога с именем LICENSES, содержащего файлы лицензий; имена этих файлов обычно соответствуют SPDX-идентификатору лицензии, за которым следует соответствующее расширение файла, как описано в спецификации REUSE . Обратите внимание, что этот критерий является обязательным только для репозитория с исходным кодом. Вам НЕ нужно включать файл лицензии при генерации чего-либо из исходного кода (например, исполняемого файла, пакета или контейнера). Например, при создании пакета R для Comprehensive R Archive Network (CRAN) рекомендуется следовать стандартной практике CRAN: если лицензия является стандартной, используйте стандартную короткую спецификацию лицензии (чтобы избежать установки еще одной копии текста) и добавьте файл LICENSE в списке исключений, например .Rbuildignore. Аналогично, при создании пакета Debian вы можете поместить в файл copyright ссылку на текст лицензии в /usr/share/common-licenses и исключить файл лицензии из созданного пакета (например, удаляя файл после вызова dh_auto_install). Мы рекомендуем включать машиночитаемую информацию о лицензии в сгенерированных форматах, где это возможно.

    Non-trivial license location file in repository: https://github.com/amiwrpremium/go-derive/blob/master/LICENSE.


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


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

    Some documentation basics file contents found.



    Проект ОБЯЗАН предоставлять справочную документацию, описывающую внешний интерфейс (как входной, так и выходной) программного обеспечения, создаваемого проектом. [documentation_interface]
    Документация внешнего интерфейса объясняет конечному пользователю или разработчику, как его использовать. Это может включать в себя интерфейс прикладного программирования (API), если программное обеспечение его имеет. Если это библиотека, документируйте основные классы/типы и методы/функции, которые можно вызвать. Если это веб-приложение, определите его URL-интерфейс (часто его интерфейс REST). Если это интерфейс командной строки, документируйте параметры и настройки, которые он поддерживает. Во многих случаях лучше всего, если большая часть этой документации будет автоматически сгенерирована, чтобы эта документация была синхронизирована с программным обеспечением по мере его изменения, но это не требуется. Проект МОЖЕТ использовать гипертекстовые ссылки для не-проектных материалов в качестве документации. Документация МОЖЕТ быть автоматически сгенерирована (там, где это применимо, это часто наилучший способ создания документации). Документация интерфейса REST может быть сгенерирована с использованием Swagger/OpenAPI. Документация по интерфейсу кода МОЖЕТ быть сгенерирована с использованием таких инструментов, как JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) и Doxygen (многие языки). Просто иметь комментарии в коде реализации недостаточно для выполнения этого критерия; должен быть простой способ увидеть информацию без чтения всего исходного кода. Если проект не создает программное обеспечение, выберите «неприменимо» (N/A).

    Reference documentation is published on pkg.go.dev and linked from the README's Go Reference badge.

    Documentation characteristics:

    • generated from godoc comments
    • covers all public interfaces
    • every public package includes a multi-paragraph overview
    • every exported type, function, method, struct field, and constant is documented
    • more than 500 documentation comments across the root package and pkg/

    API documentation:

    • method inputs documented at the parameter level
    • outputs documented through return types
    • request and response structures linked through pkg/types

    Examples:

    • runnable examples under:
      • /examples/auth
      • /examples/derive
      • /examples/rest
      • /examples/ws
    • Example_* functions render directly on pkg.go.dev

  • Другое


    Сайты проекта (веб-сайт, репозиторий и URL-адреса для загрузки) ОБЯЗАНЫ поддерживать HTTPS с использованием TLS. [sites_https]
    Для выполнения этого критерия требуется, чтобы URL домашней страницы проекта начинался с "https:", а не "http:". Вы можете получить бесплатные сертификаты от проекта Let's Encrypt. Проекты МОГУТ выполнить этот критерий, используя (например) GitHub Pages, GitLab Pages или проектные страницы SourceForge. Если вы поддерживаете HTTP, мы настоятельно рекомендуем перенаправить HTTP-трафик на HTTPS.

    Given only https: URLs.



    Проект ОБЯЗАН иметь один или несколько механизмов для обсуждения (включая предлагаемые изменения и проблемы), которые доступны для поиска, позволяют ссылаться на сообщения и темы по URL, позволяют новым людям участвовать в некоторых обсуждениях и не требуют установки на стороне клиента проприетарного программного обеспечения. [discussion]
    Примерами приемлемых механизмов являются архивируемые списки рассылки, обсуждения в GitHub issues и pull requests, Bugzilla, Mantis и Trac. Асинхронные механизмы обсуждения (например, IRC) приемлемы, если они отвечают этим критериям; убедитесь, что есть механизм архивирования URL-адресов. Разрешено, хотя и не рекомендуется, использовать проприетарный JavaScript.

    GitHub supports discussions on issues and pull requests.



    Проекту СЛЕДУЕТ предоставлять документацию на английском языке и иметь возможность принимать отчеты об ошибках и комментарии о коде на английском языке. [english]
    Английский в настоящее время является лингва франка компьютерной техники; Поддержка английского языка увеличивает число потенциальных разработчиков и рецензентов во всем мире. Проект может соответствовать этому критерию, даже если английский не является основным языком его ключевых разработчиков.

    All project-facing documentation is written in English, including:

    • README.md
    • CONTRIBUTING.md
    • SECURITY.md
    • CODE_OF_CONDUCT.md
    • documentation under docs/
    • GitHub issue templates
    • godoc and source-code comments

    Community interaction:

    • bug reports handled through GitHub Issues
    • technical discussions conducted in English
    • maintainer communication is in English


    НЕОБХОДИМО, чтобы проект поддерживался. [maintained]
    Как минимум, проект должен пытаться реагировать на сообщения о серьезных проблемах и уязвимостях. Проект, который активно добивается получения значка, вероятно, и поддерживается тоже. Ресурсы любого проекта и человека ограничены, и обычно проекты будут отклонять некоторые предлагаемые изменения; поэтому ограниченность ресурсов и отклонение предложений сами по себе не указывают на то, что проект не поддерживается.

    Если известно, что проект больше не будет поддерживаться, следует установить для этого критерия значение «Не соответствует» и использовать подходящие механизмы, чтобы указать другим, что он не поддерживается. Например, используйте “DEPRECATED” («УСТАРЕЛ») в качестве первого заголовка в файле README, добавьте “DEPRECATED” в начале его домашней страницы, добавьте “DEPRECATED” в начало описания проекта репозитория кода, добавьте значок об отсутствии поддержки в README проекта и/или домашнюю страницу, пометьте его как устаревший в любых репозиториях пакетов (напр., npm deprecate ) и/или используйте механизм, предоставленный репозиторием кода для его архивирования (например, параметр "archive" у GitHub или пометка "archive" у GitLab, статус «только для чтения» у Gerrit или статус «брошенного» проекта у SourceForge). Дополнительное обсуждение можно найти здесь .

    Project maintenance is active and continuous.

    Current activity indicators (as of 2026-05-07):

    • 29 merged pull requests on master
    • 7 releases shipped within ~48 hours (v0.2.0v0.2.7)
    • CI runs on every push and pull request
    • daily OpenSSF Scorecard scans
    • automated dependency updates via Renovate
    • automated releases via release-please

    Operational tooling:

    • renovate.json manages dependency update automation
    • release-please manages versioning and release generation
    • README includes a live "Last commit" badge showing repository freshness

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

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


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

    Repository on GitHub, which provides public git repositories with URLs.



    Проектный репозиторий исходного кода ОБЯЗАН отслеживать, какие изменения были внесены, кто внес изменения и когда изменения были сделаны. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



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

    The master branch contains the active development history, not only release tags.

    Development workflow:

    • all changes land through pull requests
    • pull requests are squash-merged
    • merge commits follow Conventional Commits formatting

    Repository activity:

    • 29 merged pull requests visible in GitHub history
    • releases are preceded by multiple development PRs and commits

    Example:

    • release v0.2.5 was preceded by PRs:
      • #23
      • #25
      • #26
    • each merged independently onto master

    Review traceability:

    • PR descriptions preserved
    • review discussions preserved
    • file diffs preserved
    • CI execution history preserved


    Для хранилища проектного исходного кода ЖЕЛАТЕЛЬНО использовать типовое ПО для распределенного управления версиями (например, git). [repo_distributed]
    Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

    Repository on GitHub, which uses git. git is distributed.


  • Уникальная нумерация версий


    Результаты проекта ОБЯЗАНЫ иметь уникальный идентификатор версии для каждой версии, предназначенной для конечных пользователей. [version_unique]
    Это МОЖНО выполнить различными способами, включая идентификаторы коммита (например, идентификатор коммита git или идентификатор набора изменений mercurial) или номер версии (включая номера версий, которые используют семантическое версионирование или схемы на основе даты, такие как YYYYMMDD).

    Each release uses a unique Semantic Version identifier.

    Versioning workflow:

    • release-please calculates versions from Conventional Commits
    • versions are synchronized across:
      • git tags (e.g. v0.2.7)
      • the Version constant in derive.go
      • .github/.release-please-manifest.json

    Release integrity:

    • repository ruleset release-tag-protection (id 15981700) prevents:
      • tag reuse
      • tag rewriting

    Release history is published through the GitHub Releases page.



    Для выпусков ЖЕЛАТЕЛЬНО использовать семантическую либо календарную нумерацию версий. При использовании календарной нумерации к версии ЖЕЛАТЕЛЬНО добавлять микро-компоненту. [version_semver]
    МОЖНО использовать в качестве номеров версий другие схемы нумерации версий, такие как идентификаторы коммитов (например, идентификатор коммита в git или идентификатор набора изменений в mercurial) или схемы на основе даты, такие как YYYYMMDD, поскольку они уникальны. Некоторые альтернативы могут вызвать трудности, поскольку пользователи могут быть не в состоянии легко определить, используют ли они последнюю версию. SemVer может оказаться менее полезным для идентификации версий программного обеспечения, если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-сервиса, который постоянно обновляется с помощью непрерывной доставки).


    Проектам ЖЕЛАТЕЛЬНО идентифицировать каждый выпуск в своей системе управления версиями. Например, при использовании git ЖЕЛАТЕЛЬНО идентифицировать каждую версию, используя теги git. [version_tags]

    Each release is identified by a git tag using the format:

    • vX.Y.Z
    • example: v0.2.7

    Tag management:

    • tags are created automatically by release-please
    • tags are generated when the auto-generated release PR is merged

    Tag protection:

    • repository ruleset release-tag-protection (id 15981700) prevents:
      • tag reuse
      • tag deletion
      • tag rewriting

    The complete release tag history is available through the GitHub Tags page.


  • Примечания к выпуску


    Проект ОБЯЗАН предоставлять с каждой выпускаемой версией замечания к выпуску - удобочитаемые человеком сведения об основных изменениях в этом выпуске, помогающие пользователям определить, должны ли они обновляться и какими будут последствия обновления. НЕДОПУСТИМО делать замечания к выпуску сырым выводом журнала управления версиями (например, результаты команды «git log» не являются замечаниями к выпуску). Проекты, результаты которых не предназначены для повторного использования в нескольких местах (например, программное обеспечение для одного веб-сайта или службы) И выдаются через непрерывную доставку (continuous delivery) МОГУТ выбрать «неприменимо» (N/A). (Требуется URL) [release_notes]
    Замечания к выпуску МОГУТ быть реализованы различными способами. Многие проекты предоставляют их в файле с именем «NEWS», «CHANGELOG» или «ChangeLog», возможно с расширениями, такими как «.txt», «.md» или «.html». Исторически термин «журнал изменений» означал журнал для каждого изменения, но для соответствия этим критериям требуется человекочитаемая сводка. Замечания к выпуску МОГУТ вместо этого быть предоставлены механизмами системы контроля версий, такими как процесс GitHub Releases.

    Non-trivial release notes file in repository: https://github.com/amiwrpremium/go-derive/blob/master/CHANGELOG.md.



    В замечаниях о выпуске НЕОБХОДИМО упоминать каждую общеизвестную уязвимость, исправленную ​​в каждой новой версии, для которой существует CVE или аналогичная публичная запись. Критерий может быть отмечен как неприменимый (N/A), если у пользователей обычно нет практической возможности обновить данное ПО самостоятельно (это часто относится к, например, обновлениям ядра операционной системы). Если замечаний о выпуске не публиковалось или не было обнародованных уязвимостей, отвечайте "неприменимо". [release_notes_vulns]
    Этот критерий помогает пользователям определить, исправит ли данное обновление общеизвестную уязвимость, чтобы помочь пользователям принять обоснованное решение об обновлении. Если пользователи обычно не могут практически самостоятельно обновлять программное обеспечение на своих компьютерах, а вместо этого должны полагаться на одного или нескольких посредников для выполнения обновления (как это часто бывает с ядром и низкоуровневым программным обеспечением, которое взаимосвязано с ядром), проект вместо этого можно выбрать «Неприменимо», поскольку эта дополнительная информация будет бесполезна для таких пользователей. Аналогично, проект может выбрать «неприменимо» (N/A), если все получатели используют только последнюю версию (например, это код для одного веб-сайта или интернет-службы, который постоянно обновлен при помощи непрерывной доставки). Этот критерий применим только к результатам проекта, а не к его зависимостям. Перечисление уязвимостей всех транзитивных зависимостей проекта становится громоздким, поскольку зависимости увеличиваются и изменяются; и в этом нет необходимости, поскольку инструменты, которые исследуют и отслеживают зависимости, могут делать это более масштабируемым способом.

    No publicly known runtime vulnerabilities have been disclosed for go-derive.

    Current security status across releases v0.1.0v0.2.7:

    • no assigned CVEs
    • no GitHub Security Advisories
    • no reported runtime vulnerabilities

    Security scanning performed in CI includes:

    • govulncheck
    • osv-scanner
    • Trivy
    • gosec
    • Semgrep
    • CodeQL

    Release notes:

    • CHANGELOG.md is generated automatically by release-please
    • changelog entries are derived from Conventional Commits
    • any future security fixes would appear under "Bug Fixes" and include the relevant CVE reference when applicable

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

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


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

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/amiwrpremium/go-derive/blob/master/SECURITY.md. [osps_do_02_01]



    СЛЕДУЕТ использовать трекер вопросов (issue tracker) для отслеживания отдельных вопросов. [report_tracker]

    GitHub Issues at https://github.com/amiwrpremium/go-derive/issues, with structured templates in .github/ISSUE_TEMPLATE/ (bug_report, feature_request, config).



    Проект ОБЯЗАН подтверждать получение большинства сообщений об ошибках, отправленных за последние 2-12 месяцев (включительно); подтверждение не обязательно включает исправление. [report_responses]

    The project is 2 days old.
    First release: v0.1.0 on 2026-05-05.

    Issue tracker status:

    • 2 total issues
    • both are bot-generated

    Issues:

    • #5 Renovate config notice
      • closed by PR #1
    • #7 Renovate Dependency Dashboard
      • intentionally kept open

    No user-submitted bug reports have been filed so far.

    The maintainer is the sole responder and handles issue triage through GitHub notifications.



    Проекту СЛЕДУЕТ реагировать на большинство (>50%) запросов на улучшения в течение последних 2-12 месяцев (включительно). [enhancement_responses]
    В качестве ответа МОЖЕТ быть «нет» или обсуждение выгод от данного улучшения. Цель состоит в том, чтобы по крайней мере на некоторые запросы был какой-то ответ, что указывает на то, что проект все еще жив. Для целей этого критерия не нужно учитывать поддельные запросы (например, от спамеров или автоматизированных систем). Если проект больше не принимает улучшения, выберите «не соответствует» и укажите URL, проясняющий ситуацию для пользователей. Если проект большую часть времени перегружен количеством запросов на улучшения, выберите «не cоответствует» и объясните.

    No user-submitted enhancement requests have been filed.

    Project status:

    • first release: v0.1.0 on 2026-05-05
    • only 2 issues exist
    • both are Renovate-generated meta-issues

    Issues:

    • #5 closed
    • #7 Renovate Dependency Dashboard kept open by design

    The "majority responded" requirement is satisfied vacuously.



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

    All issues (open + closed, including full comment threads) are archived and searchable at:
    https://github.com/amiwrpremium/go-derive/issues?q=is%3Aissue

    GitHub provides:

    • full-text search across titles, bodies, and comments
    • filtering by:
      • author
      • label
      • state
      • date

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


    Проект ОБЯЗАН публиковать процесс уведомления об уязвимостях на сайте проекта. (Требуется URL) [vulnerability_report_process]
    Например, четко обозначенный почтовый адрес на https://PROJECTSITE/security, часто в форме security@example.org. Процесс МОЖЕТ быть таким же, как и процесс для отчетов об ошибках. Отчеты об уязвимостях МОГУТ быть всегда общедоступными, но многие проекты имеют приватный механизм для отправки отчетов об уязвимостях.

    SECURITY.md:
    https://github.com/amiwrpremium/go-derive/blob/master/SECURITY.md

    Security reporting policy:

    The policy documents:

    • required report fields
    • optional report fields
    • response SLAs by severity

    Response targets:

    • Critical/High:
      • acknowledgment within 72 hours
      • triage within 7 days
    • Medium/Low:
      • acknowledgment within 5 business days
      • triage on a best-effort basis


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

    SECURITY.md §Reporting a vulnerability:
    https://github.com/amiwrpremium/go-derive/blob/master/SECURITY.md#reporting-a-vulnerability

    Private Vulnerability Reporting:
    https://github.com/amiwrpremium/go-derive/security/advisories/new

    Policy:

    • reporters must not open public issues
    • vulnerabilities must be submitted through GitHub Private Vulnerability Reporting

    Privacy guarantees:

    • reports are visible only to repository maintainers and the reporter
    • reports are not indexed in:
      • public issues
      • repository timeline
      • GitHub search


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

    No vulnerability reports have been received.

    Project status:

    • first release: v0.1.0 on 2026-05-05
    • GitHub Security Advisories currently empty

    The 14-day initial-response requirement is satisfied vacuously.

    SECURITY.md response targets:

    • Critical/High:
      • acknowledgment within 72 hours
    • Medium/Low:
      • acknowledgment within 5 business days

    Both response targets are below the 14-day requirement.


 Качество 13/13

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


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

    ЖЕЛАТЕЛЬНО использовать общеупотребительные инструменты для сборки программного обеспечения. [build_common_tools]
    Например, Maven, Ant, cmake, autotools, make, rake или devtools (R).

    Для сборки проекта СЛЕДУЕТ использовать только инструменты со свободными лицензиями. [build_floss_tools]

    Build command:
    go build ./...

    Required tooling:

    • Go toolchain
    • BSD-3-Clause
    • FLOSS

    Dependency licensing:

    No proprietary build tools, IDEs, compilers, SDKs, or licensing servers are required.

    CI linters are also FLOSS:

    • gofmt
    • goimports
    • go vet
    • golangci-lint
    • govulncheck
    • staticcheck

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


    Проект ОБЯЗАН использовать по крайней мере один автоматизированный набор тестов, опубликованный как свободное ПО (этот набор тестов может поддерживаться как отдельный проект свободного ПО). Проект ОБЯЗАН ясно показывать или иметь документацию о том, как запускать наборы тестов (например, через непрерывную интеграцию (CI) или используя файлы документации, такие как BUILD.md, README.md или CONTRIBUTING.md). [test]
    Проект МОЖЕТ использовать несколько автоматизированных наборов тестов (например, один, который работает быстро, а другой - более тщательный, но требует специального оборудования). Существует множество каркасов (frameworks) и систем поддержки тестирования, включая Selenium (автоматизация веб-браузера), Junit (JVM, Java), RUnit (R), testthat (R).

    Testing framework:

    • Go standard testing package
    • BSD-3-Clause
    • included with the Go toolchain

    Test command:
    go test -race -count=1 ./...

    Documented in:

    CI execution:

    • runs on every push and pull request
    • test matrix:
      • ubuntu-latest
      • macos-latest
      • windows-latest
    • Go versions:
      • 1.25
      • 1.26

    Integration tests:

    • located under test/
    • protected behind an integration build tag
    • dispatched manually through:
      .github/workflows/integration.yml


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

    Tests are executed with:

    • go test ./...
    • go test -race -count=1 ./...

    The project uses:

    • standard _test.go test files
    • Go's built-in testing package

    No custom test runner or test harness is required.



    ЖЕЛАТЕЛЬНО охватывать набором тестов большинство (а в идеале все) ветви кода, поля ввода и функциональные возможности. [test_most]

    Coverage:

    • 90.2% statement coverage
    • measured with:
      go test -race -coverprofile -coverpkg=...

    Test suite size:

    • 110 _test.go files
    • 7,369 LOC of tests
    • 8,378 LOC of source

    Coverage reporting:

    Coverage regressions are flagged on pull requests.



    ЖЕЛАТЕЛЬНО реализовать непрерывную интеграцию (Continuous Integration - частая интеграция нового или измененного кода в центральное хранилище кода, и запуск автоматических тестов на получившейся базе кода). [test_continuous_integration]

    Continuous integration uses GitHub Actions.

    CI workflow:

    • .github/workflows/ci.yml
    • runs on every push and pull request

    CI tasks:

    • gofmt
    • go vet
    • go test -race -coverprofile
    • govulncheck
    • go build

    Test matrix:

    • ubuntu
    • macos
    • windows
    • Go 1.25
    • Go 1.26

    Branch protection:

    • merging to master requires 14 status checks
    • enforced by:
      master-branch-protection ruleset (15981309)

    Workflow coverage:

    • tests
    • linting
    • security scanning
    • supply-chain verification
    • release verification

    Security tooling:

    • CodeQL
    • gosec
    • Semgrep
    • Trivy
    • Codacy
    • osv-scanner
    • gitleaks
    • TruffleHog

    Additional checks:

    • pin-check
    • license-check
    • govulncheck

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


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

    CONTRIBUTING.md §Coverage:
    https://github.com/amiwrpremium/go-derive/blob/master/CONTRIBUTING.md#coverage

    Policy:
    "Patches that meaningfully drop coverage will get flagged on the PR."

    Enforcement:

    • Codecov posts diff-coverage comments
    • Codacy runs:
      • Codacy Coverage Variation
      • Codacy Diff Coverage

    Checks run on every pull request and mechanically surface new functionality lacking tests.



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

    Evidence:

    • 90.2% coverage existed at v0.1.0 and remained stable across 7 releases
    • tests were committed alongside source from the beginning

    Examples:

    • PR #10 removed Trade.Realized and its dedicated test in the same commit
    • PR #17 refactored internal/retry/backoff.go to use crypto/rand
      • existing backoff_test.go validated the new implementation without modification

    PR enforcement:

    • every PR includes:
      • Codecov delta checks
      • Codacy Diff Coverage checks
    • untested new code is flagged automatically


    ЖЕЛАТЕЛЬНО задокументировать эту политику добавления тестов (см. критерий test_policy) в инструкции к предложениям об изменениях. [tests_documented_added]
    Однако даже неформальное правило приемлемо, если тесты добавляются на практике.

    Test expectations are documented in CONTRIBUTING.md through the coverage policy and CI enforcement rules, but there is no explicit standalone "tests must accompany changes" instruction in the change-proposal workflow.

    Adding an explicit requirement for contributors to include or update tests alongside behavioral changes is therefore suggested.


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


    Проект ОБЯЗАН включать один или несколько предупреждающих флагов компилятора, «безопасный» языковой режим или использовать отдельный инструмент «linter» для поиска ошибок качества кода или типовых простых ошибок, если есть хотя бы один инструмент на свободном ПО, который может реализовать этот критерий на выбранном языке. [warnings]
    Примером предупреждающего флага компилятора может служить "-Wall" для gcc/clang. Примеры «безопасного» языкового режима включают «use strict» в JavaScript и «use warnings» в perl5. Отдельный инструмент «linter» - это просто инструмент, который исследует исходный код для поиска ошибок качества кода или типовых простых ошибок. Всё это обычно включается в исходный код или инструкции сборки.

    The repository uses multiple FLOSS Go linters and analysis tools:

    • golangci-lint
    • staticcheck
    • gosec
    • go vet
    • gofmt
    • goimports

    Workflows:

    • .github/workflows/lint.yml
    • .github/workflows/gosec.yml
    • .github/workflows/ci.yml

    Git hooks:

    • Lefthook runs:
      • gofmt
      • goimports
      • go vet
      • golangci-lint run --new-from-rev=HEAD
    • documented in CONTRIBUTING.md §Git hooks

    Policy:

    • lint warnings fail CI
    • required status checks block merges on lint failures


    Проект ОБЯЗАН обращать внимание на предупреждения. [warnings_fixed]
    Речь о предупреждениях, найденных при выполнении критерия warnings. Проект должен исправлять предупреждения или отмечать их в исходном коде как ложные срабатывания. В идеале не должно быть никаких предупреждений, но проект МОЖЕТ принимать существование каких-то предупреждений (обычно менее 1 предупреждения на 100 строк или менее 10 предупреждений).

    Linter warnings are treated as build failures.

    Enforced tooling:

    • golangci-lint
    • staticcheck
    • gosec
    • go vet
    • gofmt

    Policy:

    • any finding exits non-zero
    • all are required status checks on the master ruleset
    • PRs cannot merge with open lint warnings

    Example:

    • PR #17 triggered gosec G404 on math/rand/v2
    • the code was rewritten to use crypto/rand
    • the warning was fixed, not suppressed

    Code-scanning alerts from:

    • gosec
    • Semgrep
    • CodeQL
    • Trivy

    are actively triaged and documented in:
    docs/known-tool-issues.md



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

    All linters run in strict/default mode with no rule exclusions.

    Configuration:

    • golangci-lint uses upstream defaults
    • staticcheck uses upstream defaults
    • gosec scans the full repository and uploads SARIF
    • gofmt and goimports fail on unformatted files
    • go vet runs without exclusions

    Suppression policy:

    • zero in-source:
      • nolint
      • nosec
      • noqa
        suppressions

    Project policy:

    • issues are fixed at source instead of suppressed
    • unavoidable tool false positives remain visible and are documented in:
      docs/known-tool-issues.md

    Documented examples:

    • Codacy deadcode-on-generics parser bug
    • remark-lint resolver false positives

 Безопасность 16/16

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


    По крайней мере один основной разработчик на проекте ОБЯЗАН знать, как проектировать безопасное программное обеспечение (точные требования описаны в подробностях к критерию). [know_secure_design]
    Это требует понимания следующих принципов проектирования, в том числе 8 принципов из Saltzer and Schroeder:
    • экономичность механизма (поддерживать дизайн ПО настолько простым и компактным, насколько практически возможно, например, с помощью массовых упрощений)
    • отказобезопасные значения по умолчанию (доступ по умолчанию должен быть запрещен, а установка проектов по умолчанию должна быть в защищенной конфигурации)
    • полное разграничение (любой доступ, который может быть ограничен, должен проверяться на достаточность прав доступа и не иметь обходных путей)
    • открытый дизайн (механизмы безопасности должны полагаться не на незнание их злоумышленником, а на данные типа ключей и паролей, которые проще защищать и менять)
    • разделение привилегий (в идеале доступ к важным объектам должен зависеть от более чем одного условия, так чтобы взлом одной системы защиты не приводил к полному доступу; напр., многофакторная аутентификация с требованием и пароля, и аппаратного токена сильнее однофакторной)
    • минимальные привилегии (процессы должны работать с минимальными привилегиями, необходимыми для выполнения ими своих функций)
    • наименьший общий механизм (дизайн должен минимизировать механизмы, общие для нескольких пользователей и следовательно зависящие от всех этих пользователей, например, каталоги для временных файлов)
    • психологическая приемлемость (интерфейс для человека должен быть спроектирован с учетом удобства использования - может быть полезным проектирование для «наименьшего удивления»)
    • ограничение периметра атаки (периметр атаки - множество разных точек, в которых злоумышленник может попытаться ввести или извлечь данные - должен быть ограничен)
    • проверка входных данных с помощью списков на допуск (входы обычно должны проверяться на корректность до их принятия; эта проверка должна использовать списки на допуск, содержащие только заведомо хорошие значения, а не списки на запрет, пытающиеся перечислить заведомо плохие значения).
    «Основной разработчик» в проекте - это любой, кто знаком с базой кода проекта, без затруднений может вносить в него изменения и признан таковым большинством других участников проекта. Основной разработчик, как правило, неоднократно вносит вклад в течение последнего года (через код, документацию или ответы на вопросы). Разработчики обычно считаются основными разработчиками, если это они начали проект (и не покинули проект более трех лет назад), имеют возможность получать информацию по закрытому каналу для отчетов об уязвимостях (если он есть), могут принимать коммиты от имени проекта или делать финальные выпуски программного обеспечения проекта. Если есть только один разработчик, этот человек является основным разработчиком. Есть много книг и курсов, помогающих понять, как разрабатывать более безопасное ПО, с обсуждением вопросов проектирования. Например, Secure Software Development Fundamentals - это бесплатный набор из трех курсов, объясняющих, как разрабатывать более безопасное ПО (бесплатный для обучения; за отдельную плату вы можете получить сертификат для подтверждения, что вы освоили материал).

    Self-attested security evidence in the repository includes:

    • correct EIP-712 typed-data signing in pkg/auth
    • separate EIP-191 and EIP-712 signing flows
    • session-key delegation to avoid keeping owner keys in process memory

    Security improvements:

    • cryptographic randomness via crypto/rand
      • PR #17
    • explicit validation on every workflow_dispatch input
      • PR #18

    Supply-chain hardening:

    • CycloneDX + SPDX SBOMs
    • cosign keyless signatures
    • SLSA Level 3 provenance
    • SHA-pinned GitHub Actions enforced by:
      .github/workflows/pin-check.yml

    CI hardening:

    • step-security/harden-runner on every CI job

    Security process:

    • private vulnerability reporting documented in SECURITY.md
    • severity-based response SLAs

    Defence-in-depth:

    • 9 SAST/secret/dependency scanners
    • daily OpenSSF Scorecard scans


    По крайней мере, один из основных разработчиков проекта ОБЯЗАН знать об общих видах ошибок, которые приводят к уязвимостям в этом виде программного обеспечения, а также по крайней мере одному методу противодействия или смягчения каждого из них. [know_common_errors]
    Примеры (в зависимости от типа ПО) включают внедрение SQL-кода (injection), внедрение на уровне ОС, классическое переполнение буфера, межсайтовый скриптинг, отсутствие проверки подлинности и отсутствие авторизации. Обычно используемые списки уязвимостей можно найти в CWE/SANS top 25 или OWASP Top 10. Есть много книг и обучающих курсов, помогающих понять, как разрабатывается безопасное программное обеспечение, и обсуждающих типичные ошибки в реализации, ведущие к уязвимостям. К примеру, Secure Software Development Fundamentals - это набор из трех курсов, объясняющих, как сделать разрабатываемое ПО более безопасным (бесплатный для прослушивания; за дополнительную плату вы можете получить справку о том, что прошли его).

    Self-attested security mitigations in the repository include:

    • weak randomness mitigation:

      • crypto/rand
    • integer narrowing protection:

      • explicit & 0xFFFF mask in pkg/auth/nonce.go
    • auth-bypass prevention:

      • separate EIP-191 and EIP-712 signing flows
      • session-key delegation keeps owner keys off-host
    • input injection protection:

      • regex validation for workflow_dispatch.inputs
      • implemented in PR #18
    • race-condition detection:

      • go test -race on every CI build
    • secret-leak detection:

      • gitleaks
      • TruffleHog
      • GitGuardian
    • dependency vulnerability scanning:

      • govulncheck
      • osv-scanner
      • Trivy
      • Renovate
    • supply-chain hardening:

      • SHA-pinned GitHub Actions
      • cosign-signed SBOMs
      • SLSA Level 3 provenance
    • static analysis and bug detection:

      • CodeQL
      • gosec
      • Semgrep
      • Codacy
      • golangci-lint
      • staticcheck

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

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

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

    All cryptographic operations use publicly-published, expert-reviewed primitives.

    Cryptographic standards and primitives:

    Underlying cryptography:

    • ECDSA on secp256k1
    • keccak-256 hashing
    • OS randomness via Go crypto/rand
    • TLS via Go crypto/tls
      • TLS 1.2 / 1.3
      • RFC 5246 / RFC 8446

    No custom cryptographic primitives are implemented.



    Если программное обеспечение, создаваемое проектом, является приложением или библиотекой, и его основной целью является не внедрение криптографии, тогда для реализации криптографических функций СЛЕДУЕТ обращаться к программному обеспечению, специально предназначенному для этого; НЕ СЛЕДУЕТ повторно реализовывать свои собственные функции. [crypto_call]

    go-derive's primary purpose is exchange access, not cryptography.

    Cryptographic operations are delegated to established upstream libraries:

    • github.com/ethereum/go-ethereum/crypto

      • secp256k1 ECDSA
      • keccak-256 hashing
    • signer/core/apitypes

      • EIP-712 typed-data hashing
    • common

      • EIP-55 address checksums
    • accounts/abi

      • ABI encoding
    • Go crypto/rand

      • randomness
    • Go crypto/tls

      • transport security

    No cryptographic primitives are re-implemented in the repository.
    pkg/auth only assembles inputs and calls upstream libraries.



    Вся функциональность программного обеспечения, создаваемого проектом, которая зависит от криптографии, ОБЯЗАНА быть реализована с использованием свободного ПО. [crypto_floss]

    All cryptographic dependencies are FLOSS.

    Dependencies:

    • Go stdlib crypto/*

      • BSD-3-Clause
    • github.com/ethereum/go-ethereum/{crypto,common,accounts/abi,signer/core/apitypes}

      • LGPL-3.0
    • gorilla/websocket

      • BSD-2-Clause

    License verification:

    • .github/workflows/license-check.yml
    • runs:
      go-licenses check ./...

    Allowed licenses:

    • MIT
    • BSD
    • Apache
    • MPL
    • LGPL

    No proprietary cryptographic modules are required.



    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ использовать стандартные длины криптографических ключей, которые, по крайней мере, соответствуют минимальным требованиям NIST до 2030 года (как указано в 2012 году). Проект ОБЯЗАН предоставлять возможность настройки ПО таким образом, чтобы уменьшенные длины ключей были полностью отключены. [crypto_keylength]
    Эти минимальные длины в битах перечислены далее: симметричный ключ - 112, модуль факторизации - 2048, дискретный логарифмический ключ - 224, дискретная логарифмическая группа - 2048, эллиптическая кривая - 224 и хеш - 224 (хеширование пароля не покрывается этой длиной, больше информации о хешировании пароля можно найти в описании критерия crypto_password_storage). См. http://www.keylength.com для сравнения рекомендаций по длинам криптографических ключей от различных организаций. Программное обеспечение МОЖЕТ допускать меньшие длины ключей в некоторых конфигурациях (в идеале не должно, поскольку это позволяет атаки через понижение длины ключа, но иногда требуется более короткая длина ключа для обеспечения взаимодействия с другими системами).

    Default cryptographic settings meet or exceed NIST SP 800-57 2030+ minimum recommendations.

    Defaults:

    • secp256k1 ECDSA signing

      • ~128-bit security level
      • required by EIP-191 / EIP-712
    • keccak-256 hashing

      • 256-bit output
      • SHA-3 family
    • Go stdlib TLS defaults

      • TLS 1.2 / 1.3
      • AES-128-GCM minimum

    Restrictions:

    • secp256k1 is the only supported signing curve
    • no configuration exists to weaken:
      • curve selection
      • key size
      • hashing algorithms

    Smaller key lengths are not configurable.



    Механизмы безопасности по умолчанию в программном обеспечении, создаваемом проектом, НЕДОПУСТИМО делать зависимыми от взломанных криптографических алгоритмов (например, MD4, MD5, single DES, RC4, Dual_EC_DRBG) или использовать режимы шифрования, которые не подходят для контекста, если только они не требуются для интероперабельности протокола (поддерживающего самую новую версию стандарта на этот протокол, широко распространенного в сетевой экосистеме, причем эта экосистема требует использования данного алгоритма или режима, не предлагая более безопасных альтернатив). В документации НЕОБХОДИМО описать все связанные с этим риски безопасности и все известные способы смягчения рисков, если данные алгоритмы или режимы действительно нужны для совместимости с другими реализациями этого протокола. [crypto_working]
    Режим ECB почти никогда не подходит, потому что внутри зашифрованного ECB текста обнаруживаются идентичные блоки, как можно видеть на примере «пингвина ECB», а режим CTR часто неприемлем, поскольку не выполняет аутентификацию и приводит к дубликатам, контекста, если состояние ввода повторяется. Во многих случаях лучше всего выбирать режим алгоритма с блочным шифром, предназначенный для сочетания секретности и аутентификации, например, Galois / Counter Mode (GCM) и EAX. Проекты МОГУТ разрешать пользователям включать сломанные механизмы, где это необходимо для совместимости, но в таких случаях пользователи знают, что они это делают.

    No broken cryptographic algorithms are used in any default code path.

    Cryptographic inventory:

    • secp256k1 ECDSA
      • signing
    • keccak-256
      • hashing
    • Go crypto/rand
      • randomness
    • TLS 1.2 / 1.3
      • transport security

    The following algorithms do not appear in the source tree:

    • MD4
    • MD5
    • SHA-1
    • RC2
    • RC4
    • DES / 3DES
    • Dual_EC_DRBG

    Verification:
    grep -rE "(md4|md5|^sha1|rc4|rc2|des\.|3des|dual_ec)" --include='*.go'

    Result:

    • empty

    No interoperability fallback to legacy cryptography is required.
    Derive uses modern EIP-191 and EIP-712 signing exclusively.



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

    No algorithms with known serious weaknesses are used in default code paths.

    Cryptography:

    • signing uses keccak-256
    • SHA-1 is not used

    TLS:

    • handled by Go crypto/tls
    • defaults to AEAD ciphers:
      • AES-GCM
      • ChaCha20-Poly1305
    • TLS 1.2 and TLS 1.3 only
    • CBC suites disabled
    • static RSA key exchange disabled

    Absent from the source tree:

    • RC4
    • RC2
    • DES
    • 3DES
    • MD-family hashes

    Verified via grep across *.go files.



    В механизмах безопасности в программном обеспечении, создаваемом проектом, СЛЕДУЕТ реализовать совершенную прямую секретность для протоколов соглашений о ключах, чтобы ключ сеанса, произведенный из набора долгосрочных ключей, не мог быть скомпрометирован, если один из долгосрочных ключей скомпрометирован в будущем. [crypto_pfs]

    Perfect forward secrecy is provided by the TLS layer.

    Transport security:

    • implemented through Go crypto/tls
    • ECDHE-based key exchange by default:
      • X25519
      • P-256
      • P-384

    TLS behavior:

    • TLS 1.2 uses ephemeral ECDHE key exchange
    • TLS 1.3 requires ephemeral key exchange
    • static RSA key exchange disabled
    • static DH key exchange disabled

    Security property:

    • compromise of long-term certificate keys cannot decrypt previously captured traffic

    The SDK does not implement its own application-level key agreement.



    Если ПО, создаваемое проектом, требует хранить пароли для аутентификации внешних пользователей, НЕОБХОДИМО хранить пароли как итерированные хеши с солью для каждого пользователя с использованием алгоритма (итерированного) растяжения ключа (например, PBKDF2, Bcrypt или Scrypt). См. также: OWASP Password Storage Cheat Sheet (на англ.). [crypto_password_storage]
    Этот критерий применяется только тогда, когда программное обеспечение требует проверки внешних пользователей с использованием паролей (так называемая входящая аутентификация), таких как серверные веб-приложения. Он не применяется в тех случаях, когда программное обеспечение хранит пароли для аутентификации в других системах (исходящая аутентификация; например, программное обеспечение реализует клиент для какой-либо другой системы), поскольку по крайней мере части этого программного обеспечения должны часто обращаться к нехешированному паролю.

    N/A — go-derive does not implement password-based authentication.

    Authentication model:

    • secp256k1 signatures
    • EIP-191
    • EIP-712

    The codebase contains:

    • no login flow
    • no credential database
    • no password hashing
    • no password storage

    Private keys:

    • provided by the calling application
    • held only in memory for signing
    • never serialized or persisted by the SDK


    Механизмы безопасности в программном обеспечении, создаваемом проектом, ОБЯЗАНЫ генерировать все криптографические ключи и временные значения с использованием криптографически безопасного генератора случайных чисел; НЕДОПУСТИМО делать это с использованием генераторов, которые криптографически небезопасны. [crypto_random]
    Криптографически безопасный генератор случайных чисел может быть аппаратным генератором случайных чисел или криптографически безопасным генератором псевдослучайных чисел (CSPRNG), использующим такие алгоритмы как Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow или Fortuna. Примеры вызовов защищенных генераторов случайных чисел включают java.security.SecureRandom в Java и window.crypto.getRandomValues в JavaScript. Примеры вызовов небезопасных генераторов случайных чисел включают java.util.Random в Java и Math.random в JavaScript.

    All randomness uses Go crypto/rand, backed by the OS CSPRNG:

    • Linux: getrandom
    • macOS: arc4random_buf
    • Windows: BCryptGenRandom

    Security hardening:

    • PR #17 replaced:
      • math/rand
      • math/rand/v2
    • rewritten to use:
      • crypto/rand

    ECDSA signing:

    • signing nonces (k values) come from crypto/rand
    • provided through go-ethereum crypto.Sign

    Verification:
    grep -rE "math/rand" --include='*.go'

    Result:

    • zero matches

    No insecure RNG is reachable from any code path producing keys, nonces, or signatures.


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


    Проект ОБЯЗАН использовать механизм доставки, устойчивый против атак посредника (MITM). Приемлемо использование https или ssh + scp. [delivery_mitm]
    Еще более сильным механизмом является выпуск программного обеспечения в виде пакетов, подписанных цифровой подписью, поскольку это смягчает атаки на систему распространения, но это работает только в том случае, если пользователи могут быть уверены, что открытые ключи для подписей верны и если пользователи действительно проверяют подпись.

    Distribution channels use HTTPS exclusively. [osps_br_03_02]



    НЕДОПУСТИМО получать криптографические контрольные суммы (например, sha1sum) по HTTP и использовать их без проверки криптографической подписи. [delivery_unsigned]
    Эти хеши могут быть изменены при передаче.

    No cryptographic hash is retrieved over plain HTTP and trusted without signature verification.

    Release verification:

    • .github/workflows/verify-release.yml
    • downloads occur over HTTPS
    • verification uses:
      • cosign verify-blob
      • slsa-verifier verify-artifact

    Verification checks:

    • Sigstore certificate identity validation
    • SLSA Level 3 provenance validation

    Security hardening:

    • PR #26 removed the last curl | bash pattern from CI
    • replaced with SHA-pinned:
      • codacy/codacy-coverage-reporter-action

    Dependency integrity:

    • go install uses HTTPS module transport
    • go.sum integrity verification enabled

    GitHub Actions:

    • all third-party Actions are SHA-pinned
    • enforced by:
      .github/workflows/pin-check.yml

  • Исправление обнародованных уязвимостей


    НЕДОПУСТИМО оставлять незакрытыми уязвимости со степенью серьезности средней или выше, опубликованные более 60 дней назад. [vulnerabilities_fixed_60_days]
    Уязвимость должна быть исправлена ​​и выпущена самим проектом (патчи могут быть разработаны в другом месте). Уязвимость считается опубликованной (для цели данного критерия) после того, как она имеет CVE с описанием, бесплатно доступным для общественности, (например, в National Vulnerability Database) или когда проект был проинформирован, и информация была опубликована для общественности (возможно, самим проектом). Уязвимость имеет среднюю и высокую степень серьезности, если ее базовая оценка по CVSS 2.0 равна 4 или выше. Примечание. Это означает, что пользователи могут оставаться уязвимыми для всех злоумышленников по всему миру на срок до 60 дней. Этот критерий часто намного легче выполнить, чем рекомендует Google в Rebooting responsible disclosure, поскольку Google рекомендует, чтобы 60-дневный период начинался, когда проект был уведомлен, даже если отчет не является общедоступным.

    No unpatched medium-or-higher vulnerabilities are currently known.

    Current status:

    • zero GitHub Security Advisories
    • zero Dependabot alerts

    CI security scanning:

    • govulncheck
    • osv-scanner
    • Trivy filesystem scanning
      • severity threshold: MEDIUM+
    • CodeQL
    • gosec
    • Semgrep
    • Codacy SAST

    All security checks are currently green on master HEAD.

    Relevant workflows:

    • .github/workflows/ci.yml
    • .github/workflows/osv-scanner.yml
    • .github/workflows/trivy.yml
    • .github/workflows/codeql.yml
    • .github/workflows/gosec.yml
    • .github/workflows/semgrep.yml
    • .github/workflows/codacy.yml


    Проектам СЛЕДУЕТ оперативно исправлять критические уязвимости после сообщения о них. [vulnerabilities_critical_fixed]

    No critical vulnerabilities have been reported against go-derive.

    Current status:

    • GitHub Security Advisories empty
    • project age: 2 days

    The "rapid fix" requirement is currently satisfied vacuously.

    Security response policy:
    https://github.com/amiwrpremium/go-derive/blob/master/SECURITY.md

    Response targets:

    • Critical/High:

      • acknowledgment within 72 hours
      • triage update within 7 days
      • coordinated disclosure with the reporter
    • Medium/Low:

      • acknowledgment within 5 business days
      • best-effort triage thereafter

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


    НЕДОПУСТИМА утечка действующих частных учетных данных (например, рабочий пароль или закрытый ключ), предназначенных для ограничения общего доступа, из публичных репозиториев. [no_leaked_credentials]
    Проект МОЖЕТ пропускать «шаблонные» учетные данные для тестирования и несущественные базы данных, при условии что они не предназначены для ограничения общего доступа.

    No valid private credentials exist in the repository.

    Continuous secret scanning:

    • gitleaks
    • TruffleHog
    • GitGuardian Security Checks
    • Codacy security scan

    Scanning scope:

    • every push
    • full git history

    Relevant workflows:

    • .github/workflows/gitleaks.yml
    • .github/workflows/trufflehog.yml

    Test vectors:

    • pkg/auth/*_test.go
    • use publicly-known Ethereum test keys
    • not usable credentials

    Repository contents:

    • no .env files
    • no credentials.json files

 Анализ 8/8

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


    НЕОБХОДИМО применять по крайней мере, один инструмент анализа статического кода (помимо предупреждений компилятора и "безопасных" режимов языка) к любой предлагаемой основной версии создаваемого ПО до ее выпуска, если есть хотя бы один инструмент на свободном ПО, который реализует этот критерий на выбранном языке. [static_analysis]
    Средство анализа статического кода анализирует программный код (как исходный код, промежуточный код или исполняемый файл), не выполняя его с конкретными входами. Для целей этого критерия предупреждения компилятора и «безопасные» языковые режимы не считаются инструментами анализа статического кода (они обычно избегают глубокого анализа, поскольку скорость имеет жизненно важное значение). Примеры таких статических инструментов анализа кода включают cppcheck (C, C++), статический анализатор Clang (C, C++), SpotBugs (Java), FindBugs (Java; включая FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Анализатор качества Coverity, SonarQube, Codacy и статический анализатор кода HP Enterprise Fortify. Более крупные списки инструментов можно найти в таких местах, как Wikipedia list of tools for static code analysis, OWASP information on static code analysis, NIST list of source code security analyzers и Wheeler's list of static analysis tools. Если для используемого языка(ов) реализации нет доступных инструментов статического анализа на свободном ПО, выберите «неприменимо» (N/A).

    The repository runs nine FLOSS static-analysis tools on every pull request and push to master:

    • CodeQL
    • gosec
    • Semgrep
    • staticcheck
    • golangci-lint
    • Trivy
    • osv-scanner
    • govulncheck
    • Codacy analyzers

    Codacy analyzers include:

    • Revive
    • Markdownlint
    • Remark-lint
    • Checkov

    Release process:

    • releases are created through release-please PRs
    • release PRs pass through the same CI and analysis gates
    • every release is preceded by a complete static-analysis run

    Workflow definitions:
    https://github.com/amiwrpremium/go-derive/tree/master/.github/workflows



    ЖЕЛАТЕЛЬНО включать по крайней мере в один из инструментов статического анализа, используемых для критерия static_analysis, правила или подходы для поиска распространенных уязвимостей в анализируемом языке или среде. [static_analysis_common_vulnerabilities]
    Инструменты статического анализа, специально предназначенные для поиска распространенных уязвимостей, с большей вероятностью найдут их. Тем не менее, использование любых статических инструментов обычно помогает найти какие-то проблемы, поэтому мы предлагаем, но не требуем этого для получения базового значка.

    Three static-analysis tools specifically target common Go vulnerability classes.

    gosec:

    • runs the full Go security ruleset
    • includes checks such as:
      • G101 hardcoded credentials
      • G201–G204 injection risks
      • G302–G306 file permissions
      • G401–G404 weak cryptography
      • G115 integer overflow
    • workflow:
      .github/workflows/gosec.yml

    Semgrep:

    • runs security-focused rule packs:
      • p/security-audit
      • p/golang
      • p/secrets
    • workflow:
      .github/workflows/semgrep.yml

    CodeQL:

    • uses the security-and-quality query pack
    • workflow:
      .github/workflows/codeql.yml

    All analysis runs execute on every push and pull request.



    Все уязвимости со средней и высокой степенью серьезности, обнаруженные при статическом анализе кода, НЕОБХОДИМО своевременно исправлять после их подтверждения. [static_analysis_fixed]
    Уязвимость имеет среднюю и высокую степень серьезности, если ее оценка по CVSS 2.0 - 4 или выше.

    All medium-or-higher severity findings from the static-analysis stack have been fixed at source.

    Examples:

    • gosec G115 integer narrowing

      • fixed in PR #17
      • explicit & 0xFFFF mask added
    • Semgrep / Opengrep math-random-used

      • fixed in PR #17
      • switched from non-CSPRNG randomness to crypto/rand

    Response time:

    • both fixes shipped within ~30 minutes of alert discovery

    Remaining open alerts:

    • low/info-severity false positives only

    Documented examples:

    • Codacy deadcode parser limitations with Go generics
    • remark-lint reference-resolution issues in Contributor Covenant templates

    Tracking document:
    https://github.com/amiwrpremium/go-derive/blob/master/docs/known-tool-issues.md



    ЖЕЛАТЕЛЬНО выполнять анализ статического исходного кода при каждом коммите или по крайней мере ежедневно. [static_analysis_often]

    All static analysis runs on every push and pull request:

    • gosec
    • Semgrep
    • CodeQL
    • Trivy
    • Codacy
    • osv-scanner
    • govulncheck
    • staticcheck
    • golangci-lint

    Analysis frequency:

    • every commit triggers fresh analysis

    Scheduled backstop scans:

    • daily:
      • Trivy
      • OpenSSF Scorecard
    • weekly:
      • CodeQL
      • Semgrep
      • osv-scanner
      • Codacy

    Purpose:

    • catches findings introduced by updated vulnerability datasets or rulesets

    Workflow definitions:
    https://github.com/amiwrpremium/go-derive/tree/master/.github/workflows


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


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

    Two FLOSS dynamic-analysis mechanisms run on every push and pull request, and therefore before every release.

    1. Go race detector
    • executed via:
      go test -race -coverprofile -covermode=atomic
    • configured in:
      .github/workflows/ci.yml
    • instruments runtime memory access to detect data races
    1. Native Go fuzzing
    • 10 fuzz functions across:
      • pkg/auth
      • pkg/types
      • pkg/errors
      • internal/jsonrpc

    Fuzz targets include:

    • signer handling
    • address parsing
    • txhash parsing
    • decimal parsing
    • orderbook parsing
    • millistime parsing
    • API error JSON decoding
    • JSON-RPC decode and notification detection

    Fuzz seed corpora:

    • committed into the repository
    • executed as ordinary tests during CI


    ЖЕЛАТЕЛЬНО регулярно использовать по меньшей мере один динамический инструмент (например, fuzzer или сканер веб-приложения) в сочетании с механизмом для обнаружения проблем безопасности памяти, таких как перезапись буфера, если программное обеспечение, создаваемое проектом, включает части, написанные на небезопасном языке (например, 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 is written entirely in Go, a memory-safe language.

    Memory-safety properties:

    • no C code
    • no C++
    • no cgo usage
    • no unsafe package usage

    Verification:

    • grep -rn '"unsafe"' --include='*.go'
    • grep -rn 'import "C"' --include='*.go'

    Results:

    • both return empty

    Dependencies:

    • all modules in go.sum are pure Go


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

    N/A — the project is written entirely in Go, a memory-safe language.

    Memory-safety properties:

    • no C code
    • no C++
    • no cgo usage
    • no unsafe package usage

    Verification:

    • grep -rn '"unsafe"' --include='*.go'
    • grep -rn 'import "C"' --include='*.go'

    Results:

    • both return empty

    Dependencies:

    • all modules in go.sum are pure Go


    Проект ОБЯЗАН своевременно исправлять все уязвимости средней и выше степени серьезности, обнаруженные при динамическом анализе кода, после их подтверждения. [dynamic_analysis_fixed]
    Если вы не используете динамический анализ кода и, следовательно, не обнаружили уязвимостей таким способом, выберите «неприменимо» (N/A). Степень серьезности уязвимости считается средней или выше, если уязвимость имеет среднюю или выше базовую оценку по Common Vulnerability Scoring System (CVSS). В версиях CVSS с 2.0 по 3.1 это соответствует оценке 4.0 и выше. Проекты могут использовать оценку CVSS опубликованную в любой широко используемой базе данных по уязвимостям (такой как National Vulnerability Database) используя самую новую версию CVSS доступную в этой базе данных. Вместо этого проекты могут сами вычислять серьезность используя последнюю версию CVSS на момент раскрытия уязвимости, если вводные для вычисления раскрываются вместе с публикацией уязвимости.

    No medium-or-higher severity dynamic-analysis findings have been raised.

    Current status:

    • Go race detector passes on every CI build
    • fuzz-test seed corpora execute on every push
    • no crashes or panics detected since:
      • v0.1.0
      • 2026-05-05

    CI matrix:

    • ubuntu
    • macos
    • windows
    • Go 1.25
    • Go 1.26

    There are currently no pending dynamic-analysis fixes.



Эти данные доступны по лицензии Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Это означает, что получатель данных может распространять данные с изменениями или без них, при условии, что получатель данных предоставляет текст данного соглашения вместе с распространяемыми данными. Пожалуйста, укажите в качестве источника AMiWR и участников OpenSSF Best Practices badge.

Владелец анкеты на значок проекта: AMiWR.
2026-05-07 11:45:28 UTC, последнее изменение сделано 2026-05-07 12:40:37 UTC. Последний раз условия для получения значка были выполнены 2026-05-07 12:40:37 UTC.