La plupart des conseils de sécurité pour les utilisateurs crypto se concentrent sur les surfaces visibles : votre phrase de récupération, les liens sur lesquels vous cliquez, les sites où vous vous connectez. C'est important. Mais il existe un risque plus silencieux sous tout cela — le logiciel lui-même, et tout ce à partir de quoi il a été construit. Un portefeuille peut être écrit à la perfection et livrer malgré tout une porte dérobée, car les applications modernes sont assemblées à partir de centaines de briques tierces et d'un pipeline de build qui transforme le code source en le binaire que vous installez. Compromettez n'importe quel maillon de cette chaîne et vous compromettez tous les utilisateurs en aval.
C'est la chaîne d'approvisionnement logicielle, et les attaquants ont compris qu'elle est l'une des cibles à plus fort levier en crypto. Cet article explique ce qu'est réellement une attaque de la chaîne d'approvisionnement, pourquoi les portefeuilles sont des cibles si attrayantes, les défenses qui tiennent en pratique et ce que vous apportent les builds déterministes, y compris la façon dont SSP applique tout cela.
Ce qu'est une attaque de la chaîne d'approvisionnement
Une attaque de la chaîne d'approvisionnement ne pénètre pas directement dans l'application. Elle compromet plutôt quelque chose en quoi l'application a confiance : une dépendance qu'elle importe, le compte d'un mainteneur, ou le pipeline de build qui assemble l'artefact final. Le code malveillant entre par une mise à jour légitime, signée et livrée par les canaux habituels, de sorte qu'il ressemble exactement au logiciel que vous vouliez installer.
Cette indirection est tout l'enjeu. Attaquer une bibliothèque très utilisée — ou un serveur de build — peut atteindre des milliers de projets en aval et des millions d'utilisateurs d'un coup. Pour un portefeuille crypto, le gain est direct : le code qui s'exécute dans votre portefeuille a déjà accès au moment qui compte, lorsqu'une transaction est signée et que les adresses sont affichées. Une seule dépendance altérée peut remplacer une adresse de destination ou exfiltrer du matériel de clés sans jamais vous atteindre par hameçonnage ni par une mauvaise hygiène de la phrase de récupération. Voilà pourquoi cette catégorie d'attaque mérite une place dans votre modèle mental.
Deux cas qui touchent de près
Deux incidents réels montrent comment cela se déroule — l'un visant directement la crypto, l'autre qui a failli frapper tout internet.
event-stream et le portefeuille Copay
En 2018, un paquet npm populaire nommé event-stream a été confié à un nouveau mainteneur bénévole qui proposait son aide. C'était un transfert de routine, d'apparence bien intentionnée, du type qui se produit constamment dans l'open source. Le nouveau mainteneur a alors ajouté une nouvelle dépendance, flatmap-stream, qui contenait du code malveillant obfusqué.
La charge utile était inhabituellement ciblée. Au lieu de se déclencher pour tout le monde, elle ne s'activait qu'à l'intérieur d'un projet en aval précis : le portefeuille Bitcoin Copay. Là, elle était conçue pour voler le matériel de la phrase de récupération et les fonds des utilisateurs de cette application. La plupart des développeurs qui ont importé event-stream n'ont jamais été touchés — le code savait exactement quelle victime il cherchait.
C'est le rappel canonique que « je n'ai installé qu'une petite bibliothèque » n'est jamais toute l'histoire. Vous avez aussi installé tout ce à quoi cette bibliothèque fait confiance.
La porte dérobée de XZ Utils
L'incident XZ Utils de 2024 (CVE-2024-3094) fut encore plus patient. XZ Utils est une bibliothèque de compression présente discrètement sur la plupart des systèmes Linux. Sur plusieurs années, un attaquant a bâti sa crédibilité comme contributeur serviable, a peu à peu obtenu des responsabilités de mainteneur, puis a glissé une porte dérobée conçue pour interférer avec OpenSSH — le logiciel qui sécurise les connexions distantes aux serveurs partout dans le monde.
Cela a été détecté presque par accident, par un ingénieur qui a remarqué un retard d'une fraction de seconde. Si la porte dérobée s'était largement diffusée, elle aurait pu livrer un accès distant à d'innombrables machines.
La leçon pour la crypto est sévère : l'attaque n'a pas exploité un bug astucieux, elle a exploité le modèle de confiance de l'open source lui-même, en jouant une partie d'ingénierie sociale sur plusieurs années pour devenir la personne sur qui tout le monde comptait.
Les défenses qui marchent vraiment
Aucun contrôle isolé n'arrête les attaques de la chaîne d'approvisionnement. Ce qui marche, c'est une pile de contrôles, chacun réduisant les options de l'attaquant :
- Dépendances épinglées et fichiers de verrouillage. Épingler des versions exactes et versionner un fichier de verrouillage signifie qu'un build ne peut pas tirer en silence une version plus récente et altérée. Les mises à jour deviennent des événements délibérés et révisables, plutôt qu'automatiques.
- Dépendances minimales. Chaque paquet ajouté est une partie à qui vous faites confiance. Moins de dépendances, c'est une surface d'attaque plus réduite et moins de mainteneurs susceptibles d'être compromis.
- Mise en bac à sable des dépendances. Des outils comme LavaMoat limitent ce que chaque paquet peut faire à l'exécution, afin qu'une dépendance compromise ne puisse pas atteindre librement le réseau ni des API sensibles.
- Signature de code. Les versions signées permettent aux utilisateurs de vérifier qu'un binaire provient du véritable éditeur et n'a pas été modifié en transit.
- Audits par des tiers. Des cabinets de sécurité indépendants examinent le code et les dépendances avec un œil adverse, repérant ce que les équipes internes banalisent.
- Builds reproductibles et déterministes. La défense structurelle la plus forte, et celle qui mérite d'être comprise en détail.
Les builds déterministes, expliqués
Normalement, compiler deux fois le même code source peut produire deux binaires légèrement différents — des horodatages, l'ordre des fichiers et des détails de la machine de build s'y glissent. Cette variabilité est un problème, car elle signifie que vous ne pouvez pas distinguer une différence bénigne d'une différence malveillante.
Un build déterministe (ou reproductible) supprime cette variabilité. À partir du même code source, n'importe qui, n'importe où, sur n'importe quelle machine, produit un artefact identique octet pour octet. L'implication est puissante : des personnes indépendantes peuvent recompiler le portefeuille à partir de son code source public et confirmer que le binaire que vous avez téléchargé correspond, bit pour bit, à ce que produit le code source. Si un attaquant a altéré le pipeline de build ou y a glissé quelque chose après coup, les empreintes ne correspondront pas et l'altération devient immédiatement visible.
Cela renverse le modèle de confiance. Vous n'avez plus à croire l'éditeur sur parole ; la vérification devient quelque chose que toute la communauté peut réaliser et recouper. Le projet Reproducible Builds documente cette pratique dans tout l'écosystème, et des cadres comme SLSA définissent des niveaux de garanties d'intégrité de build que vous pouvez exiger d'un projet.
Comment SSP applique cela
SSP traite le pipeline de build comme une composante de son modèle de menaces, pas comme une réflexion après coup. Le portefeuille est livré avec un build déterministe basé sur un Dockerfile : le même environnement défini par Docker produit le même artefact à chaque fois, de sorte qu'une version publiée peut être recompilée à partir du code source public et comparée, bit pour bit, à ce que vous avez téléchargé. SSP a également fait l'objet d'audits de sécurité indépendants par Halborn, dont les audits examinent à la fois le code et les dépendances sur lesquelles il s'appuie.
Il existe une couche de plus, propre à la façon dont SSP est construit, et elle compte ici. SSP est un portefeuille multisig 2 sur 2 : chaque transaction exige une approbation indépendante d'une seconde clé, la SSP Key, sur un appareil distinct. Soyez précis sur ce que cela fait et ne fait pas. Les builds déterministes et les audits réduisent la probabilité qu'un build altéré soit livré d'emblée ; ils sont la première ligne. Mais même dans le pire des cas — un build qui serait passé d'une manière ou d'une autre — la seconde clé est une surface d'approbation distincte qui doit encore valider chaque transaction.
Ce n'est pas un bouclier magique, et cela ne rend pas un build compromis acceptable. Cela signifie simplement qu'un seul composant altéré sur un appareil ne déplace pas vos fonds à lui seul. La défense en profondeur, voilà l'idée.
Ce que vous pouvez vérifier vous-même
Vous n'avez pas besoin d'être ingénieur en sécurité pour profiter de tout cela. Quelques habitudes font une grande différence :
- Téléchargez uniquement depuis des sources officielles. Récupérez le portefeuille depuis son site officiel ou sa fiche de magasin, jamais depuis un lien dans un message ou une publicité de recherche. C'est la même discipline que couvre l'hygiène des extensions de navigateur.
- Privilégiez les projets qui publient des builds déterministes et des audits. Un projet qui laisse la communauté vérifier ses versions — et paie pour une revue indépendante — vous dit quelque chose sur sa façon de penser.
- Vérifiez les signatures et les empreintes quand elles sont proposées. Si une version fournit une signature ou une somme de contrôle, prenez la minute de la vérifier. Les builds reproductibles ne vous protègent que si quelqu'un fait réellement la comparaison.
- Gardez une opsec globale rigoureuse. Les défenses de la chaîne d'approvisionnement s'inscrivent dans un tableau plus large ; parcourez régulièrement votre liste opsec pour qu'aucune couche ne porte tout le poids.
Rien de tout cela n'exige de faire confiance à une seule partie. C'est exactement la propriété que vous voulez d'un logiciel d'auto-conservation.
Pour aller plus loin
Un portefeuille n'est digne de confiance que dans la mesure de la chaîne qui l'a construit. La bonne nouvelle, c'est que c'est l'un des rares problèmes de sécurité avec une réponse nette et structurelle : des builds déterministes plus des audits indépendants transforment le « faites-nous confiance » en « vérifiez vous-même ».
Continuez à bâtir vos défenses avec la vigilance face à l'hameçonnage, les bonnes pratiques de la phrase de récupération, l'hygiène des extensions de navigateur et une liste opsec régulière. Chacune ferme une porte ; ensemble, elles forment ce à quoi ressemble vraiment la sécurité en auto-conservation.
