silken_net

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

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

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


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

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

        

 Основы 1/5 ●

  • Общая

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

    Silken Net: a trustless, decentralized D-MRV / Nature-as-a-Service (NaaS) platform for planetary-scale forest-health monitoring. Edge IoT sensors in trees bridge to the Polygon blockchain via a Chainlink oracle, minting Silken Carbon (SCC) and Silken Forest (SFC) tokens from verified biomass-growth telemetry; a Lorenz-attractor homeostasis signal guards against fraud.

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

    Honest TRL: backend TRL 8, firmware TRL 6, bio-anchor TRL 3; multi-zone licensing — see NOTICE.

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


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

    Проект ОБЯЗАН получить серебряный значок. [achieve_silver]

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


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

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

    Unmet — the project currently has a single maintainer, so its bus factor is 1. This is mitigated: the project is fully FLOSS with all code, history, issues and releases public on GitHub (forkable by anyone — see GOVERNANCE.md "Continuity"), so loss of the maintainer does not lose the project, only its stewardship. The maintainer intends to add co-maintainers as the contributor base grows, raising the bus factor to 2+.
    https://github.com/Alexey-Lukin/silken_net/blob/main/GOVERNANCE.md#continuity


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

    Проект ОБЯЗАН иметь как минимум двух несвязанных значительных соавторов. (Требуется URL) [contributors_unassociated]
    Соавторы связаны, если они оплачиваются работой одной и той же организации (как работник или подрядчик), и организация может выиграть от результатов проекта. Финансовые гранты не считаются находящимися в одной организации, если они проходят через другие организации (например, гранты на науку, выплачиваемые различным организациям из общего правительства или источника НПО, не приводят к тому, что вкладчики могут быть связаны). Соавтор считается значительным, если за последний год он(а) внес(ла) заметный вклад в проект. Примерами хороших показателей значительного соавтора являются: написано не менее 1000 строк кода, внесено 50 коммитов или предоставлено не менее 20 страниц документации.

    Unmet — the project currently has a single significant contributor: the founding
    maintainer, who appears in git history under two spellings of the same name
    (Oleksii Lukin / Alexey Lukin, same email). The other commit authors are not
    independent significant contributors — GitHub Copilot and Dependabot are AI/automation
    directed and owned by that maintainer (DCO-signed by the human), and the one other
    human author is well below the significance threshold (a few commits, not ~50
    commits / 1000 LOC / 20 pages). This is the same single-maintainer reality as
    bus_factor. It is mitigated by the project being fully FLOSS and open to outside
    contribution (CONTRIBUTING.md); the maintainer intends to onboard unassociated
    significant contributors as the community grows.
    https://github.com/Alexey-Lukin/silken_net/graphs/contributors


  • Другое


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

    Проект ОБЯЗАН указывать лицензию в каждом исходном файле. Это МОЖЕТ быть сделано путем включения в комментарий рядом с началом каждого файла следующей строки: SPDX-License-Identifier: [SPDX-выражение лицензии для проекта]. [license_per_file]
    Это МОЖЕТ также быть сделано путем указания лицензии на естественном языке. Проект МОЖЕТ также включать стабильный URL-адрес, указывающий на текст лицензии, или полный текст лицензии. Обратите внимание, что критерий license_location требует помещать лицензию проекта в стандартном расположении. См. этот учебник SPDX для получения дополнительных сведений об SPDX-выражениях лицензии. Обратите внимание на связь с критерием copyright_per_file, содержимое для которого обычно предшествует информации о лицензии.

    This is okay because the project's licensing is unambiguous and clearly declared at
    the repository level, even though it is not repeated as a per-file header. The repo
    ships explicit per-zone LICENSE files — AGPL-3.0-or-later (code), CERN-OHL-S-2.0
    (hardware), CC-BY-SA-4.0 (documentation) — plus a NOTICE file that maps each zone to
    its license and lists third-party exceptions, and the licensing strategy is documented
    in docs/08_01. The Solidity contracts already carry a per-file SPDX-License-Identifier
    (required by solc). So there is no licensing uncertainty for any file; the only gap is
    the convenience of an in-file SPDX header in the Ruby/C/Python sources, which is a
    deferred, scriptable enhancement rather than a licensing ambiguity. This gold-level
    item is in any case gated by the project's single-maintainer bus factor.
    https://github.com/Alexey-Lukin/silken_net/blob/main/NOTICE


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

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


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

    Хранилище проектного исходного кода ОБЯЗАНО использовать типовое ПО для распределенного управления версиями (например, git или mercurial). [repo_distributed]
    Не требуется именно git, и проекты могут использовать централизованное программное обеспечение для управления версиями (например, Subversion) с обоснованием.

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


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

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

    This is okay because the project is currently a single-maintainer effort with no
    active external-contributor pipeline yet, so there is no backlog of newcomer-tagged
    small tasks; the internal roadmap (docs/00_07) tracks domain-expert work rather than
    casual-contributor microtasks, and there are essentially no open issues. The project
    is nonetheless open to contribution — CONTRIBUTING.md documents the fork → branch → PR
    flow and the per-domain checks — so a newcomer can contribute; specific "good first
    issue"-tagged tasks simply have not been curated. The maintainer intends to label
    good-first-issues as the contributor base grows (the same single-maintainer reality
    behind bus_factor, which independently gates this gold level).
    https://github.com/Alexey-Lukin/silken_net/blob/main/CONTRIBUTING.md


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

    Проект ОБЯЗАН требовать двухфакторной аутентификации (ДФА) от разработчиков для изменения центрального хранилища или доступа к конфиденциальным данным (например, приватным отчетам об уязвимостях). Этот механизм ДФА МОЖЕТ использовать механизмы без криптографической защиты, такие как SMS, хотя это не рекомендуется. [require_2FA]

    Changes to the central repository require the maintainer's GitHub account, which has two-factor authentication enabled. GitHub has also mandated 2FA for all code contributors since its March 2023 rollout (accounts without it are restricted). As a personal (non-organization) repository, 2FA is enforced at the GitHub-account level rather than via an org-wide policy. (OSPS AC-01.01)


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

    При двухфакторной аутентификации (ДФА) проекту СЛЕДУЕТ использовать криптографические механизмы для предотвращения имперсонации. ДФА на основе службы коротких сообщений (SMS) сама по себе НЕ соответствует этому критерию, поскольку короткие сообщения не шифруются. [secure_2FA]
    Механизм ДФА, который соответствует этому критерию, может быть приложением для генерации временных одноразовых паролей (Time-based One-Time Password, TOTP), которое автоматически генерирует код аутентификации, меняющийся через определенный промежуток времени. Обратите внимание, что GitHub поддерживает TOTP.

    The maintainer's GitHub two-factor authentication uses a Time-based One-Time Password (TOTP) authenticator app, a cryptographic mechanism — not SMS. GitHub supports TOTP and WebAuthn security keys / passkeys for 2FA. (OSPS AC-01.02)


 Качество 6/7 ●

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


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

    Проект ОБЯЗАН документировать свои требования по ревью кода, в том числе, как проводится ревью кода, что необходимо проверять и что необходимо для приемлемости кода. (Требуется URL) [code_review_standards]
    См. также критерии two_person_review и contrib_requirements.

    Met. The project documents its code-review / acceptance requirements in CONTRIBUTING.md
    and the pull-request template:

    • How review is conducted: changes go through a fork → branch → pull-request flow; CI
      must be green and a CODEOWNERS maintainer reviews the PR before it is merged
      (CONTRIBUTING.md, "Contribution process").
    • What must be checked / what is acceptable: CONTRIBUTING.md "Requirements for acceptable
      contributions" lists the per-domain checks a change must pass (RuboCop + RSpec +
      Brakeman + bundler-audit for Ruby; Ruff for Python; -Wall -Wextra -Wpedantic + cppcheck
      for firmware C; forge build/test for Solidity), the enforced style guides, the
      "add/update automated tests for new functionality" policy, and the SSOT doc-update
      requirement; the PR template repeats this as a per-PR checklist (conventional-commit
      title, CI passed + Docs passed green, SSOT updated). Solidity test conventions are
      documented in CLAUDE.md §8.
      https://github.com/Alexey-Lukin/silken_net/blob/main/CONTRIBUTING.md#requirements-for-acceptable-contributions
      https://github.com/Alexey-Lukin/silken_net/blob/main/.github/pull_request_template.md

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

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

    Unmet — the project currently has a single maintainer, so proposed modifications are
    not reviewed before release by a person other than the author; the author and the only
    available reviewer are the same person. This is the same single-maintainer reality as
    bus_factor. It is mitigated by strong automated gates that every change must pass before
    it lands: CI (RuboCop, RSpec with a 99%-line/95%-branch coverage gate, Brakeman,
    bundler-audit, Ruff, the firmware host suite under AddressSanitizer + UndefinedBehavior-
    Sanitizer, Foundry contract tests, Slither, and CodeQL) plus the SSOT documentation gate
    — which catch many of the issue classes a second human reviewer would look for. The
    maintainer intends to require independent second-person review once co-maintainers join.
    https://github.com/Alexey-Lukin/silken_net/blob/main/CONTRIBUTING.md


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


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

    Проект ОБЯЗАН обеспечивать воспроизводимую сборку. Если сборка не требуется (например, в случае языков сценариев, где исходный код используется непосредственно вместо компиляции), выберите «N/A». (Требуется URL) [build_reproducible]
    Воспроизводимая сборка означает, что несколько сторон могут независимо повторить процесс генерации информации из исходных файлов и получить аналогичный результат с точностью до бита. В некоторых случаях воспроизводимости можно достичь путем принудительного выставления окружения. Разработчики JavaScript могут рассмотреть возможность использования npm shrinkwrap и webpack OccurenceOrderPlugin. Пользователи GCC и clang могут найти полезной опцию -frandom-seed. Среда сборки (включая набор инструментов) часто может быть определена для внешних сторон путём указания криптографической суммы (hash) для конкретного контейнера или виртуальной машины, которые они могут использовать для пересборки. В проекте Reproducible Builds есть документация о том, как это сделать.

    Met. The project's compiled, security-critical artifact — the Solidity smart-contract
    bytecode — has a reproducible build: contracts/foundry.toml pins the toolchain
    (solc_version 0.8.35, evm_version cancun, optimizer on / 200 runs) and solc is
    deterministic, so any party that runs forge build against the committed source +
    foundry.toml gets the same bytecode bit-for-bit. This is independently verifiable and is
    exactly what lets anyone confirm the deployed on-chain bytecode matches the source.

    Build inputs across the rest of the stack are fully pinned (the prerequisite for
    reproducible packaging): the Docker base image is pinned by digest
    (ruby:4.0.5-slim@sha256:…) and dependencies are locked (Gemfile.lock,
    contracts/package-lock.json, tools/in_silico/conda-lock.yml); the released container also
    carries a Sigstore SLSA build-provenance attestation recording how it was produced (see
    SECURITY.md). The Ruby (Rails) and Python tiers are interpreted — source used directly,
    not compiled — the criterion's N/A case for those tiers.
    https://github.com/Alexey-Lukin/silken_net/blob/main/contracts/foundry.toml
    https://github.com/Alexey-Lukin/silken_net/blob/main/Dockerfile


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


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

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

    Met. The test suites are invocable the standard way for each language, as documented
    in CONTRIBUTING.md ("Requirements for acceptable contributions"):


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

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

    GitHub Actions CI runs the test + lint suites on every push and pull request: RSpec, Brakeman, RuboCop, Ruff, firmware host tests, and forge tests.
    https://github.com/Alexey-Lukin/silken_net/blob/main/.github/workflows/ci.yml


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

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

    Met. The Ruby/Rails backend — the bulk of the codebase — is measured by SimpleCov (FLOSS,
    with branch coverage enabled), and the full CI suite enforces a hard gate of
    minimum_coverage line: 99, branch: 95 (spec/spec_helper.rb): the build fails below 99%
    statement coverage, comfortably above the 90% gold bar. A per-group tripwire additionally
    floors Services/Workers/Models at ~99% line so no single area can erode while the global
    average holds. The other languages are measured with FLOSS coverage tools too: the
    firmware C host suite via gcov/lcov (make -C firmware/test coverage) and the Solidity
    contracts via forge coverage --report lcov (→ Codecov). Coverage policy: docs/04_06 §B.
    https://github.com/Alexey-Lukin/silken_net/blob/main/spec/spec_helper.rb


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

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

    Met. SimpleCov (FLOSS) runs with branch coverage enabled (enable_coverage :branch), and
    the full CI suite enforces a hard gate of minimum_coverage line: 99, branch: 95
    (spec/spec_helper.rb): the build fails below 95% branch coverage, comfortably above the
    80% bar. Per-group branch floors additionally hold Services ≥97%, Workers ≥96%, Models
    ≥99%, so no single area can erode while the global average holds (branch is the tighter
    signal; line is ~99.9% everywhere).
    https://github.com/Alexey-Lukin/silken_net/blob/main/spec/spec_helper.rb


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

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

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

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

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

    Met (SHOULD). All IP/web network communications use TLS by default and no insecure
    protocol is enabled:

    • The web app and API enforce HTTPS in production (config.force_ssl = true) with
      HSTS (1 year, includeSubdomains, preload) and assume_ssl behind the TLS-terminating
      Kamal proxy (Let's Encrypt, TLS 1.2/1.3). HTTP is redirected to HTTPS.
    • All outbound calls use HTTPS — chain RPC (Alchemy/Infura), Chainlink Functions,
      IoTeX and peaq endpoints — with default certificate verification (no VERIFY_NONE).
    • A scan of the code finds no FTP, telnet, SSLv3/earlier, SSHv1, or plain-HTTP
      endpoints.
      For the constrained IoT radio link (Soldier->Queen LoRa, Queen->Rails CoAP) TLS/DTLS
      is not feasible on a tens-of-bytes LoRa frame, so confidentiality and integrity are
      provided at the application layer with AES: AES-128-CCM (authenticated; the
      LoRaWAN/Zigbee/Thread/BLE golden standard for constrained IoT) on the LoRa link and
      AES-256-CBC with a per-message random IV on the CoAP backhaul. This design — and why
      heavier schemes such as Kyber do not fit the radio MTU — is documented in docs/03_05.
      The transitional AES-128-ECB LoRa mode is documented and is migrating to AES-128-CCM.
      https://github.com/Alexey-Lukin/silken_net/blob/main/config/environments/production.rb
      https://github.com/Alexey-Lukin/silken_net/blob/main/docs/03_05_Hardware_Symmetric_Crypto_and_Security.md

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

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

    Met (SHOULD). The project uses TLS and supports TLS 1.2+ everywhere; nothing is
    configured to allow TLS 1.1 or earlier:

    • Inbound HTTPS is terminated by the Kamal proxy with automatic Let's Encrypt
      certificates (config/deploy.yml, proxy ssl: true); the proxy (Go crypto/tls)
      negotiates TLS 1.2/1.3 and does not offer TLS 1.0/1.1. The Rails app enforces it
      with config.force_ssl = true and HSTS (1 year, includeSubdomains, preload) in
      production.rb, so HTTP is redirected to HTTPS.
    • Outbound HTTPS (chain RPC, Chainlink, IoTeX, peaq) is made by Ruby 4.0.5 on
      OpenSSL 3.6.2, which negotiates TLS 1.2/1.3 by default and has TLS 1.0/1.1
      disabled; no client sets a lower ssl_version/min_version.
      No SSLv2/SSLv3 or TLS 1.1-or-earlier is configured or supported anywhere in the stack.
      https://github.com/Alexey-Lukin/silken_net/blob/main/config/environments/production.rb
      https://github.com/Alexey-Lukin/silken_net/blob/main/config/deploy.yml

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


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

    Веб-сайт проекта, репозиторий (если он доступен через Интернет) и сайт загрузки (если он существует отдельно) ОБЯЗАНЫ использовать упрочняющие безопасность (hardening) заголовки с неразрешающими значениями. (Требуется URL) [hardened_site]
    Обратите внимание, что GitHub отвечает этому критерию. Такие сайты как https://securityheaders.io/ могут быстро проверить использование. Ключевыми заголовками для упрочнения являются: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (выставленный в «nosniff»), X-Frame-Options и X-XSS-Protection. Статические веб-сайты без возможности входа в систему через веб-страницы могут опускать упрочняющие HTTP-заголовки CSP и X-XSS-Protection, поскольку в этом случае эти заголовки менее эффективны.

    Met. The project's web presence is its GitHub repository
    (github.com/Alexey-Lukin/silken_net); GitHub is explicitly noted by this criterion as
    meeting the hardening-header requirement (CSP, HSTS, X-Content-Type-Options: nosniff,
    X-Frame-Options). Releases are distributed via GitHub Releases + GHCR (also GitHub), so
    the download surface is covered too, and there is no separate project website. The
    project's own application is additionally configured to emit all four headers with
    nonpermissive values when deployed: a strict CSP with a per-request nonce
    (config/initializers/content_security_policy.rb), HSTS with preload + config.force_ssl
    (config/environments/production.rb), and X-Content-Type-Options: nosniff +
    X-Frame-Options: DENY (config/initializers/security_headers.rb).
    https://github.com/Alexey-Lukin/silken_net


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


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

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

    Met. A security review was performed and is documented in
    docs/SECURITY_ASSURANCE_CASE.md (2026-06-25). It is a human-authored structured review
    that explicitly considers the security requirements (the top-level security claims and
    the OWASP Top 10 countermeasure analysis) and the security boundary (an enumeration of
    every trust boundary across the Soldier→Queen→Rails→chain pipeline and the guard
    enforcing each), plus a threat model (assets, actors, attack surfaces) and an honest
    residual-risk section. It is supported by static and dynamic tooling (Brakeman, Slither,
    CodeQL, cppcheck, ASan/UBSan) but goes beyond them with human design analysis (the
    trust-boundary and minting/slashing-gate reasoning that tools cannot detect). It is
    complemented by the ongoing SEC.* hardening audits tracked in docs/00_07.
    https://github.com/Alexey-Lukin/silken_net/blob/main/docs/SECURITY_ASSURANCE_CASE.md


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

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

    Met (SHOULD). Hardening mechanisms are applied on both the web and firmware sides.

    Web (Rails — the network-facing attack surface):

    • A strict Content-Security-Policy (config/initializers/content_security_policy.rb):
      default_src/base_uri/form_action 'self', frame_ancestors 'none', frame_src 'none',
      object_src 'none', and a per-request nonce for inline scripts (no 'unsafe-inline'
      on script-src).
    • A full security-header set (config/initializers/security_headers.rb): X-Frame-Options
      DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin,
      Cross-Origin-Opener-Policy / Cross-Origin-Resource-Policy same-origin, a restrictive
      Permissions-Policy, and X-XSS-Protection 0 (disables the legacy exploitable filter).
    • HSTS with preload (1 year, includeSubdomains) + config.force_ssl; session cookies are
      httponly + secure + same_site:lax.

    Firmware C (a memory-unsafe language → compiler hardening):

    • The entire host test suite is compiled and executed under AddressSanitizer +
      UndefinedBehaviorSanitizer (-fsanitize=address,undefined -fno-sanitize-recover=all) on
      every CI run, so undefined behavior, buffer overflows and use-after-free abort the build
      before release — the criterion's "compiler flags to eliminate undefined behavior"
      example. The host build also honors -fstack-protector-strong / -D_FORTIFY_SOURCE / RELRO.

    https://github.com/Alexey-Lukin/silken_net/blob/main/config/initializers/content_security_policy.rb
    https://github.com/Alexey-Lukin/silken_net/blob/main/firmware/test/Makefile


 Анализ 2/2 ●

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


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

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

    The smart contracts are dynamically analysed by Foundry property/fuzz testing: 11 testFuzz_ properties (mint, slash, setParameter, permit, storeStateRoot, …), each run with 512 randomized input iterations (foundry.toml [fuzz] runs=512) on every CI run, plus invariant testing. This varies inputs to look for failures, satisfying the criterion. The Ruby backend additionally runs a comprehensive RSpec suite in CI.
    https://github.com/Alexey-Lukin/silken_net/blob/main/.github/workflows/solidity_audit.yml


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

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

    Assertions are heavily enabled during dynamic analysis. The firmware host-test build compiles without -DNDEBUG (so C assert() and the 1833 host-test assertions are active), and the Foundry contract suite checks 4 protocol invariants (solvency, supply accounting, total-supply-within-cap, voting-power-matches-supply) plus ~200 assertEq/assertTrue assertions during fuzzing. These assertions are test-only — not compiled into the firmware production binary or the deployed contracts.
    https://github.com/Alexey-Lukin/silken_net/blob/main/firmware/test/Makefile



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

Владелец анкеты на значок проекта: Alexey Lukin.
2026-06-24 13:17:00 UTC, последнее изменение сделано 2026-06-25 13:55:07 UTC. Последний раз условия для получения значка были выполнены 2026-06-24 17:34:54 UTC.