silken_net

Miradi inayofuata mazoea bora hapa chini inaweza kujihakikisha kwa hiari na kuonyesha kuwa wamepata nishani ya mazoea bora ya Open Source Security Foundation (OpenSSF).

Hakuna seti ya mazoea yawezayo kuhakikisha kuwa programu haitakuwa na kasoro au udhaifu; hata mbinu rasmi zinaweza kushindwa ikiwa vipimo au dhana ni sahihi. Wala hakuna seti ya mazoea yawezayo kuhakikisha kuwa mradi utaendelea kuwa na jamii ya maendeleo yenye afya na inayofanya kazi vizuri. Hata hivyo, kufuata mazoea bora kunaweza kusaidia kuboresha matokeo ya miradi. Kwa mfano, baadhi ya mazoea huwezesha ukaguzi wa watu wengi kabla ya kutolewa, ambayo inaweza kusaidia kupata udhaifu wa kiufundi ambao vinginevyo ni vigumu kupata na kusaidia kujenga uaminifu na hamu ya mwingiliano wa kurudia kati ya wasanidi programu kutoka makampuni tofauti. Ili kupata nishani, vigezo vyote vya LAZIMA na LAZIMA WALA USIWAHI lazima vifuatwe, vigezo vyote vya INAPASWA lazima vifuatwe AU visivyo fufufutiliana na thibitisho, na vigezo vyote vya PENDEKEZA lazima vifuatwe AU visivyo fufufutiliana (tunataka vifikiwe angalau). Ikiwa unataka kuingiza maandishi ya thibitisho kama maoni ya jumla, badala ya kuwa maelezo ya busara kwamba hali ni inakubaliwa, anza kifungu cha maandishi na '//' ikifuatiwa na nafasi. Maoni ni karibu kupitia tovuti ya GitHub kama masuala au maombi ya kuvuta Kuna pia orodha ya barua pepe kwa majadiliano ya jumla.

Tunafuraha kutoa habari katika lugha nyingi, hata hivyo, ikiwa kuna mgongano au kutokuwa na usawa kati ya tafsiri, toleo la Kiingereza ni toleo lenye mamlaka.
Ikiwa huu ni mradi wako, tafadhali onyesha hadhi ya nishani yako kwenye ukurasa wa mradi wako! Hadhi ya nishani inaonekana kama hii: Kiwango cha nishani kwa mradi 13358 ni silver Hapa ni jinsi ya kuiweka:
Unaweza kuonyesha hali ya nishani yako kwa kuweka hii katika faili yako ya markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13358/badge)](https://www.bestpractices.dev/projects/13358)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/13358"><img src="https://www.bestpractices.dev/projects/13358/badge"></a>


Hizi ni vigezo vya kiwango cha Dhahabu. Unaweza pia kuangalia vigezo vya kiwango cha Kupita au Fedha.

Baseline Series: Kiwango cha Msingi 1 Kiwango cha Msingi 2 Kiwango cha Msingi 3

        

 Misingi 1/5 ●

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    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.

    Tafadhali tumia muundo wa maneno ya leseni ya SPDX; mifano ni pamoja na "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", na "(BSD-2-Clause OR Ruby)". Usitumie alama za nukuu za moja au mbili.
    Ikiwa kuna lugha zaidi ya moja, ziorodhe kama thamani zilizotengwa kwa koma (nafasi ni za hiari) na ziorodhe kuanzia iliyotumiwa zaidi hadi iliyotumiwa kidogo. Ikiwa kuna orodha ndefu, tafadhali orodhesha angalau tatu za kawaida zaidi. Ikiwa hakuna lugha (k.m., huu ni mradi wa nyaraka tu au wa majaribio tu), tumia herufi moja "-". Tafadhali tumia herufi kubwa za kawaida kwa kila lugha, k.m., "JavaScript".
    Common Platform Enumeration (CPE) ni mpango wa kuweka majina yenye muundo kwa mifumo ya teknolojia ya habari, programu, na vifurushi. Inatumika katika mifumo na hifadhidata nyingi wakati wa kuripoti udhaifu.

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

  • Mahitaji ya awali


    Ya kutosha kwa nishani!

    Mradi LAZIMA ufikie kiwango cha nishani ya fedha. [achieve_silver]

  • Usimamizi wa mradi


    Si ya kutosha kwa nishani.

    Mradi LAZIMA uwe na "bus factor" ya 2 au zaidi. (URL inahitajika) [bus_factor]
    "Bus factor" (pia inajulikana kama "truck factor") ni idadi ya chini ya washiriki wa mradi ambao wanapaswa kutoweka ghafla kutoka kwenye mradi ("kupigwa na basi") kabla ya mradi kusimama kwa sababu ya ukosefu wa wafanyakazi wenye elimu au wenye uwezo. Zana ya truck-factor inaweza kukadiria hii kwa miradi kwenye GitHub. Kwa maelezo zaidi, angalia Kutathmini Bus Factor ya Hifadhi za Git na Cosentino et al.

    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


    Si ya kutosha kwa nishani.

    Mradi LAZIMA uwe na angalau wachangiaji wawili wasiohusika. (URL inahitajika) [contributors_unassociated]
    Wachangiaji wanahusianishwa ikiwa wanalipwa kufanya kazi na shirika moja (kama mwajiriwa au mkandarasi) na shirika lile linapata faida kutokana na matokeo ya mradi. Misaada ya kifedha haihesabiwi kuwa kutoka shirika sawa ikiwa inapitia mashirika mengine (k.m., misaada ya sayansi inayolipwa kwa mashirika tofauti kutoka serikali ya kawaida au chanzo cha NGO haifanyi wachangiaji kuhusianishwa). Mtu ni mchangiaji muhimu ikiwa amefanya michango isiyojulikana kwa mradi katika mwaka uliopita. Mifano ya viashiria vizuri vya mchangiaji muhimu ni: ameandika angalau mistari 1,000 ya msimbo, amechangia commits 50, au amechangia angalau kurasa 20 za nyaraka.

    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


  • Mengine


    Si ya kutosha kwa nishani.

    Mradi LAZIMA ujumuishe tamko la leseni katika kila faili ya chanzo. Hii YAWEZA kufanyika kwa kujumuisha yafuatayo ndani ya maoni karibu na mwanzo wa kila faili: SPDX-License-Identifier: [maneno ya leseni ya SPDX kwa mradi]. [license_per_file]
    Hii pia YAWEZA kufanyika kwa kujumuisha tamko katika lugha asilia ikitambulisha leseni. Mradi pia YAWEZA kujumuisha URL thabiti inayoelekeza kwenye maandishi ya leseni, au maandishi kamili ya leseni. Kumbuka kwamba kigezo cha license_location kinahitaji leseni ya mradi iwe mahali pa kawaida. Angalia mafunzo haya ya SPDX kwa maelezo zaidi kuhusu maneno ya leseni ya SPDX. Kumbuka uhusiano na copyright_per_file, ambayo yaliyomo yake kwa kawaida yangetangulia maelezo ya leseni.

    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


 Udhibiti wa Mabadiliko 3/4 ●

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    Ya kutosha kwa nishani!

    Hifadhi ya chanzo ya mradi LAZIMA itumie programu ya kawaida ya kudhibiti toleo linalosambazwa (k.m., git au mercurial). [repo_distributed]
    Git haihitajiki kihususa na miradi inaweza kutumia programu ya udhibiti wa toleo iliyokusanyika (kama subversion) na sababu.

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


    Si ya kutosha kwa nishani.

    Mradi LAZIMA utambulishe kazi ndogo ambazo zinaweza kufanywa na wachangiaji wapya au wa mara kwa mara. (URL inahitajika) [small_tasks]
    Utambulisho huu kwa kawaida unafanyika kwa kuweka alama masuala yaliyochaguliwa katika kifuatiliaji cha masuala kwa lebo moja au zaidi ambazo mradi unatumia kwa madhumuni hayo, k.m., up-for-grabs, first-timers-only, "Marekebisho madogo", microtask, au IdealFirstBug. Kazi hizi mpya hazihitaji kujumuisha kuongeza utendaji; zinaweza kuwa kuboresha nyaraka, kuongeza hali za majaribio, au chochote kingine kinachosaidia mradi na kusaidia mchangiaji kuelewa zaidi kuhusu mradi.

    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


    Ya kutosha kwa nishani!

    Mradi LAZIMA uhitaji uthibitishaji wa mambo mawili (2FA) kwa wasanidi programu ili kubadilisha hifadhi ya kati au kupata data nyeti (kama ripoti za faragha za udhaifu). Utaratibu huu wa 2FA YAWEZA kutumia taratibu bila taratibu za usimbuaji kama SMS, ingawa hii hairuhusiwi. [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)


    Ya kutosha kwa nishani!

    Uthibitishaji wa mambo mawili (2FA) ya mradi INAPASWA kutumia taratibu za usimbuaji ili kuzuia ujigeuzi. Uthibitishaji wa 2FA unaotegemea Huduma ya Ujumbe Mfupi (SMS), peke yake, HAUKIDHI kigezo hiki, kwa kuwa haufichui. [secure_2FA]
    Utaratibu wa 2FA unaokidhi kigezo hiki unaweza kuwa programu ya Nywila ya Mara Moja Inayotegemea Muda (TOTP) ambayo inazalisha kiotomatiki msimbo wa uthibitishaji unaobadilika baada ya muda fulani. Kumbuka kwamba GitHub inasaidia 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)


 Ubora 6/7 ●

  • Viwango vya msimbo


    Ya kutosha kwa nishani!

    Mradi LAZIMA uandike mahitaji yake ya kukagua msimbo, pamoja na jinsi ukaguzi wa nambari unafanywa, nini lazima ichunguzwe, na nini kinachohitajika ili ikubalike. (URL inahitajika) [code_review_standards]
    Angalia pia two_person_review na 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

    Si ya kutosha kwa nishani.

    Mradi LAZIMA uwe na angalau 50% ya marekebisho yote yaliyopendekezwa kupitishwa kabla ya kutolewa na mtu mwingine isipokuwa mwandishi, ili kuamua ikiwa ni marekebisho ya manufaa na huru ya masuala yaliyojulikana ambayo yangepingana na ujumuishaji wake [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


  • Mfumo wa ujenzi unaofanya kazi


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na ujenzi unaorudiwa. Ikiwa hakuna ujenzi unaofanyika (k.m., lugha za uandishi ambapo msimbo wa chanzo unatumika moja kwa moja badala ya kukusanywa), chagua "haihusiki" (N/A). (URL inahitajika) [build_reproducible]
    Ujenzi unaorudiwa unamaanisha kwamba pande nyingi zinaweza kwa uhuru kurudia mchakato wa kuzalisha taarifa kutoka faili za chanzo na kupata matokeo sawa ya biti-kwa-biti. Katika hali fulani, hii inaweza kutatuliwa kwa kulazimisha mpangilio fulani wa aina. Wasanidi wa JavaScript wanaweza kuzingatia kutumia npm shrinkwrap na webpack OccurrenceOrderPlugin. Watumiaji wa GCC na clang wanaweza kupata chaguo la -frandom-seed kuwa na manufaa. Mazingira ya ujenzi (ikijumuisha zana) kwa kawaida yanaweza kufafanuliwa kwa pande za nje kwa kubainisha hash ya usimbuaji ya chombo maalum au mashine ya kawaida ambayo wanaweza kutumia kwa kujenga upya. Mradi wa majengo yanayorudiwa una nyaraka za jinsi ya kufanya hivi.

    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


  • Seti ya majaribio otomatiki


    Ya kutosha kwa nishani!

    Seti ya majaribio LAZIMA iweze kuitwa kwa njia ya kawaida kwa lugha hiyo. (URL inahitajika) [test_invocation]
    Kwa mfano, "make check", "mvn test", au "rake test" (Ruby).

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


    Ya kutosha kwa nishani!

    Mradi LAZIMA utekeleze ujumuishaji wa kuendelea, ambapo msimbo mpya au uliobadilishwa unajumuishwa mara kwa mara katika hifadhi ya msimbo ya kati na majaribio ya kiotomatiki yanafanywa kwenye matokeo. (URL inahitajika) [test_continuous_integration]
    Katika hali nyingi hii inamaanisha kwamba kila msanidi programu anayefanya kazi kikamilifu kwenye mradi anajumuisha angalau kila siku.

    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


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na seti ya majaribio ya kiotomatiki ya FLOSS ambayo inatoa angalau 90% ya ufikio wa tamko ikiwa kuna angalau zana moja ya FLOSS ambayo inaweza kupima kigezo hiki katika lugha iliyochaguliwa. [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


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na seti ya jaribio zilizofanywa kiotomatiki za FLOSS ambazo zinatoa angalau asilimia 80 ya uangaliaji wa tawi ikiwa kuna angalau zana moja ya FLOSS inayoweza kupima kigezo hiki katika lugha iliyochaguliwa. [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


 Usalama 5/5 ●

  • Tumia mazoea mazuri ya msingi ya usimbuaji

    Kumbuka kwamba programu fulani haihitaji kutumia taratibu za usimbuaji. Ikiwa mradi wako unazalisha programu ambayo (1) inajumuisha, inaamilisha, au inafanya usimbuaji kuwa hai, na (2) inaweza kutolewa kutoka Marekani (US) kwenda nje ya Marekani au kwa raia asiye wa Marekani, inaweza kuwa ni lazima kisheria kuchukua hatua chache za ziada. Kawaida hii inahusisha tu kutuma barua pepe. Kwa maelezo zaidi, tazama sehemu ya usimbuaji ya Kuelewa Teknolojia ya Chanzo Wazi & Udhibiti wa Usafirishaji wa Marekani.

    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA isaidie itifaki salama kwa mawasiliano yake yote ya mtandao, kama vile SSHv2 au zaidi, TLS1.2 au zaidi (HTTPS), IPsec, SFTP, na SNMPv3. Itifaki zisizo salama kama vile FTP, HTTP, telnet, SSLv3 au mapema zaidi, na SSHv1 LAZIMA zizimwe kwa chaguo-msingi, na kuzimwa tu ikiwa mtumiaji anaisanidi mahususi. Ikiwa programu iliyozalishwa na mradi haiesaidii mawasiliano ya mtandao, chagua "haihusiki" (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

    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA, ikiwa inasaidia au inatumia TLS, isaidie angalau toleo la TLS 1.2. Kumbuka kwamba kabla ya TLS kuitwa SSL. Ikiwa programu haitumii TLS, chagua "haihusiki" (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

  • Utoaji salama dhidi ya mashambulizi ya mtu-katikati (MITM)


    Ya kutosha kwa nishani!

    Tovuti ya mradi, hifadhi (ikiwa inapatikana kupitia wavuti), na tovuti ya kupakua (ikiwa ni tofauti) LAZIMA ijumuishe vichwa muhimu vya kuimarisha na thamani zisizo na ruhusa. (URL inahitajika) [hardened_site]
    Kumbuka kwamba GitHub na GitLab zinajulikana kukidhi hii. Tovuti kama vile https://securityheaders.com/ zinaweza kuangalia hii haraka. Vichwa muhimu vya kuimarisha ni: Sera ya Usalama wa Maudhui (CSP), Usalama wa Usafiri wa HTTP Mkali (HSTS), X-Content-Type-Options (kama "nosniff"), na X-Frame-Options. Tovuti za wavuti zilizo za tuli kabisa bila uwezo wa kuingia kupitia kurasa za wavuti zinaweza kuacha baadhi ya vichwa vya kuimarisha na hatari ndogo, lakini hakuna njia ya kuaminika ya kugundua tovuti kama hizo, kwa hivyo tunahitaji vichwa hivi hata kama ni tovuti za tuli kabisa.

    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


  • Masuala mengine ya usalama


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe umefanya ukaguzi wa usalama ndani ya miaka 5 iliyopita. Ukaguzi huu LAZIMA uzingatie mahitaji ya usalama na mpaka wa usalama. [security_review]
    Hii YAWEZA kufanywa na wanachama wa mradi na/au tathmini huru. Tathmini hii YAWEZA kusaidiwa na zana za uchambuzi za tuli na zenye nguvu, lakini lazima pia kuwe na ukaguzi wa binadamu ili kutambua matatizo (hasa katika muundo) ambayo zana haziwezi kugundua.

    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


    Ya kutosha kwa nishani!

    Taratibu za kuimarisha LAZIMA zitumike katika programu iliyozalishwa na mradi ili kasoro za programu ziwe na uwezekano mdogo wa kusababisha udhaifu wa usalama. (URL inahitajika) [hardening]
    Taratibu za kuimarisha zinaweza kujumuisha vichwa vya HTTP kama Sera ya Usalama wa Maudhui (CSP), bendera za mkusanyaji ili kupunguza mashambulizi (kama vile -fstack-protector), au bendera za mkusanyaji ili kuondoa tabia isiyofafanuliwa. Kwa madhumuni yetu upendeleo mdogo hauhesabiwi kuwa utaratibu wa kuimarisha (upendeleo mdogo ni muhimu, lakini tofauti).

    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


 Uchanganuzi 2/2 ●

  • Uchambuzi wa msimbo wa nguvu za ziada


    Ya kutosha kwa nishani!

    Mradi LAZIMA utumie angalau zana moja ya uchambuzi wenye nguvu kwa toleo lolote lililopendekezwa kuu la uzalishaji wa programu iliyozalishwa na mradi kabla ya kutolewa kwake. [dynamic_analysis]
    Zana ya uchambuzi wa nguvu inachunguza programu kwa kuitekeleza na ingizo maalum. Kwa mfano, mradi YAWEZA kutumia zana ya fuzzing (k.m., American Fuzzy Lop) au kitafutaji cha programu ya wavuti (k.m., OWASP ZAP au w3af). Katika hali fulani mradi wa OSS-Fuzz unaweza kuwa tayari kutumia majaribio ya fuzz kwenye mradi wako. Kwa madhumuni ya kigezo hiki zana ya uchambuzi wa nguvu inahitaji kubadilisha ingizo kwa njia fulani kutafuta aina mbalimbali za matatizo au kuwa seti kiotomatiki ya majaribio yenye angalau asilimia 80 ya ukaguzi wa tawi. Ukurasa wa Wikipedia kuhusu uchambuzi wa nguvu na ukurasa wa OWASP kuhusu fuzzing hutambulisha baadhi ya zana za uchambuzi wa nguvu. Zana za uchambuzi ZINAWEZA kuzingatia kutafuta udhaifu wa usalama, lakini hii haihitajiki.

    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


    Ya kutosha kwa nishani!

    Mradi INAPASWA kujumuisha madai mengi ya muda wa kutekeleza katika programu inayozalisha na kuangalia madai hayo wakati wa uchambuzi wenye nguvu. [dynamic_analysis_enable_assertions]
    Kigezo hiki hakipendekezi kuwezesha madai wakati wa uzalishaji; hilo ni kabisa kwa mradi na watumiaji wake kuamua. Lengo la kigezo hiki ni badala yake kuboresha ugunduzaji wa hitilafu wakati wa uchambuzi wa nguvu kabla ya kusambazwa. Kuwezesha madai katika matumizi ya uzalishaji ni tofauti kabisa na kuwezesha madai wakati wa uchambuzi wa nguvu (kama vile majaribio). Katika hali fulani kuwezesha madai katika matumizi ya uzalishaji ni busara sana (hasa katika vipengele vya uadilifu wa juu). Kuna hoja nyingi dhidi ya kuwezesha madai katika uzalishaji, k.m., maktaba hazipaswi kuvuruga waita, uwepo wao unaweza kusababisha kukataliwa na maduka ya programu, na/au kuamilisha madai katika uzalishaji kunaweza kufunua data za faragha kama vile funguo za faragha. Kumbuka kwamba katika usambazaji mwingi wa Linux NDEBUG haijafafanuliwa, hivyo C/C++ assert() kwa chaguo-msingi itawezeshwa kwa uzalishaji katika mazingira hayo. Inaweza kuwa muhimu kutumia utaratibu tofauti wa madai au kufafanua NDEBUG kwa uzalishaji katika mazingira hayo.

    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



Data hii inapatikana chini ya Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Hii inamaanisha kuwa Mpokeaji wa Data anaweza kushiriki Data, na au bila marekebisho, mradi Mpokeaji wa Data anapatanisha maandishi ya mkataba huu na Data iliyoshirikiwa. Tafadhali tambua Alexey Lukin na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Alexey Lukin.
Ingizo liliundwa siku 2026-06-24 13:17:00 UTC, iliyosasishwa mara ya mwisho siku 2026-06-25 13:55:07 UTC. Ilipata mara ya mwisho nishani ya kupita siku 2026-06-24 17:34:54 UTC.