Talon d’Achille de l’open source : Nofx, 9000 étoiles en 2 mois, et ses scandales de hackers, conflits internes et questions sur l’open source
TechFlow SélectionTechFlow Sélection
Talon d’Achille de l’open source : Nofx, 9000 étoiles en 2 mois, et ses scandales de hackers, conflits internes et questions sur l’open source
De sa rapide ascension aux trois crises auxquelles elle fait face, l'histoire de Nofx résume le mouvement open source du Web3.
Dédié à des analyses Web3 approfondiesAuteur : WquGuru
Contexte de rédaction
Avant d’entamer cette histoire, je dois préciser ma position par rapport à cet événement.
Je suis un observateur et un analyste. Pendant la période où le projet Nofx a connu un succès fulgurant, j’ai développé le projet nof0 — les deux inspirés par nof1. Au cours du développement, j’ai échangé avec Tinkle et Zack, membres clés de l’équipe Nofx, principalement autour des questions techniques et de la collaboration open source.
Il convient de préciser que mes échanges avec l’équipe Nofx se sont limités au domaine technique, sans aucune relation commerciale ; quant à l’équipe ChainOpera AI (COAI), je n’ai eu aucun contact direct. En rédigeant cet article, j’ai fait mon possible pour rester objectif et neutre, toutes mes analyses et jugements étant fondés sur des informations publiques vérifiables, notamment les historiques GitHub, les publications sur les réseaux sociaux et les rapports de sécurité.
Durée de l'événement :
-
Fin octobre 2025 : lancement du projet Nofx, qui obtient près de 9000 étoiles sur GitHub en seulement 2 mois
-
Novembre 2025 : divulgation d'une vulnérabilité de sécurité, publication d'un avertissement par SlowMist (affaire des pirates)
-
Décembre 2025 : éclatement d’un litige concernant la licence open source (affaire de la licence), tandis que les dissensions internes au sein de l’équipe deviennent publiques (affaire des conflits internes)
L'ensemble de l'événement a duré environ deux mois, mais a concentré plusieurs contradictions inhérentes au mouvement open source Web3.
L'objectif de cet article n’est pas de prendre parti ni d’accuser une partie, mais plutôt de :
-
documenter intégralement ce cas emblématique du mouvement open source Web3
-
explorer le conflit profond entre esprit open source et intérêts commerciaux
-
fournir des éléments de réflexion et de référence pour l’établissement futur de normes dans le secteur
Maintenant, commençons par reconstituer cette histoire complexe depuis le début.
Prélude : l’essor fulgurant d’un projet de trading IA
À la fin d'octobre 2025, un projet de trading automatique IA nommé Nof1 a déclenché une vague sur Twitter. En quelques jours seulement, ses différentes versions open source — dont nof0 et nofx — ont accumulé des milliers d’étoiles sur GitHub. Le projet Nofx, lancé fin octobre, avait déjà rassemblé plus de 9000 étoiles en décembre, devenant l’un des projets open source les plus surveillés dans le domaine du Trading IA.
Pourtant, deux mois plus tard, ce projet vedette s’est retrouvé plongé dans trois crises simultanées :
Crise des pirates : l’entreprise de sécurité blockchain SlowMist a révélé que Nofx présentait une grave vulnérabilité de sécurité, exposant complètement les clés API des utilisateurs, leurs clés privées et leurs adresses de portefeuille sur plus de 1000 instances déployées à travers le réseau. Les principales bourses comme Binance et OKX sont intervenues d’urgence pour aider les utilisateurs affectés à renouveler leurs identifiants.
Crise interne : Tinkle, membre fondateur du projet, a publiquement accusé Zack, un autre cofondateur, d’avoir participé seulement 14 jours et apporté quelques lignes de code, tout en exigeant 50 % des parts et 500 000 dollars. Zack a riposté en envoyant un document juridique officiel par l’intermédiaire de son avocat, accusant Tinkle de « détournement d’actifs » et « transfert illicite de bénéfices », accompagné d’un document d’enregistrement d’entreprise prouvant que chacun détenait 50 % des parts.
Crise de la licence : Nofx a publiquement accusé ChainOpera AI (COAI), financée à hauteur de 17 millions de dollars, de violer la licence AGPL open source en déployant un produit commercial sans rendre leur code source public. COAI a répliqué que Nofx utilisait encore la licence MIT le 3 novembre, ne passant à l’AGPL que le 4 novembre, et que leur produit était développé en Python, totalement différent de l’implémentation Go de Nofx.
Comment un projet open source acclamé par la communauté a-t-il pu tomber en quelques mois dans une telle crise complexe ? Quels problèmes systémiques cela révèle-t-il au sein des communautés open source, des équipes de startups et de l’écosystème d’investissement ? Examinons attentivement cette tempête à travers cinq questions clés.
Question 1 : La licence open source a-t-elle vraiment été violée ?
MIT contre AGPL : deux philosophies open source radicalement opposées
Avant d’aborder le litige entre Nofx et COAI sur la licence, nous devons comprendre la différence fondamentale entre ces deux licences :
La licence MIT est l’une des licences open source les plus permissives. Elle permet :
-
d’utiliser, modifier et redistribuer librement le code
-
de l’utiliser à des fins commerciales sans obligation de publier le code source
-
la seule condition : conserver la mention de copyright de l’auteur original
L’AGPL v3.0 (Licence Publique Générale Affero GNU) est l’une des licences open source les plus strictes. Elle exige :
-
tout projet utilisant ce code doit également être open source
-
notamment, même si le service est fourni via internet (comme un SaaS), le code source doit être rendu public
-
indiquer clairement les informations du projet d’origine
Le passage de la licence MIT à l’AGPL représente un changement à 180 degrés, passant d’une situation « extrêmement permissive » à « extrêmement stricte ». C’est précisément là que réside le cœur du litige.
Changement de licence et controverse temporelle
La licence open source du projet Nofx est passée de MIT à AGPL, mais la date exacte de ce changement est devenue un point de discorde crucial, car elle détermine directement quelle licence l’équipe ChainOpera (COAI) devait respecter au moment du fork du code.
Comparaison des preuves des deux parties :
-
Nofx a fourni les enregistrements des commits GitHub, indiquant la date de modification du fichier de licence
-
COAI affirme que, selon ses propres observations et données, le moment public de ce changement de licence est douteux
L’accusation de « plagiat » par ChainOpera
La communauté Nofx a découvert que le projet ChainOpera (COAI), financé à hauteur de 17 millions de dollars et listé sur Binance Alpha, présentait un code fortement similaire à celui de Nofx.
Les accusations de Nofx :
-
COAI a utilisé le code de Nofx sans mentionner la source ni publier le code source
-
Selon la licence AGPL en vigueur à l’époque, COAI aurait dû : clairement indiquer la source du code, publier le code modifié, adopter la même licence AGPL
La réponse de COAI :
-
Affirme avoir effectué le fork alors que Nofx utilisait encore la licence MIT
-
La licence MIT autorise l’utilisation commerciale sans obligation de publication du code source
-
La controverse sur la date du changement de licence influence toute l’interprétation de l’événement
Conflit sur la licence open source : qui a tort, qui a raison ?
Ce litige met en lumière des problèmes profonds au sein de l’écosystème open source Web3 :
Problème de validité du changement de licence :
-
Controverse sur l’effet rétroactif : un changement de licence open source s’applique-t-il aux codes déjà forkés ?
-
Détermination du moment : la date exacte du changement de licence est difficile à établir définitivement, chaque camp soutenant sa version
-
Fiableté des preuves : les historiques GitHub peuvent être modifiés, nécessitant une validation tierce plus fiable
-
Communication du changement : dans quelle mesure le passage de MIT à AGPL a-t-il été annoncé à la communauté ?
Conflit d’intérêts commerciaux :
-
COAI a levé des fonds importants et est listée sur Binance, ce qui lui confère une grande valeur commerciale
-
Nofx, en tant que projet open source, n’a pas de voie commerciale claire
-
Conflit central : comment trouver un équilibre entre l’esprit de partage open source et la protection des intérêts commerciaux ?
Opinions divisées au sein de la communauté :
-
Les partisans de Nofx pensent que COAI tire profit du code open source sans redonner à la communauté
-
Les partisans de COAI soulignent que la licence MIT autorise l’usage commercial, et que la date du changement de licence reste incertaine
-
Les observateurs neutres notent que la question du timing est essentielle et qu’il faut des preuves plus solides pour trancher
Zone grise entre droit et technologie :
-
L’effet juridique des licences open source dans les projets blockchain n’est pas clair
-
La possibilité de falsifier les historiques GitHub affaiblit leur crédibilité en tant que preuve
-
Le secteur Web3 manque de mécanismes matures pour résoudre les litiges open source
Résumé : une accusation controversée
D’après les preuves publiques actuelles, les accusations de violation de licence par COAI formulées par Nofx comportent plusieurs points douteux :
-
Date incertaine : les preuves GitHub indiquent un changement vers AGPL seulement le 4 novembre
-
Implémentation différente : des noms d’interfaces identiques n’impliquent pas nécessairement un code identique
-
Explication logique des journaux : les fonctionnalités statistiques insérées pendant la phase MIT continuent de s’exécuter
-
Violation potentielle propre : insertion non déclarée de statistiques, risquant de violer les lois sur la vie privée
-
Procédure bâclée : envoi simultané d’un courriel et d’une accusation publique
Il est important de noter que la controverse sur la date du changement de licence joue un rôle décisif dans l’interprétation globale de l’événement. Si Nofx a raison, COAI a bel et bien violé la licence AGPL ; mais si COAI a raison, son comportement respecte pleinement les conditions de la licence MIT. Ce point doit être tranché par une validation tierce plus fiable.
Question 2 : 14 jours valent-ils 50 % des parts ?
Si l’affaire de la licence oppose Nofx à l’extérieur, celle des conflits internes révèle une lutte interne au projet — une bataille entre fondateurs sur la notion de « contribution » et de « valeur ».
Chronologie : de l’entrée à l’affrontement
28 octobre 2025 : début du développement de Nofx ;
29 octobre 2025 : Zack rejoint le projet (alors que le projet vient d’être publié depuis un jour) ;
Début novembre 2025 : Zack demande 50 % des parts, arguant pouvoir présenter Amber Group pour la commercialisation ;
Début novembre 2025 : Tinkle refuse de donner 50 %, estimant être le PDG et CTO de l’équipe, et que la contribution de Zack est insuffisante ;
19 novembre 2025 : l’avocat de Zack (bureau de Hong Kong du cabinet JunHe) envoie une « offre de règlement sans préjudice » (Without Prejudice Save as to Costs), demandant le paiement de 500 000 dollars pour racheter les 50 % de parts détenues par Zack ;
Décembre 2025 : le conflit devient public, les deux parties s’accusent mutuellement sur les réseaux sociaux ;
Chronologiquement, Zack passe moins d’un mois entre son entrée et l’envoi de la lettre d’avocat — un laps très court.
Face-à-face : deux versions contradictoires
Récit de Tinkle :
-
Zack n’a participé que 14 jours
-
A contribué quelques lignes de code (« vérifiable »)
-
A rejoint après que le projet soit déjà publié et compte des milliers de membres dans le groupe Telegram
-
A exigé des parts importantes en échange de la présentation d’Amber
-
Après refus, a retenu le compte Twitter du projet
-
A menacé de 500 000 dollars via son avocat, soupçonné de chantage
-
Zack était stagiaire chez Amber, mais n’a pas été titularisé et en est parti
-
N’a finalement pas réussi à attirer l’investissement d’Amber
La riposte de Zack :
-
Fournit les documents d’enregistrement de la société APEIRON LABS PTE. LTD.
-
Les documents montrent que Tinkle et Zack détiennent chacun 50 % des parts
-
Ce sont des informations publiques accessibles dans le registre des sociétés de Singapour, vérifiables par tous
-
La lettre d’avocat est une « offre de règlement sans préjudice », conforme aux procédures légales commerciales
-
Le document principal est une « lettre de mise en demeure » détaillant les actes de Tinkle : « détournement d’actifs, transferts illicites de profits »
-
500 000 dollars ne constituent pas un chantage, mais un rachat légitime basé sur une faible valorisation
-
Contre-question : si l’entreprise a de la valeur, pourquoi racheter 50 % pour 1 million de dollars serait-il déraisonnable ? Et si elle n’en a pas, pourquoi Tinkle appelle-t-il cela un « chantage » ?
Conflit central : comment quantifier la contribution ?
L’essence de ce conflit est un problème ancien dans les startups : contribution technique vs introduction de ressources, laquelle a plus de valeur ?
D’un point de vue du code, l’argument de Tinkle peut sembler raisonnable. L’historique des commits GitHub est public ; si Zack n’a effectué que peu de contributions, c’est une réalité facilement vérifiable dans la communauté technique. Sur un projet développé pendant 60 jours, une participation de 14 jours implique une différence énorme en temps et volume de code.
Mais du point de vue des parts, Zack présente un document légal. L’enregistrement de APEIRON LABS PTE. LTD. montre que les deux parties ont signé un accord de répartition 50-50. Cela signifie :
-
Un accord juridique formel a été conclu
-
L’accord reconnaît que Zack détient 50 % des droits
-
Ce n’est pas une promesse verbale, mais un fait juridique enregistré auprès des autorités
Alors pourquoi Tinkle a-t-il accepté une telle répartition ?
Quelle est la vraie valeur de la carte Amber ?
Le facteur clé est Amber Group — ou plus précisément, son accélérateur d’écosystème amber.ac.
Le levier de Zack : il peut présenter Amber pour la commercialisation de Nofx. Selon Tinkle, Zack a été stagiaire chez Amber (sans être titularisé). Dans l’industrie crypto, obtenir le parrainage ou les fonds d’un acteur majeur constitue une valeur considérable.
Mais le résultat final est :
-
Amber n’a pas investi formellement dans Nofx
-
Amber déclare officiellement : « aucune relation formelle d’incubation, d’investissement ou commerciale avec Nofx »
-
Amber reconnaît avoir eu des « échanges amicaux », mais cela n’a pas abouti à une coopération formelle
Cela donne lieu à deux interprétations possibles :
Interprétation A (pro-Tinkle) : Zack a exagéré ses capacités relationnelles, troquant une promesse vide contre des parts, n’a pas tenu sa promesse, refuse de céder ses parts et menace par lettre d’avocat.
Interprétation B (pro-Zack) : Un accord de parts a bien été conclu, Zack a tenté sérieusement d’introduire Amber, mais l’investissement n’a pas abouti à cause de problèmes côté Tinkle (peut-être liés à « détournement d’actifs, transferts illicites »). En tant qu’actionnaire légitime, Zack a le droit de demander son départ et une compensation.
Laquelle est plus proche de la vérité ? Il faudrait davantage de documents internes pour le savoir.
Procédure légale ou chantage ?
Tinkle a publié publiquement la lettre d’avocat de Zack et l’a qualifiée de « chantage ». Cette accusation est grave, car le chantage est un délit criminel.
Mais la réponse de Zack met en lumière la rigueur procédurale :
Une « offre de règlement sans préjudice » (Without Prejudice Save as to Costs) est une procédure juridique standard dans les systèmes de common law, destinée aux négociations de règlement. Ses caractéristiques sont :
-
Protégée par la loi, ne peut servir de preuve devant les tribunaux (sauf pour les frais de procès)
-
Elle encourage les parties à régler pacifiquement leur différend
-
Faire une proposition de règlement ne constitue pas un chantage
-
Le document principal est une « lettre de mise en demeure », listant les manquements contractuels ou violations
La lettre d’avocat de Zack demande 500 000 dollars, mais ce montant repose sur :
-
Le fait juridique que Zack détient 50 % des parts de la société
-
Une valorisation conservatrice de 1 million de dollars pour l’entreprise
-
Comme prix de rachat pour que Tinkle acquière les parts de Zack
D’un point de vue juridique, c’est une stratégie de négociation parfaitement légale. Si Tinkle pense vraiment qu’il s’agit d’un « chantage », la démarche correcte serait de porter plainte, pas de tweeter.
La mise en garde finale de Zack est aussi percutante :
« Si vous pensez vraiment que c’est du chantage, portez plainte immédiatement. Si vous n’avez pas le courage de le faire, arrêtez ce théâtre absurde. »
L’accusation cachée : détournement d’actifs et transferts illicites
Dans cet affrontement public, un détail attire l’attention : Zack mentionne que le corps principal de la lettre d’avocat est une « lettre de mise en demeure » détaillée, documentant les actes de Tinkle : « détournement des actifs de la société, complicité par moyens illégaux ».
Le contenu complet de cette lettre n’a pas été rendu public, mais l’accusation est très grave. Si elle est fondée, cela pourrait impliquer :
-
Détournement de fonds de l’entreprise à usage personnel
-
Échanges d’intérêts avec des investisseurs individuels
-
Violation des obligations fiduciaires envers la société
Tinkle n’a pas répondu directement à ces accusations, se contentant de dire : « Je ne répondrai plus, je me concentre sur le produit. »
Cette attitude d’évitement suscite la curiosité : que contient exactement cette lettre de mise en demeure ?
Résumé : un dilemme insoluble
Les litiges fondateurs sur les parts sont fréquents dans les startups. Le cas Nofx attire l’attention car il condense les conflits typiques :
-
Promesses verbales vs accords écrits : sans accord écrit, comment évaluer la contribution ?
-
Contribution technique vs introduction de ressources : comment mesurer ces deux valeurs ?
-
Responsabilité en cas d’échec : à qui incombe l’échec d’un investissement ?
-
Procédure légale vs jugement moral : une négociation équivaut-elle à un chantage ?
D’après les preuves disponibles :
-
Zack dispose d’un document légal confirmant ses 50 %
-
Tinkle dispose de l’historique des commits pour justifier son rôle central
-
Les deux ont leurs narratifs, mais manquent de chaînes de preuves complètes
La réponse finale ne pourra probablement venir que d’un tribunal. Mais ce cas alerte toutes les équipes de startups sur :
-
Fixer les parts tôt, par écrit, clairement
-
Quantifier objectivement les contributions (volume de code, temps de travail, valeur des ressources)
-
Conserver des traces des décisions importantes
-
Privilégier la voie légale en cas de litige, pas la guerre médiatique
Question 3 : Pourquoi les projets open source deviennent-ils des zones à risques sécuritaires ?
Avant le litige de licence entre Nofx et COAI et les conflits internes, une crise encore plus grave a commencé à poindre : une vulnérabilité de sécurité.
En novembre 2025, l’entreprise de sécurité blockchain SlowMist a publié un rapport d’analyse détaillé, révélant de graves failles de sécurité dans le projet Nofx. Ce n’était pas un simple « petit bug », mais une vulnérabilité pouvant entraîner le vol total des fonds des utilisateurs.
Chronologie de la faille : de l’absence d’authentification aux clés par défaut
31 octobre 2025 - Commit 517d0c : le péché originel de l’absence d’authentification
Dans ce commit, le code de Nofx présente un défaut fatal :
-
admin_mode défini par défaut à true
-
Le middleware autorise toutes les requêtes sans vérification
-
L’interface /api/exchanges est entièrement ouverte
Que signifie cela ? Quiconque connaît l’adresse d’un serveur exécutant Nofx peut accéder directement à l’interface /api/exchanges et récupérer :
-
api_key : la clé API de l’utilisateur
-
secret_key : la clé secrète de l’échange
-
hyperliquid_wallet_addr : l’adresse du portefeuille Hyperliquid
-
aster_private_key : la clé privée de la plateforme Aster
Avec ces informations, un attaquant peut :
-
Contrôler entièrement le compte utilisateur sur l’échange
-
Effectuer des transactions fictives (wash trading)
-
Retirer directement les fonds
-
Manipuler les prix du marché
C’est une exposition totale, une erreur fondamentale de conception de sécurité.
5 novembre 2025 - Commit be768d9 : l’illusion de « renforcement »
Peut-être conscient du problème, l’équipe Nofx a ajouté dans ce commit un mécanisme d’authentification JWT (JSON Web Token). En apparence, c’est un renforcement de sécurité.
Mais le problème est :
-
La clé jwt_secret par défaut n’a pas été modifiée
-
Si l’utilisateur ne définit pas la variable d’environnement, le système revient à une clé codée en dur
-
/api/exchanges continue de retourner tous les champs sensibles au format JSON brut
Cela signifie :
-
Un attaquant peut fabriquer un jeton JWT valide avec la clé par défaut
-
Une fois le jeton valide obtenu, toutes les clés seront toujours divulguées intégralement
-
La version « renforcée » reste en réalité fragile
C’est comme poser un verrou sur une porte, mais laisser la clé sous le paillasson, là où tout le monde sait la trouver.
13 novembre 2025 - Branche dev : risques persistants
Même le 13 novembre, le code de la branche dev présente encore plusieurs problèmes :
-
L’implémentation d’authMiddleware reste défectueuse (api/server.go:1471–1511)
-
/api/exchanges continue de retourner directement le ExchangeConfig complet (api/server.go:1009–1021)
-
Le fichier de configuration contient encore admin_mode=true et jwt_secret codé en dur
-
La branche principale (origin/main) est encore bloquée sur la version sans authentification du 31 octobre
Ce n’est pas une négligence accidentelle, mais un manque systématique de conscience de la sécurité.
Découverte et réponse : l’intervention clé de SlowMist
Source du renseignement : le chercheur en sécurité @Endlessss20 a fourni à SlowMist les premières indications sur les failles de sécurité de Nofx.
Analyse approfondie : l’équipe de sécurité de SlowMist a audité intégralement le code GitHub de Nofx, identifiant les deux problèmes d’authentification ci-dessus.
Scan global : plus choquant encore, SlowMist a effectué un scan à l’échelle d’internet, découvrant plus de 1000 instances Nofx accessibles publiquement, nombreuses utilisant des configurations par défaut ou faibles, exposant complètement les identifiants des utilisateurs.
Ce n’est pas un risque théorique, mais une menace réelle en cours.
Coordination urgente : face à l’urgence, SlowMist a contacté immédiatement les principales bourses :
-
Fourniture des informations aux équipes de sécurité de Binance et OKX
-
Les deux bourses ont fait une vérification croisée indépendante
-
Utilisation des clés API récupérées pour tracer les utilisateurs affectés
-
Notification des utilisateurs et assistance pour le renouvellement des clés
-
Blocage des attaques potentielles de wash trading
État d’avancement : au 17 novembre 2025, toutes les clés exposées des utilisateurs des bourses centralisées (CEX) ont été traitées. Mais certains utilisateurs Aster et Hyperliquid, en raison de la nature décentralisée de leurs portefeuilles, sont difficiles à atteindre directement, nécessitant une vérification personnelle.
Portée de l’impact : bien au-delà du technique
L’impact de cet incident dépasse largement le plan technique :
Victimes directes :
-
Plus de 1000 utilisateurs utilisant Nofx pour le trading automatisé
-
Couvrant Binance, OKX, Hyperliquid, etc.
-
Non seulement les clés API, mais aussi les clés privées et adresses de portefeuille ont été exposées
Pertes potentielles :
-
Si des attaquants agissent avant l’intervention des bourses, les fonds des utilisateurs pourraient être entièrement volés
-
Le trading IA est caractérisé par des opérations fréquentes et volumineuses, les pertes pourraient être énormes
Effondrement de la confiance :
-
La communauté perd confiance dans la sécurité du projet Nofx
-
Doute sur tout l’écosystème open source du Trading IA
-
Les développeurs sont plus prudents dans le choix des projets open source
Interrogation profonde : pourquoi de telles erreurs élémentaires ?
Les failles de sécurité de Nofx ne sont pas des défis techniques complexes, mais des bases de sécurité élémentaires :
-
Le mécanisme d’authentification devrait être activé par défaut, pas désactivé
-
Les clés par défaut devraient être générées aléatoirement, pas codées en dur
-
Les données sensibles devraient être chiffrées ou masquées, pas retournées en clair
-
Les fichiers de configuration devraient clairement avertir des risques de sécurité
Ce sont des principes que tout développeur expérimenté devrait connaître. Alors pourquoi Nofx a-t-il commis ces erreurs ?
Causes possibles :
-
Le développement rapide prime sur la sécurité : dans la fièvre du Trading IA, prendre les devants est plus important que la sécurité
-
Manque d’expérience de l’équipe : absence d’expérience dans la gestion sécurisée des fonds utilisateurs
-
Configuration de test en production : désactivation de l’authentification pour faciliter les tests, mais cette configuration est passée en production
-
Absence d’audit de sécurité : les projets open source manquent souvent d’audits professionnels
Mais la cause la plus fondamentale est peut-être : open source ≠ sécurité.
Beaucoup pensent que le code open source est « examiné par des milliers d’yeux », donc plus sûr. Mais en réalité :
-
La majorité des utilisateurs sont consommateurs, pas auditeurs
-
Même en cas de découverte, ils n’ont pas forcément la capacité ou la volonté de proposer une correction
-
Un audit de sécurité nécessite une expertise et beaucoup de temps
-
Les entreprises commerciales ont des équipes sécurité, pas les projets open source
Frontière de responsabilité : quelle responsabilité pour les auteurs open source ?
Cela soulève une question controversée : quand un utilisateur subit des pertes à cause d’une faille dans un logiciel open source, l’auteur open source doit-il assumer une responsabilité ?
D’un point de vue juridique, la plupart des licences open source (y compris MIT et AGPL) incluent une clause de non-responsabilité :
« Le logiciel est fourni "tel quel", sans garantie expresse ou implicite... L’auteur n’est responsable d’aucun dommage. »
Mais d’un point de vue moral, lorsque vous savez que votre code sera utilisé par les utilisateurs pour gérer des actifs réels, ne devriez-vous pas appliquer des normes de sécurité plus élevées ?
Le cas Nofx est particulier car :
-
C’est un système de trading IA automatisé, impliquant directement les fonds des utilisateurs
-
Le projet a obtenu plus de 9000 étoiles, avec de nombreux utilisateurs
-
La faille n’est pas une attaque sophistiquée, mais une absence de base de protection
-
Le problème existe depuis des semaines, avec de nouveaux utilisateurs se déployant continuellement
Leçons sectorielles : les risques spécifiques du Trading IA
La crise de sécurité de Nofx révèle les risques spécifiques du domaine du Trading IA :
Le double tranchant de l’automatisation :
-
Les systèmes de trading IA sont conçus pour fonctionner 24/7 en mode automatique
-
Une fois compromis, un attaquant peut exécuter rapidement de nombreuses transactions
-
Les utilisateurs peuvent ne découvrir le transfert de leurs actifs que plusieurs heures plus tard
Le paradoxe entre open source et sécurité :
-
L’open source favorise l’amélioration et l’examen par la communauté
-
Mais facilite aussi la découverte de failles par les attaquants
-
Avant que la faille soit corrigée, elle est déjà publique
Manque d’éducation des utilisateurs :
-
Beaucoup d’utilisateurs ne comprennent pas les risques du déploiement de systèmes de trading IA
-
Ils utilisent directement les configurations par défaut, ignorant qu’il faut changer les clés
-
Ils exposent le service sur le réseau public, sans protection de base
Signification exemplaire de SlowMist
Dans cet incident, l’action de SlowMist mérite d’être saluée :
-
Réponse rapide : analyse approfondie immédiate après réception du signalement
-
Scan proactif : découverte active d’instances affectées, sans attendre les signalements utilisateurs
-
Collaboration sectorielle : coordination étroite avec les bourses, pas d’action isolée
-
Divulgation publique : publication d’un rapport détaillé après gestion de l’urgence, pour éduquer la communauté
-
Position claire : insister sur le fait que ce n’est pas une critique, mais une réduction des risques
Ce mécanisme de divulgation responsable (Responsible Disclosure) est la pierre angulaire de la sécurité sectorielle.
Résumé : l’open source n’est pas un laissez-passer
L’incident de sécurité de Nofx nous enseigne :
-
Les projets open source ont besoin d’audits de sécurité : même pour des projets en itération rapide, on ne peut pas sauter cette étape
-
Les configurations par défaut doivent prioriser la sécurité : commodité pour le développeur = facilité pour l’attaquant
-
Les fonds des utilisateurs doivent être traités avec une attention particulière : la sécurité est une limite intransigeable pour les systèmes financiers
-
La communauté a besoin de mécanismes de réponse à la sécurité : l’action de SlowMist fournit un bon exemple
-
Compétence technique ≠ conscience de la sécurité : savoir écrire du code fonctionnel ne signifie pas savoir écrire du code sécurisé
Question 4 : Combien vaut le « parrainage » d’Amber ?
Dans les multiples crises de Nofx, un détail est facilement ignoré, mais il révèle un problème courant dans l’industrie crypto : la culture du parrainage.
L’apparition du parrainage : « Backed by@amber_ac_ »
Avant l’éclatement de l’affaire, si vous visitiez la page Twitter de Nofx, vous y voyiez cette ligne : « Backed by@amber_ac_ »
Que signifie cela ? Dans l’industrie crypto, « backed by » signifie généralement :
-
avoir reçu un investissement de cet organisme
-
ou au moins un soutien d’incubation
-
une reconnaissance officielle
Amber Group est une institution renommée dans le secteur crypto, dotée de ressources financières et humaines importantes. amber.ac est son accélérateur d’écosystème. Pour un nouveau projet open source, obtenir le parrainage d’Amber signifie :
-
Garantie de crédibilité : le projet semble plus fiable, attirant plus d’utilisateurs
-
Facilité de financement : d’autres investisseurs seront plus enclins à suivre
-
Soutien en ressources : possibilité d’obtenir un soutien technique, marketing, juridique
-
Confiance communautaire : les utilisateurs sont plus enclins à participer et contribuer
C’est comme si un entrepreneur obtenait une lettre d’intention d’un VC de premier plan : même sans argent reçu, ce seul parrainage apporte une immense valeur.
Le levier de Zack : je peux amener Amber
Revenons au contexte de l’affaire interne : l’un des principaux atouts de Zack pour exiger 50 % des parts était : il pouvait présenter Amber pour la commercialisation de Nofx.
Selon Tinkle, Zack a été stagiaire chez Amber. Dans le secteur, ce passé implique certaines relations professionnelles. Zack a promis à Tinkle de pouvoir introduire un investissement ou un soutien d’incubation d’Amber, en échange de 50 % des parts.
D’un point de vue commercial, cet échange est raisonnable :
-
Si Zack réussit à amener l’investissement d’Amber, cette valeur dépasse largement sa contribution en code sur 14 jours
-
Pour un projet open source, obtenir le parrainage d’un acteur majeur peut être le saut décisif du 0 au 1
-
Attribuer 50 % des parts à un introducteur de ressources n’est pas sans précédent dans les débuts d’une startup
Mais la question cruciale est : Amber est-il venu ?
Le démenti d’Amber : « aucune relation formelle d’incubation, d’investissement ou commerciale »
En décembre 2025, alors que les conflits internes et la crise de licence de Nofx faisaient grand bruit, amber.ac a publié une déclaration officielle :
« amber.ac n’a aucune relation formelle d’incubation, d’investissement ou commerciale avec Nofx. Nous avons eu des échanges amicaux basés sur l’observation du secteur, mais ces échanges n’ont conduit à aucune coopération formelle. Toutes nos collaborations officielles sont annoncées via notre site web. »
Cette déclaration est subtile :
-
Déni d’une relation formelle : pas d’investissement, pas d’incubation, pas de coopération commerciale
-
Reconnaissance d’un contact : « échanges amicaux », « observation du secteur »
-
Insistance sur la procédure : toute collaboration formelle est
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@wquguru
