silken_net

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在您的项目页面上显示您的徽章状态！徽章状态如下所示： 项目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>


这些是黄金级别条款。您还可以查看通过或白银级别条款。

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”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

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

  • 先决条件


    足够获得徽章！

    该项目必须拥有银级徽章。 [achieve_silver]

  • 项目监督


    不足以获得徽章。

    项目必须具有2个或更多的“公交车因子”。 (需要网址) [bus_factor]
    “公交车系数”（又名“卡车因子”）是指最少数量的项目成员，如果突然离开项目（“被公交车撞了”），项目会由于缺乏具备知识的或有能力的人员而暂停。 卡车因子 工具可以对GitHub上的项目进行估计。有关详细信息，请参阅Cosentino等人的评估Git存储库的卡车因子。

    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


    不足以获得徽章。

    该项目必须至少有两个不相关的重要贡献者。 (需要网址) [contributors_unassociated]
    如果同一组织（作为雇员或承包商）支付工作费用，并且组织将从项目的结果中受益，则贡献者是相关联的。如果通过其他组织得到财务补助（例如，源自政府或非政府组织，支付给不同组织的科学补助金不会导致捐助者关联），不视为来自同一组织。重要贡献者定义为过去一年对项目做出了不平凡的贡献。一个重要贡献者的良好指标的例子是：编写至少1,000行代码，贡献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 expression for project]。 [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.


    不足以获得徽章。

    该项目必须清楚地识别新的或临时贡献者可以执行的小型任务。 (需要网址) [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


    足够获得徽章！

    项目必须要求开发人员使用双因素身份验证（2FA）来更改中央存储库或访问敏感数据（如私密漏洞报告）。这种2FA机制可以使用没有密码学机制的方案，如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)


    足够获得徽章！

    项目的双因素身份认证（2FA）应该使用加密机制来防止仿冒。基于短消息服务（SMS）的2FA本身不符合此标准，因为它不被加密。 [secure_2FA]
    满足此条款的2FA机制将是一种基于时间的一次性密码（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 ●

  • 编码标准


    足够获得徽章！

    该项目必须记录其代码检视需求，包括代码检视是如何进行的，必须检查的内容以及哪些是可接纳的内容。 (需要网址) [code_review_standards]
    另请参阅 two_person_review 和contribution_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）。 (需要网址) [build_reproducible]
    可重复的构建意味着多方可以独立地重做从源文件生成信息的过程，并获得每比特完全相同的结果。在某些情况下，这可以通过强制某种排序来解决。 JavaScript开发人员可能会考虑使用npm shrinkwrap和webpack的OccurenceOrderPlugin。 GCC和clang用户可能会发现-frandom-seed选项有用。通常可以通过指定可用于重新构建的特定容器或虚拟机的加密散列来为外部方定义构建环境（包括工具集）。 可重复构建项目具有文档指导如何执行此操作。

    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


  • 自动测试套件


    足够获得徽章！

    测试套件必须以该语言的标准方式进行调用。 (需要网址) [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

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


    足够获得徽章！

    该项目必须实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 (需要网址) [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


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少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


    足够获得徽章！

    如果有至少一个FLOSS工具可以以所选语言度量此条款，该项目的FLOSS自动测试套件必须具有至少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）的攻击


    足够获得徽章！

    项目网站，存储库（如果可通过网络访问）和下载站点（如果单独）必须包括具有非允许值的密钥加固头。 (需要网址) [hardened_site]
    请注意，GitHub是已知满足的。 https://securityheaders.io/ 等网站可以快速查看。主要头加固包含：内容安全策略（CSP），HTTP严格传输安全性（HSTS），X-Content-Type-Options（“nosniff”），X-Frame-Options和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]
    加固机制可能包括HTTP头，如内容安全策略（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 ）或Web应用扫描程序（例如， ZAP 或 w3af ）。在某些情况下， OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款，动态分析工具需要以某种方式改变输入，以寻找各种问题，或者将其作为一个具有至少80％分支覆盖率的自动测试套件。 动态分析维基百科页面和 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞，但这不是必需的。

    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


    足够获得徽章！

    项目应该在其生成的软件中包含许多运行时断言，并在动态分析期间检查这些断言。 [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



该数据可在社区数据许可协议 – 许可性，版本 2.0 (CDLA-Permissive-2.0)下获取。这意味着数据接收方可以共享数据，无论是否经过修改，只要数据接收方在共享数据时提供本协议文本。请注明Alexey Lukin和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Alexey Lukin.
最后更新于 2026-06-24 13:17:00 UTC, 最后更新于 2026-06-25 13:55:07 UTC。 最后在 2026-06-24 17:34:54 UTC 获得通过徽章。