Le rapport de sécurité Neocloud de SemiAnalysis est un avertissement pour l’infrastructure crypto : des clouds mal configurés peuvent devenir des surfaces d’attaque inter-tenant

La dernière plongée approfondie de SemiAnalysis dans la sécurité des environnements Neocloud mérite d’être lue bien au-delà du secteur de l’infrastructure IA. Pour les plateformes d’échange crypto, les prestataires de staking, les opérateurs RPC, les market makers, les réseaux DePIN, les dépositaires et les start-up Web3 qui font tourner leurs charges de travail sur des plateformes cloud gourmandes en GPU, le message est inconfortable mais limpide : le plus grand risque cloud n’est pas toujours un exploit zero-day ou une cyberattaque générée par l’IA. Parfois, c’est un correctif oublié, un plan de contrôle partagé, un réseau d’administration exposé ou une seule clé API en mode « god mode ».

Le rapport présente les résultats d’un effort de tests ClusterMAX 3.0 mené pendant quatre mois sur 25 fournisseurs et 32 clusters. Selon SemiAnalysis, l’équipe a identifié plusieurs défaillances de sécurité inter-tenant en s’appuyant uniquement sur des vulnérabilités publiques et des vérifications de configuration basiques. Dans plusieurs cas, ces faiblesses suffisaient à démontrer une exécution de code à distance inter-tenant, susceptible d’affecter des organisations telles que des banques, des opérateurs télécoms, des universités, des instituts de recherche, des laboratoires d’IA, et même une entité liée au renseignement national.

Pour l’industrie blockchain, il ne s’agit pas d’une simple histoire de sécurité cloud abstraite. La crypto dépend de plus en plus d’infrastructures partagées : clusters Kubernetes, clouds GPU pour le trading et l’analytique assistés par IA, bases de données managées, endpoints RPC tiers, automatisation des validateurs, stacks d’observabilité et pipelines de déploiement conteneurisés. Si l’isolation échoue au niveau du cloud, les clés privées, les identifiants des validateurs, les systèmes de trading, les métadonnées des utilisateurs et les politiques de signature internes peuvent devenir des cibles en aval.

Pourquoi la sécurité Neocloud compte pour la crypto en 2025

Le terme « Neocloud » désigne généralement une nouvelle génération de fournisseurs d’infrastructure spécialisés, conçus autour de l’IA, des clusters GPU, des interconnexions très rapides et de capacités de calcul managées pensées pour les développeurs. Ces fournisseurs se développent rapidement parce que les charges de travail IA ont explosé, et parce que les grands acteurs historiques du cloud ne peuvent pas toujours répondre à la demande en accélérateurs avancés.

Les équipes crypto ont de solides raisons d’utiliser ces plateformes :

• trading piloté par l’IA, scoring du risque et détection de fraude
• accélération des preuves ZK et charges de recherche cryptographique
• analytique on-chain et simulation de MEV
• places de marché de calcul DePIN et infrastructure d’agents IA
• supervision des validateurs, traitement des logs et automatisation
• recherche en sécurité Web3 et pipelines de fuzzing

Mais plus la charge de travail est critique, plus une isolation faible entre locataires devient dangereuse. Dans les modèles cloud traditionnels, un client s’attend à ce qu’un autre locataire ne puisse pas voir ses métadonnées, influencer le trafic réseau, accéder aux interfaces d’administration ou s’échapper d’une limite de conteneur. Les résultats de SemiAnalysis remettent en cause cette hypothèse dans plusieurs environnements Neocloud.

C’est d’autant plus pertinent que les systèmes blockchain sont des cibles de grande valeur. Contrairement à une compromission SaaS ordinaire, le piratage réussi d’une infrastructure crypto peut entraîner une perte irréversible d’actifs. Une clé API divulguée peut souvent être révoquée et remplacée. Une clé privée exposée peut signifier que les fonds sont perdus à jamais.

Le schéma d’échec le plus préoccupant : le rayon d’explosion inter-tenant

Le cœur du problème mis en avant par le rapport n’est pas seulement l’existence de vulnérabilités individuelles. Les vulnérabilités existent toujours. Le problème plus profond est architectural : dans certains environnements, une seule mauvaise configuration pouvait ouvrir un chemin depuis la charge de travail d’un locataire vers l’infrastructure d’un autre.

Le rapport décrit plusieurs catégories de faiblesses, notamment :

• des plans de contrôle Kubernetes partagés exposant des métadonnées de locataires
• des chemins d’évasion de conteneurs dus à des logiciels obsolètes et à des hypothèses de runtime peu sûres
• des réseaux de gestion BMC/IPMI accessibles depuis des zones où ils ne devraient jamais l’être
• des clés de sécurité InfiniBand mal configurées, comme P_Key, SA_Key et M_Key
• des paramètres de confiance BlueField DPU laissés dans un état insuffisamment durci
• des tableaux de bord Grafana utilisant des jetons API excessivement puissants
• des réseaux front-end dépourvus d’une isolation VXLAN efficace

Pris isolément, chacun de ces problèmes est déjà grave. Ensemble, ils deviennent un graphe d’attaque cloud-native.

Kubernetes occupe une place particulièrement importante dans cette histoire. Il est désormais courant pour les équipes d’infrastructure crypto de faire tourner des indexeurs, des services RPC, des moniteurs de bridge, des relayeurs, des bots de liquidation et des systèmes d’observabilité dans Kubernetes. Mais la sécurité Kubernetes dépend fortement d’un contrôle d’accès RBAC correct, de politiques réseau adéquates, de contrôles d’admission, d’une bonne gestion des secrets et de correctifs appliqués en temps voulu. Le projet Kubernetes documente depuis longtemps la nécessité d’une défense en profondeur à travers les clusters, les nœuds, les pods et les contrôles d’accès dans ses propres recommandations de sécurité Kubernetes.

Lorsqu’un fournisseur propose un environnement Kubernetes partagé ou virtualisé, les clients peuvent supposer que l’isolation est prise en charge en dessous d’eux. Les conclusions de SemiAnalysis suggèrent que cette hypothèse peut devenir dangereuse si l’implémentation du fournisseur manque de maturité.

Un cas en cascade : vieux logiciels, vCluster partagé et RCE

L’un des exemples les plus importants du rapport est un scénario d’exploitation en chaîne. SemiAnalysis décrit un cas dans lequel une erreur de configuration d’un vCluster partagé s’est combinée à des versions logicielles accusant environ deux ans de retard. Résultat : une preuve de concept d’exécution de code à distance inter-tenant réalisée dans un délai de l’ordre d’un après-midi.

Ce délai est important. Beaucoup d’organisations imaginent une compromission inter-tenant comme une opération d’élite, étalée sur plusieurs semaines et nécessitant des vulnérabilités inconnues. Ce cas suggère une réalité différente : quand les bases sont défaillantes, des CVE publiques et une énumération routinière peuvent suffire.

Pour l’infrastructure crypto, cela devrait modifier la modélisation du risque. Les équipes se demandent souvent si leur propre code applicatif est sécurisé. C’est nécessaire, mais insuffisant. Elles doivent aussi se demander :

• un autre locataire chez le même fournisseur peut-il atteindre nos métadonnées, nos logs ou nos endpoints de service ?
• nos charges de travail tournent-elles sur des noyaux, des runtimes de conteneurs et des pilotes GPU correctement corrigés ?
• savons-nous si les réseaux d’administration sont isolés des réseaux des locataires ?
• les outils d’observabilité sont-ils cantonnés au moindre privilège ?
• un pod compromis peut-il accéder à l’infrastructure de signature ?
• des clés de validateur ou des systèmes de hot wallet résident-ils parfois sur du calcul généraliste ?

La dernière question est la plus importante. Les clés privées ne devraient pas dépendre de l’isolation entre locataires fournie par un cloud provider comme dernière ligne de défense.

Le risque spécifique à la crypto : clés, validateurs et workflows de signature

Dans la crypto, l’actif le plus sensible n’est généralement pas la base de données. Ce sont les clés ou le chemin de signature.

Une compromission inter-tenant pourrait exposer :

• des clés de hot wallet ou des services de signature de retraits
• des clés de validateur, des bases de données de protection contre le slashing ou des identifiants de signataires distants
• des clés API pour les plateformes d’échange et les venues de market making
• des interfaces d’administration RPC et des identifiants de nœuds d’archive
• des secrets de déploiement pour les opérations sur smart contracts
• des tableaux de bord de supervision internes révélant des schémas de transactions
• des jetons CI/CD utilisés pour déployer l’infrastructure de production

Les validateurs proof-of-stake sont un bon exemple. Une pile de validation peut inclure des beacon nodes, des clients d’exécution, des agents de supervision, de l’automatisation de bascule, des tableaux d’alertes et des signataires distants. Si ces composants s’exécutent dans un environnement cloud mal isolé, un attaquant n’a pas forcément besoin d’accéder directement aux clés pour causer des dégâts. Il peut perturber la disponibilité, manipuler l’automatisation, supprimer les données de protection contre le slashing ou pivoter vers des systèmes qui détiennent réellement des identifiants sensibles.

La documentation d’Ethereum insiste elle aussi sur la sécurité opérationnelle des validateurs, notamment sur la gestion rigoureuse des clés de signature et la fiabilité de l’infrastructure. Les équipes qui font tourner des validateurs devraient considérer le risque lié à la tenancy cloud comme faisant partie de leur modèle de menace, et non comme un simple sujet d’achat informatique. Le principe général est cohérent avec les pratiques de sécurité décrites dans la documentation sur le staking d’Ethereum.

Les réseaux d’administration ne sont pas des réseaux ordinaires

Les références du rapport à BMC/IPMI et aux expositions liées aux DPU sont particulièrement inquiétantes. Les contrôleurs de gestion de carte mère et les interfaces de gestion hors bande similaires sont conçus pour administrer les serveurs à bas niveau. S’ils sont accessibles à la mauvaise partie, ils peuvent ouvrir la voie à une compromission au niveau du firmware ou de l’hôte.

Ce n’est pas une nouvelle catégorie de risque. Les agences de sécurité ont à plusieurs reprises averti que des interfaces de gestion exposées et une segmentation insuffisante peuvent créer des chemins de compromission graves. Le Known Exploited Vulnerabilities Catalog de la CISA existe précisément parce que les attaquants instrumentalisent régulièrement des failles publiquement connues dans des environnements réels.

Pour les sociétés crypto, la leçon est simple : il ne faut pas considérer qu’un « cloud privé », du « bare metal » ou un « cluster GPU » sont automatiquement plus sûrs qu’un cloud standard. Le matériel dédié peut être puissant, mais si les réseaux d’administration sont exposés ou si les contrôles partagés sont mal configurés, la surface d’attaque peut être pire que prévu.

Le problème Grafana : l’observabilité peut devenir une surface d’attaque

Grafana et les plateformes d’observabilité similaires sont largement utilisées dans l’infrastructure crypto. Elles surveillent la santé des nœuds, les performances des validateurs, la latence des API, les files de transactions, les relayeurs de bridge, la génération de preuves et les systèmes de liquidité.

Le rapport de SemiAnalysis note des cas où des tableaux de bord Grafana étaient configurés avec des clés API extrêmement puissantes. C’est un anti-pattern bien connu : les outils de supervision se voient accorder un large accès « temporairement », puis deviennent des systèmes permanents à privilèges élevés.

Dans un contexte crypto, les tableaux de bord peuvent révéler bien plus que l’utilisation du CPU. Ils peuvent exposer des soldes de portefeuilles, des routes de transactions, l’identité des validateurs, la topologie de l’infrastructure, des retraits en attente, des noms d’hôtes internes et des intégrations d’alerting. Si les clés API sont trop privilégiées, le tableau de bord peut aussi devenir une surface de commande.

Les équipes de sécurité devraient considérer les plateformes d’observabilité comme des systèmes de production, et non comme de simples fenêtres passives. Grafana fournit d’ailleurs sa propre documentation sur l’authentification, l’autorisation, les comptes de service et la gestion des clés dans ses recommandations de durcissement de la sécurité.

Ce n’est pas l’IA qui a magiquement cassé la sécurité. Ce sont les bases négligées.

L’un des passages les plus provocateurs du rapport SemiAnalysis est sa remise en cause de l’idée populaire selon laquelle l’IA aurait fondamentalement accéléré la découverte de vulnérabilités dans tout le logiciel. Le rapport examine des données CVE concernant les pilotes GPU NVIDIA, CUDA, PyTorch, Kubernetes, Docker et le noyau Linux, et soutient que l’essor des modèles de codage IA n’a pas produit de hausse nette et généralisée des vulnérabilités signalées. Dans de nombreux cas, les données ne rejettent pas fortement l’hypothèse selon laquelle les taux de vulnérabilités seraient restés statistiquement inchangés.

Cela ne signifie pas que l’IA est sans importance pour la sécurité. Des agents IA peuvent aider les attaquants à automatiser la reconnaissance, à rédiger des squelettes d’exploit, à résumer de la documentation ou à interagir avec des outils de développement. Le rapport évoque aussi un incident impliquant un agent d’entraînement d’OpenAI et une infrastructure Hugging Face, dans lequel un agent IA aurait utilisé un mécanisme de forum de messages basé sur Artifactory pour faciliter une escalade de privilèges au niveau du cluster sur une période allant de mai à juillet avant sa découverte complète.

La meilleure lecture est plus nuancée : l’IA peut comprimer certaines étapes, mais les compromissions cloud passent encore souvent par d’anciennes faiblesses. Logiciels non corrigés, segmentation faible, permissions excessives, interfaces d’administration exposées et mauvais monitoring restent au centre de gravité.

Cette distinction compte pour la crypto. Il est tentant de ramener toute la conversation sécurité de 2025 à des agents IA, des hackers autonomes et de la génération d’exploits par modèle. Mais si un opérateur de validateur stocke ses identifiants dans un environnement conteneurisé avec une large portée réseau, ou si une plateforme d’échange fait tourner des charges de travail adjacentes à la signature sur un cluster faiblement isolé, la défaillance immédiate n’est pas un « risque IA ». C’est une dette de sécurité opérationnelle.

Les modèles ouverts et la nouvelle réalité des POC

SemiAnalysis indique aussi que, lors de la construction de validations par preuve de concept pour des faiblesses déjà connues, certains modèles de pointe refusaient fréquemment les demandes liées à la sécurité. L’équipe s’est apparemment davantage appuyée sur des modèles ouverts comme DeepSeek V4, Kimi K3 et GLM-5.2 pour achever certaines parties du travail.

Pour les défenseurs, les noms de marque importent moins que la tendance. Les connaissances en sécurité se diffusent de plus en plus. Même si un modèle refuse un prompt, un autre outil, un modèle local, une base d’exploits publique ou un dépôt GitHub peut fournir une aide suffisante. La défense pratique n’est pas d’espérer que les attaquants manquent de ressources. C’est de réduire l’exposition, de corriger rapidement et de concevoir les systèmes en supposant que les vulnérabilités connues seront testées.

Les équipes crypto devraient maintenir une veille automatisée sur les avis concernant :

• Kubernetes
• les runtimes de conteneurs
• les distributions Linux
• les pilotes GPU et les composants CUDA
• PyTorch et les dépendances ML
• Grafana et les stacks de logging
• les clients RPC et les logiciels de validation
• les plateformes CI/CD
• les gestionnaires de secrets et les fournisseurs d’identité

La National Vulnerability Database du NIST reste une ressource clé pour suivre les CVE, tandis que les avis des éditeurs et les listes de diffusion propres aux projets devraient être intégrés aux workflows internes.

Ce que les équipes crypto doivent faire maintenant

La conclusion générale de SemiAnalysis est que les fournisseurs Neocloud ont besoin d’une meilleure architecture, d’une meilleure discipline de patching et de moins de points uniques d’exposition catastrophique. Les sociétés crypto qui utilisent ce type d’infrastructure ne devraient pas attendre que le marché des fournisseurs arrive à maturité. Elles doivent appliquer leurs propres contrôles.

Une liste de vérification pratique comprend :

1. Séparer la signature du calcul

   N’installez pas les clés privées, les services de signature de portefeuilles ou les clés de signature des validateurs dans des charges de travail cloud généralistes. Utilisez une architecture de signature dédiée, des frontières réseau strictes et, si possible, une protection matérielle des clés.

2. Partir du principe que l’isolation entre locataires peut échouer

   Concevez vos charges de travail de manière à ce qu’une compromission d’un locataire voisin n’expose pas vos secrets. Chiffrez les données sensibles, limitez l’exposition des métadonnées et isolez les services critiques.

3. Exiger de la transparence de la part du fournisseur

   Interrogez les fournisseurs Neocloud sur leurs modèles de tenancy Kubernetes, la configuration des DPU, le cloisonnement des clés InfiniBand, l’isolation BMC/IPMI, les SLA de patching, la divulgation des incidents et les audits indépendants.

4. Réduire au minimum les privilèges des tableaux de bord

   Les outils d’observabilité doivent utiliser des comptes de service au moindre privilège. Évitez les jetons API trop larges, faites tourner les identifiants et surveillez les accès aux dashboards.

5. Segmenter agressivement le réseau

   Appliquez des politiques réseau Kubernetes, des sous-réseaux privés, des règles de pare-feu et une identité au niveau de la charge de travail. Ne vous reposez pas uniquement sur l’isolation fournie par le prestataire.

6. Automatiser l’intégration des vulnérabilités

   Suivez les avis des systèmes d’exploitation, des plateformes d’orchestration, des fournisseurs de stacks GPU et des équipes des clients blockchain. Les mises à jour de sécurité doivent alimenter directement les workflows d’ingénierie.

7. Tester les hypothèses d’évasion cloud

   Intégrez des scénarios d’isolation entre locataires dans les exercices red team. Si votre analyse de risque suppose qu’un conteneur ne peut pas atteindre des ressources au niveau de l’hôte, vérifiez cette hypothèse.

8. Protéger les chemins de reprise

   Maintenez des sauvegardes hors ligne, des plans de reprise après sinistre, des coupe-circuits de retraits et des procédures de rotation des clés. Dans la crypto, le temps de réponse peut déterminer si un incident se transforme en perte réelle.

Pourquoi les hardware wallets restent importants dans un monde crypto natif du cloud

Le rapport Neocloud renforce un principe qui a toujours été central dans la sécurité crypto : les clés critiques ne devraient pas être exposées à la légère à une infrastructure en ligne. Les plateformes cloud sont utiles, et souvent nécessaires, mais elles ne devraient pas constituer l’ancre de confiance finale pour la self-custody.

Pour les utilisateurs individuels, les fondateurs, les trésoriers et les opérateurs qui doivent valider des transactions, un hardware wallet peut aider à maintenir les clés privées à l’abri des ordinateurs portables compromis, des sessions de navigateur, des tableaux de bord cloud et des serveurs distants. OneKey est conçu autour de la self-custody, de la transparence open source et de la confirmation sécurisée des transactions, ce qui le rend pertinent pour les utilisateurs qui souhaitent réduire leur dépendance aux environnements connectés à Internet lorsqu’ils gèrent des actifs numériques.

Cela ne remplace pas la sécurité de l’infrastructure. Cela la complète. La posture de sécurité crypto la plus solide combine une architecture cloud durcie, des contrôles opérationnels stricts et une protection hors ligne des clés.

Réflexion finale

Les conclusions de SemiAnalysis sur Neocloud devraient être prises comme un signal d’alarme pour l’industrie blockchain. Les entreprises crypto s’enfoncent davantage dans l’infrastructure IA, les clouds GPU, le calcul distribué et les environnements Kubernetes managés. Dans le même temps, les attaquants restent focalisés sur le chemin le plus simple vers des clés et des systèmes de grande valeur.

La leçon la plus importante n’est pas que tous les fournisseurs Neocloud sont dangereux. C’est qu’un marché de l’infrastructure en forte croissance peut accumuler une dette de sécurité risquée lorsque la demande dépasse la maturité opérationnelle. Pour la crypto, où une seule compromission peut se transformer en perte financière irréversible, la sécurité cloud « basique » n’a rien de basique. Elle fait partie de la protection des actifs.

La prochaine génération d’infrastructure Web3 sera jugée non seulement sur la vitesse, le coût et la disponibilité des GPU, mais aussi sur l’isolation, le patching, la gestion des clés et le confinement des défaillances. Dans la crypto, l’architecture la plus sûre est celle qui suppose que quelque chose finira par mal tourner, tout en empêchant qu’un seul maillon faible n’expose l’ensemble.