À une heure du matin, je rafraîchis Square et je vois, dans le groupe Newton, quelqu’un poster une capture d’écran : soumission d’une faille permettant l’évasion du sandbox, récompense créditée de 12 000 dollars. Dans la section commentaires, tout le monde ne parle que de « grands gars, guidez-moi ». Mon doigt est resté suspendu au-dessus de l’écran et ce n’est pas un problème technique qui m’a traversé l’esprit, mais un ami.
L’an dernier, il a découvert une faille sur un certain protocole DeFi : elle relevait du contrôle des permissions, et sa gravité n’était pas négligeable. Il l’a soumise via les canaux officiels avec un rapport détaillé, mais l’équipe a simplement lu sans jamais répondre. Au bout d’une semaine, il a relancé par e-mail. Leur réponse : « En interne, c’est déjà enregistré ». Deux semaines plus tard, le protocole a discrètement publié un correctif. Pas de mention de son nom, pas de récompense, même pas un simple merci. Par la suite, il n’a plus jamais touché à ce protocole.
Alors quand j’ai vu la capture postée par ce white hat chez Newton, ma première réaction n’a pas été de calculer le montant de la prime : c’est plutôt la chronologie qu’il mentionnait. De la soumission à la confirmation : quatre heures. Quatre heures, c’est quoi au juste ? J’ai déjà fait de l’audit de contrats, et je sais que, pour la plupart des équipes, la première réaction à un signalement de faille est le silence ; la deuxième, le déni ; la troisième, la correction en douce. Être capable de confirmer en quatre heures une faille de niveau « évasion du sandbox », ce rythme de réponse n’est pas courant dans les projets en phase bêta.
Il y a aussi un autre détail qui m’a davantage interpellé : après le correctif, l’équipe a rendu publics les détails techniques et le rapport de rétrospective sur le forum de gouvernance. Ce n’était pas quelques phrases du genre « merci au white hat » façon communication. C’était une chronologie complète, la cause technique racine, la solution de correction et les mesures de renforcement à la suite.
Cela m’a fait redécouvrir ce que le mot « sécurité » pèse, dans le langage de l’équipe Newton. D’autres projets traitent la sécurité comme un argument marketing ; eux la traitent comme un processus d’ingénierie devant être consigné publiquement et vérifiable par des tiers. Le barème de récompense n’est pas non plus du « au feeling » : il est gradué selon la sévérité des failles, et la prime des failles critiques est directement liée au pourcentage du montant total verrouillé.
J’ai éteint mon téléphone pour dormir et j’ai envoyé un message au même ami, celui qui avait été piégé l’an dernier : la prochaine fois que tu repères une faille, signale-la à Newton. Il m’a répondu : « On voit que cette équipe paie vraiment. » Je lui ai dit : ce n’est pas seulement une question d’argent. C’est une question d’attitude. Les promesses à l’oral, tout le monde peut en faire. Mais des critères de récompense clairement écrits noir sur blanc, et des traces de correction publiques et vérifiables, voilà ce qui manque le plus dans la sphère des cryptos.
#newt $NEWT @NewtonProtocol
L’an dernier, il a découvert une faille sur un certain protocole DeFi : elle relevait du contrôle des permissions, et sa gravité n’était pas négligeable. Il l’a soumise via les canaux officiels avec un rapport détaillé, mais l’équipe a simplement lu sans jamais répondre. Au bout d’une semaine, il a relancé par e-mail. Leur réponse : « En interne, c’est déjà enregistré ». Deux semaines plus tard, le protocole a discrètement publié un correctif. Pas de mention de son nom, pas de récompense, même pas un simple merci. Par la suite, il n’a plus jamais touché à ce protocole.
Alors quand j’ai vu la capture postée par ce white hat chez Newton, ma première réaction n’a pas été de calculer le montant de la prime : c’est plutôt la chronologie qu’il mentionnait. De la soumission à la confirmation : quatre heures. Quatre heures, c’est quoi au juste ? J’ai déjà fait de l’audit de contrats, et je sais que, pour la plupart des équipes, la première réaction à un signalement de faille est le silence ; la deuxième, le déni ; la troisième, la correction en douce. Être capable de confirmer en quatre heures une faille de niveau « évasion du sandbox », ce rythme de réponse n’est pas courant dans les projets en phase bêta.
Il y a aussi un autre détail qui m’a davantage interpellé : après le correctif, l’équipe a rendu publics les détails techniques et le rapport de rétrospective sur le forum de gouvernance. Ce n’était pas quelques phrases du genre « merci au white hat » façon communication. C’était une chronologie complète, la cause technique racine, la solution de correction et les mesures de renforcement à la suite.
Cela m’a fait redécouvrir ce que le mot « sécurité » pèse, dans le langage de l’équipe Newton. D’autres projets traitent la sécurité comme un argument marketing ; eux la traitent comme un processus d’ingénierie devant être consigné publiquement et vérifiable par des tiers. Le barème de récompense n’est pas non plus du « au feeling » : il est gradué selon la sévérité des failles, et la prime des failles critiques est directement liée au pourcentage du montant total verrouillé.
J’ai éteint mon téléphone pour dormir et j’ai envoyé un message au même ami, celui qui avait été piégé l’an dernier : la prochaine fois que tu repères une faille, signale-la à Newton. Il m’a répondu : « On voit que cette équipe paie vraiment. » Je lui ai dit : ce n’est pas seulement une question d’argent. C’est une question d’attitude. Les promesses à l’oral, tout le monde peut en faire. Mais des critères de récompense clairement écrits noir sur blanc, et des traces de correction publiques et vérifiables, voilà ce qui manque le plus dans la sphère des cryptos.
#newt $NEWT @NewtonProtocol