Je ne m’attendais pas à ce qu’un simple fichier SECURITY.md me fasse réfléchir de manière plus attentive à @NewtonProtocol .
En général, quand je regarde des projets crypto, les éléments les plus bruyants sont faciles à trouver. Le pitch deck. La feuille de route. Le visuel de l’écosystème. La liste des partenaires. Le fil du token. L’explication soignée de pourquoi ce protocole compte.
La sécurité est généralement présentée de la même manière aussi.
Un badge.
Un logo d’audit.
Une courte ligne qui dit « signalez ici les vulnérabilités ».
Une formalité.
Mais parfois, le signal le plus intéressant n’est pas la chose conçue pour impressionner tout le monde. Parfois, c’est le fichier ennuyeux, tranquillement posé à côté du code.
C’est ce qui m’a marqué chez Newton.
Son SECURITY.md ne ressemble pas à un document créé principalement pour le marketing. Il ressemble à quelque chose écrit pour des personnes qui pourraient réellement tenter de briser le système et de signaler ce qu’elles trouvent. Il explique comment signaler des vulnérabilités, ce qui est dans le périmètre, et comment la divulgation devrait se faire.
Ça ressemble à du basique.
Mais en crypto, des choses simples faites sérieusement peuvent compter.
Ce qui a surtout retenu mon attention, ce n’était pas seulement le contenu du fichier. C’était l’endroit où il se trouve. Le document de sécurité est proche du code, des contrats et du travail de politique Rego. Il ne donne pas l’impression d’être caché dans une page juridique séparée, ni enterré sous une section polie de confiance et sécurité.
On dirait que c’est une partie de l’environnement d’ingénierie.
Ce petit détail compte pour moi.
Parce que la culture de sécurité ne consiste pas seulement à dire les bonnes choses publiquement. Elle concerne aussi la façon dont une équipe se prépare au moment où quelque chose tourne mal. Un vrai processus de sécurité suppose que des bugs peuvent exister. Il suppose que les chercheurs peuvent trouver des problèmes. Il leur donne une voie claire avant que la panique ne commence.
Cela ne prouve pas que Newton est sécurisé.
Un bon fichier SECURITY.md ne protège pas magiquement les contrats. Il ne remplace pas les audits. Il ne garantit pas que les rapports seront traités parfaitement. Cela ne veut pas dire que chaque vulnérabilité sera détectée à temps.
Mais c’est tout de même un signal.
Et certains signaux valent qu’on s’y attarde.
Un livre blanc vous dit vers quoi un projet veut devenir.
Un dossier de présentation explique aux investisseurs ce qu’il veut qu’ils croient.
Un fil Twitter vous dit ce qu’il veut que le marché répète.
Mais un fichier de sécurité au sein d’un dépôt vous dit quelque chose de plus discret. Il indique si l’équipe s’attendait à la venue de chercheurs en sécurité. Il montre si la divulgation des vulnérabilités a été traitée comme faisant partie du processus de construction, et pas seulement comme un simple regret de relations publiques.
Cette différence est importante.
Dans un système comme Newton, où l’application des politiques, l’autorisation, les contrats et la logique sensible des transactions comptent, le processus de sécurité autour du code ne peut pas être décoratif. Si les gens vont faire confiance au système pour décider si des actions doivent passer ou s’arrêter, alors le code sous-jacent doit être traité avec un sérieux réel.
C’est pourquoi de petits artefacts d’ingénierie peuvent parfois dire plus que de grandes annonces.
N’importe qui peut dire que la sécurité compte.
Moins d’équipes construisent comme elles s’attendent à être testées.
C’est la partie que je trouve intéressante.
Le SECURITY.md de Newton ressemble moins à un badge qu’à une invitation à un examen responsable. Il dit, en substance : voici comment signaler quelque chose, voici ce que nous considérons comme pertinent, voici comment ce processus devrait fonctionner.
Encore une fois, ce n’est pas une preuve.
Mais c’est plus sain que de prétendre que la sécurité n’est qu’une chose à faire annoncer après un audit.
L’industrie crypto a déjà vu trop de projets traiter la sécurité comme une couche marketing. Ils collectent des audits, affichent des logos, publient un thread, puis passent à autre chose. Mais la vraie sécurité n’est pas un événement unique. C’est une habitude. C’est une posture. C’est la discipline ennuyeuse consistant à garder les portes ouvertes pour les chercheurs avant que les attaquants ne les forcent à s’ouvrir.
C’est pour cela que ce type de fichier compte.
Pas parce que c’est excitant.
Parce que c’est utile.
Et les choses utiles révèlent souvent davantage d’un projet que les choses excitantes.
Pour $NEWT , je ne le traiterais pas comme une preuve haussière à lui seul. Ce serait trop facile. Une politique de sécurité claire ne signifie pas que le protocole sera sûr pour toujours.
Mais je le traiterais comme une petite marque dans la bonne colonne.
Cela suggère que quelqu’un a pensé aux personnes qui inspectent les systèmes de l’extérieur. Cela suggère que le signalement des vulnérabilités n’a pas été totalement mis de côté. Cela suggère que la sécurité est traitée comme faisant partie de l’infrastructure, et pas seulement comme un message.
En crypto, ce genre de sérieux mérite d’être surveillé.
Parce que parfois le document le plus important n’est pas le livre blanc.
Parfois, c’est le fichier discret à côté du code, écrit pour la personne qui pourrait trouver ce que tout le monde a manqué.