silken_net

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez indiquer votre statut de badge sur votre page de projet ! Le statut du badge ressemble à ceci : Le niveau de badge pour le projet 13358 est silver Voici comment l'intégrer :
Vous pouvez afficher votre statut de badge en incorporant ceci dans votre fichier markdown :
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13358/badge)](https://www.bestpractices.dev/projects/13358)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/13358"><img src="https://www.bestpractices.dev/projects/13358/badge"></a>


Ce sont les critères du niveau Or. Vous pouvez également afficher les critères des niveaux Basique ou Argent.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base 1/5 ●

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

    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.

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.

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

  • Conditions préalables


    Assez pour un badge !

    Le projet DOIT atteindre un badge de niveau argent. [achieve_silver]

  • Supervision du projet


    Pas assez pour un badge.

    Le projet DOIT avoir un « facteur bus » de 2 ou plus. (URL requise) [bus_factor]
    Un « bus factor » (aussi connu en tant que « truck factor ») est le nombre minimum de membres du projet qui doivent disparaître soudainement d'un projet (« écrasé par un bus ») avant que le projet ne se bloque en raison du manque de personnel compétent. L'outil truck-factor peut l'estimer pour des projets sur GitHub. Pour plus d'informations, voir Évaluation du « bus factor » des dépôts Git par 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


    Pas assez pour un badge.

    Le projet DOIT avoir au moins deux contributeurs significatifs non associés. (URL requise) [contributors_unassociated]
    Les contributeurs sont associés s'ils sont payés pour leur travail par la même organisation (en tant qu'employé ou contractuel) et si l'organisation bénéficie des résultats du projet. Les subventions financières ne comptent pas comme provenant de la même organisation si elles passent par d'autres organisations (par exemple, les subventions scientifiques versées à différentes organisations par un même gouvernement ou ONG ne rendent pas les contributeurs associés). Quelqu'un est un contributeur significatif s'il a apporté des contributions non triviales au projet au cours de la dernière année. Des exemples de bons indicateurs d'un contributeur significatif sont : écrit au moins 1 000 lignes de code, a contribué à 50 commits ou au moins 20 pages de documentation.

    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


  • Autre


    Pas assez pour un badge.

    Le projet DOIT inclure une déclaration de licence dans chaque fichier source. Cela PEUT être fait en incluant ce qui suit à l'intérieur d'un commentaire au début de chaque fichier : SPDX-License-Identifier : [expression d'une licence SPDX pour le projet]. [license_per_file]
    Cela PEUT également être fait en incluant une déclaration en langage naturel identifiant la licence. Le projet PEUT également inclure une URL stable indiquant le texte de la licence ou directement le texte complet de la licence. Notez que le critère license_location requiert que la licence du projet soit dans un emplacement standard. Voir ce didacticiel SPDX pour plus d'informations sur les expressions de licence SPDX. Notez la relation avec copyright_per_file, dont le contenu devrait généralement précéder les informations sur la licence.

    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


 Contrôle des modifications 3/4 ●

  • Dépôt source public sous contrôle de version


    Assez pour un badge !

    Le dépôt source du projet DOIT utiliser un logiciel courant de contrôle de version distribué (par exemple, git ou mercurial). [repo_distributed]
    Git n'est pas spécifiquement requis et les projets peuvent utiliser un logiciel de contrôle de version centralisé (comme subversion) avec justification.

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


    Pas assez pour un badge.

    Le projet DOIT identifier clairement les petites tâches qui peuvent être effectuées par des contributeurs nouveaux ou occasionnels. (URL requise) [small_tasks]
    Cette identification se fait typiquement en marquant les problèmes sélectionnés dans un outil de suivi de problèmes avec une ou plusieurs étiquettes que le projet utilise à cet effet, par exemple up-for-grabs, first-timers-only, « Small fix », microtask ou IdealFirstBug. Ces nouvelles tâches n'ont pas besoin d'ajouter des fonctionnalités ; elles peuvent améliorer la documentation, ajouter des cas de test ou toute autre chose qui aide le projet et aide le contributeur à en comprendre davantage sur le projet.

    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


    Assez pour un badge !

    Le projet DOIT exiger l'authentification à deux facteurs (2FA) des développeurs pour changer un dépôt central ou accéder à des données sensibles (telles que des signalements de vulnérabilités privés). Ce mécanisme 2FA PEUT utiliser des mécanismes sans mécanismes cryptographiques tels que SMS, mais cela n'est pas recommandé. [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)


    Assez pour un badge !

    L'authentification à deux facteurs du projet (2FA) DOIT utiliser des mécanismes cryptographiques pour empêcher l'emprunt d'identité. Une 2FA basée sur un service de messages courts (SMS), par elle-même, ne satisfait PAS à ce critère, car elle n'est pas chiffrée. [secure_2FA]
    Un mécanisme 2FA qui répond à ce critère serait une application de mot de passe à usage unique basé sur le temps (TOTP) qui génère automatiquement un code d'authentification qui change après un certain laps de temps. Notez que GitHub prend en charge 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)


 Qualité 6/7 ●

  • Normes de codage


    Assez pour un badge !

    Le projet DOIT documenter ses exigences en matière de revue de code, y compris la façon dont la revue de code est menée, ce qui doit être vérifié et ce qui est requis pour être acceptable. (URL requise) [code_review_standards]
    Voir aussi two_person_review et 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

    Pas assez pour un badge.

    Le projet DOIT avoir au moins 50% de toutes les modifications proposées revues avant la sortie par une personne autre que l'auteur, afin de déterminer s'il s'agit d'une modification valable et sans problèmes connus qui risqueraient de s'opposer à son inclusion. [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


  • Système de construction opérationnel


    Assez pour un badge !

    Le projet DOIT avoir une construction reproductible. Si aucune construction ne se produit (par exemple, les langages de script où le code source est utilisé directement au lieu d'être compilé), sélectionnez « non applicable » (N/A). (URL requise) [build_reproducible]
    Une construction reproductible signifie que plusieurs parties peuvent refaire indépendamment le processus de génération d'informations à partir de fichiers source et obtenir exactement le même résultat bit-à-bit. Dans certains cas, cela peut être résolu en forçant un ordre de tri. Les développeurs JavaScript peuvent envisager d'utiliser npm shrinkwrap et webpack OccurenceOrderPlugin. Les utilisateurs GGC et clang peuvent trouver l'option -frandom-seed utile. L'environnement de construction (y compris le jeu d'outils) peut souvent être défini pour les parties externes en spécifiant le hachage cryptographique d'un conteneur spécifique ou d'une machine virtuelle qu'ils peuvent utiliser pour la reconstruction. Le projet de construction reproductible dispose de documentation sur la façon de le faire.

    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


  • Suite de tests automatisée


    Assez pour un badge !

    Une suite de tests DOIT être invocable d'une manière standard pour ce langage. (URL requise) [test_invocation]
    Par exemple, « make check », « mvn test » ou « rake test » (Ruby).

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


    Assez pour un badge !

    Le projet DOIT utiliser une intégration continue, où le code nouveau ou modifié est fréquemment intégré dans un dépôt de code central et des tests automatisés sont exécutés sur le résultat. (URL requise) [test_continuous_integration]
    Dans la plupart des cas, cela signifie que chaque développeur qui travaille à plein temps sur le projet intègre son code au moins tous les jours.

    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


    Assez pour un badge !

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture d'instructions d'au moins 90% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [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


    Assez pour un badge !

    Le projet DOIT avoir une ou des suites de tests automatisées FLOSS qui fournissent une couverture de branche d'au moins 80% s'il existe au moins un outil FLOSS qui peut mesurer ce critère dans le langage sélectionné. [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


 Sécurité 5/5 ●

  • Utiliser de bonnes pratiques de base de cryptographie

    Notez que certains logiciels n'ont pas besoin d'utiliser des mécanismes cryptographiques. Si votre projet produit un logiciel qui (1) inclut ou active la fonctionnalité de chiffrement, et (2) peut être publié des États-Unis (US) vers l'extérieur des États-Unis ou vers un citoyen autre qu'américain, vous pouvez être légalement obligé à faire quelques étapes supplémentaires. En règle générale, cela implique simplement l'envoi d'un email. Pour plus d'informations, consultez la section sur le chiffrement de Comprendre la technologie Open Source et les contrôles à l'exportation américains .

    Assez pour un badge !

    Le logiciel produit par le projet DOIT supporter des protocoles sécurisés pour toutes ses communications réseau, tels que SSHv2 ou ultérieur, TLS1.2 ou ultérieur (HTTPS), IPsec, SFTP et SNMPv3. Les protocoles non sûrs tels que FTP, HTTP, telnet, SSLv3 ou antérieur, et SSHv1 DOIVENT être désactivés par défaut et uniquement activés si l'utilisateur le configure spécifiquement. Si le logiciel produit par le projet ne prend pas en charge les communications réseau, sélectionnez « non applicable » (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

    Assez pour un badge !

    Le logiciel produit par le projet DOIT, s'il prend en charge ou utilise TLS, prendre en charge au moins TLS version 1.2. Notez que le prédécesseur de TLS s'appelait SSL. Si le logiciel n'utilise pas TLS, sélectionnez « non applicable » (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

  • Livraison sécurisée contre les attaques man-in-the-middle (MITM)


    Assez pour un badge !

    Le site Web du projet, le dépôt (s'il est accessible via le Web) et le site de téléchargement (si séparé) DOIVENT inclure des en-têtes clés de durcissement avec des valeurs non admises. (URL requise) [hardened_site]
    Notez que GitHub et GitLab sont connus pour le faire. Des sites tels que https://securityheaders.com/ peuvent le vérifier rapidement. Les en-têtes clés de durcissement sont : Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (comme « nosniff ») et X-Frame-Options. Les sites Web complètement statiques sans possibilité de se connecter à travers les pages Web peuvent éventuellement omettre certains entêtes de durcissement avec moins de risques, mais il n'existe aucune manière fiable de détecter ces sites, donc nous exigeons ces en-têtes mêmes pour les sites complètement statiques.

    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


  • Autres problèmes de sécurité


    Assez pour un badge !

    Le projet DOIT avoir effectué une évaluation de la sécurité au cours des 5 dernières années. Cette revue DOIT prendre en considération les exigences de sécurité et les limites de sécurité. [security_review]
    Cela PEUT être fait par les membres du projet et/ou une évaluation indépendante. Cette évaluation PEUT être soutenue par des outils d'analyse statiques et dynamiques, mais il doit aussi y avoir une revue par des humains pour identifier les problèmes (en particulier dans la conception) que les outils ne peuvent pas détecter.

    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


    Assez pour un badge !

    Des mécanismes de durcissement DOIVENT être utilisés dans le logiciel produit par le projet afin que les défauts du logiciel soient moins susceptibles d'entraîner des vulnérabilités de sécurité. (URL requise) [hardening]
    Les mécanismes de durcissement peuvent inclure des en-têtes HTTP comme Content Security Policy (CSP), des options de compilation pour atténuer les attaques (telles que -fstack-protector) ou des options de compilation pour éliminer les comportements indéfinis. Pour nos besoins, le principe de plus faible privilège n'est pas considéré comme un mécanisme de durcissement (le principe de plus faible privilège est important, mais séparé).

    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


 Analyse 2/2 ●

  • Analyse dynamique de code


    Assez pour un badge !

    Le projet DOIT appliquer au moins un outil d'analyse dynamique à tout candidat pour une version majeure du logiciel produit par le projet avant sa sortie. [dynamic_analysis]
    Un outil d'analyse dynamique examine le logiciel en l'exécutant avec des entrées spécifiques. Par exemple, le projet PEUT utiliser un outil de fuzzing (par exemple, American Fuzzy Lop) ou un scanner d'application Web (par exemple, OWASP ZAP ou w3af). Dans certains cas, le projet OSS-Fuzz peut être prêt à appliquer des tests de fuzzing à votre projet. Aux fins de ce critère, l'outil d'analyse dynamique doit varier les entrées d'une manière ou d'une autre pour rechercher différents types de problèmes ou être une suite de test automatisée avec au moins 80% de couverture de branche. La page Wikipedia sur l'analyse dynamique et la page OWASP sur le fuzzing identifient certains outils d'analyse dynamique. Le ou les outils d'analyse PEUVENT être axés sur la recherche de vulnérabilités de sécurité, mais cela n'est pas nécessaire.

    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


    Assez pour un badge !

    Le projet DEVRAIT inclure de nombreuses assertions à l'exécution dans le logiciel qu'il produit, et vérifier ces assertions lors d'une analyse dynamique. [dynamic_analysis_enable_assertions]
    Ce critère ne suggère pas d'activer les assertions en production ; c'est entièrement au projet et à ses utilisateurs de le décider. L'objectif de ce critère est plutôt d'améliorer la détection des défauts lors de l'analyse dynamique avant le déploiement. L'activation des assertions en production est complètement différente de l'activation des assertions pendant l'analyse dynamique (comme les tests). Dans certains cas, il est extrêmement imprudent d'activer les assertions en production (en particulier dans les composants à haute intégrité). Il existe de nombreux arguments contre l'activation des assertions en production, par exemple, les bibliothèques ne devraient pas faire échouer les appelants, leur présence peut provoquer le rejet par les magasins d'applications et/ou l'activation d'une assertion en production peut exposer des données privées telles que des clés privées. Attention, dans de nombreuses distributions Linux, NDEBUG n'est pas défini, donc assert() sera activé par défaut en C/C++ pour la production dans ces environnements. Il peut être important d'utiliser un mécanisme d'assertion différent ou de définir NDEBUG pour la production dans ces environnements.

    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



Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Alexey Lukin et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Alexey Lukin.
Soumission créée le 2026-06-24 13:17:00 UTC, dernière mise à jour le 2026-06-25 13:55:07 UTC. Le dernier badge obtenu l'a été le 2026-06-24 17:34:54 UTC.