💻 computer science

Assessing Vulnerability in Smart Contracts: The Role of Code Complexity Metrics in Security Analysis

Cette recherche démontre que si les métriques de complexité logicielle individuelles présentent une faible corrélation avec des vulnérabilités spécifiques dans les contrats intelligents Solidity, leur analyse collective permet de distinguer efficacement le code sécurisé du code vulnérable, les contrats vulnérables présentant systématiquement des scores de complexité moyenne plus élevés.

Auteurs originaux : Masoud Jamshidiyan Tehrani

Publié 2026-01-26

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Masoud Jamshidiyan Tehrani

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez qu'un Smart Contract (contrat intelligent) est comme un distributeur automatique de boissons auto-exécutable construit sur une blockchain. Une fois que vous avez inséré de l'argent et appuyé sur un bouton, il vous donne un snack automatiquement. Vous ne pouvez pas revenir en arrière pour modifier les engrenages internes de la machine plus tard ; elle est « immuable ». S'il y a un défaut dans les engrenages, un pirate peut voler tout l'argent à l'intérieur, et il n'y a aucun moyen de le réparer sans construire une toute nouvelle machine.

Cet article traite de la tentative de trouver ces engrenages cassés avant que la machine ne soit déployée. Les chercheurs se sont posé une question simple : « Pouvons-nous dire si un distributeur automatique est susceptible d'être défectueux simplement en regardant à quel point ses plans sont complexes ? »

Voici la décomposition de leurs découvertes en utilisant des analogies de la vie quotidienne :

1. L'idée centrale : La complexité est un « signal d'alarme »

Les chercheurs ont examiné 21 façons différentes de mesurer à quel point le code d'un programme est « désordonné » ou « complexe ». Considérez ces mesures comme des indicateurs mesurant des choses telles que :

SLOC (Lignes de code source) : Combien de pages contient le manuel d'instructions ?
Imbrication (Nesting) : Combien de couches de boîtes « si ceci, alors cela » sont imbriquées les unes dans les autres ? (Comme une poupée russe).
Couplage (Coupling) : De combien d'autres machines cette machine a-t-elle besoin pour communiquer afin de fonctionner ?

La découverte : Ils ont constaté que des plans désordonnés signifient généralement des machines défectueuses.
Lorsqu'ils ont examiné les contrats qui avaient été piratés (vulnérables), leurs plans étaient presque toujours plus complexes, plus longs et plus emmêlés que les plans des contrats sûrs.

2. Le problème de la « boule de cristal » (Mesures individuelles)

Les chercheurs ont tenté de voir si une seule mesure spécifique pouvait prédire un piratage.

Analogie : Imaginez essayer de deviner si une voiture va avoir un accident simplement en regardant le nombre de porte-gobelets.
Résultat : Cela n'a pas bien fonctionné. Aucune mesure unique (comme compter seulement les lignes de code) n'était une « boule de cristal » parfaite. Si vous regardiez uniquement le nombre de lignes, vous ne pouviez pas dire de manière fiable : « Celui-ci va certainement être piraté. » La connexion existait, mais elle était faible.

3. Le succès de « l'effort d'équipe » (Mesures combinées)

Cependant, lorsqu'ils ont examiné toutes les mesures ensemble, le tableau est devenu très clair.

Analogie : On ne peut pas savoir si une soupe est salée juste en goûtant le salier, mais si on goûte tout le bol, on sait exactement à quel point elle est salée.
Résultat : Bien qu'une seule mesure ne suffisait pas, la combinaison de mesures était très efficace pour distinguer les contrats sûrs des contrats dangereux. Les contrats « vulnérables » avaient systématiquement des scores plus élevés sur toute la ligne (plus de lignes, plus d'imbrications, plus de connexions) par rapport aux contrats sûrs.

4. Les exceptions surprenantes

Il y a eu trois éléments qui allaient à l'encontre de la règle « plus de complexité = plus de danger » :

Les commentaires (CLOC) : Les contrats sûrs avaient plus de commentaires (notes écrites par le programmeur pour expliquer le code). Les contrats vulnérables en avaient moins.
- À retenir : Écrire des notes sur votre plan semble aider à maintenir votre machine en sécurité.
Les descendants (NOD) : Les contrats sûrs avaient plus de « descendants » (versions ou contrats enfants). Les vulnérables en avaient moins.
Les paramètres : Les contrats vulnérables avaient en fait légèrement moins d'entrées/paramètres en moyenne.

5. Ce que cela signifie pour les développeurs

L'article conclut que la complexité n'est pas la cause du piratage (comme un virus), mais qu'elle est un signal d'avertissement très sonore.

L'analogie : Si vous voyez une maison avec un enchevêtrement de fils électriques, des tuyaux exposés et un plan au sol confus, vous ne savez pas avec certitude qu'elle va prendre feu, mais vous savez qu'elle est beaucoup plus susceptible de le faire qu'une maison avec un câblage propre et organisé.
Le conseil : Les développeurs doivent essayer de garder leur code simple. Si un contrat devient trop complexe, c'est un signal pour s'arrêter et vérifier les failles de sécurité. De plus, écrivez plus de commentaires ; les données suggèrent qu'un code bien documenté est plus sûr.

Résumé

L'article prouve que la complexité est un indicateur fort de risque dans les smart contracts. Vous ne pouvez pas vous appuyer sur un seul chiffre pour prédire un piratage, mais si vous regardez le « désordre » global du code, vous pouvez repérer les contrats dangereux bien mieux que si vous ignoriez totalement la complexité. C'est un outil pour aider les auditeurs et les développeurs à prioriser les contrats qui nécessitent l'inspection la plus minutieuse.

Résumé Technique : Évaluation de la vulnérabilité des contrats intelligents via les métriques de complexité du code

Énoncé du problème
Les contrats intelligents déployés sur des plateformes blockchain comme Ethereum sont immuables et gèrent souvent des transactions financières de haute valeur, ce qui rend l'assurance de la sécurité critique. Bien que la blockchain sous-jacente soit sécurisée, les contrats intelligents eux-mêmes sont vulnérables aux exploitations découlant de la négligence des programmeurs ou d'erreurs de codage. Les outils d'analyse statique traditionnels reposent souvent sur la reconnaissance de formes pour détecter des types de vulnérabilités spécifiques. Cependant, il est nécessaire de comprendre si les propriétés structurelles du code, spécifiquement la complexité logicielle, peuvent servir d'indicateurs complémentaires pour identifier les zones vulnérables. Les auteurs postulent qu'un code s'écartant des meilleures pratiques établies (c'est-à-dire une complexité plus élevée) peut présenter une exposition plus grande aux défauts de sécurité, mais que la relation spécifique entre les métriques de complexité et les vulnérabilités des contrats intelligents Solidity reste un problème ouvert nécessitant une validation empirique.

Méthodologie
L'étude emploie une approche quantitative et empirique pour analyser la relation entre 21 métriques de complexité logicielle distinctes et la présence de vulnérabilités dans les contrats intelligents Solidity.

Jeu de données : La recherche utilise un jeu de données dérivé de Liu et al., composé de 16 239 contrats individuels (258 vulnérables, 15 981 neutres) extraits d'Etherscan. Les contrats vulnérables ont été étiquetés selon huit types de vulnérabilités spécifiques : dépassement de capacité d'entier (Integer Underflow/Overflow), égalité stricte d'Ether dangereuse (Dangerous Ether Strict Equality), réentrance (Reentrancy), dépendance au horodatage (Timestamp Dependency), dépendance au numéro de bloc (Block Number Dependency), appel délégué dangereux (Dangerous Delegatecall), gel de l'Ether (Ether Frozen) et appel externe non vérifié (Unchecked External Call).
Extraction des métriques : L'outil d'analyse statique Solmet a été utilisé pour extraer 21 métriques de complexité pour chaque contrat. Celles-ci incluent des métriques de taille (SLOC, LLOC, CLOC), des métriques structurelles (NF, WMC, NOS), des métriques d'imbrication (NL, NLE), des métriques d'héritage (DIT, NOA, NOD), des métriques de couplage (CBO, NOI, NA) et les versions moyennes de ces métriques.
Analyse statistique :
- Analyse de corrélation : Le coefficient de corrélation de rang de Spearman a été utilisé pour évaluer les relations monotones et pour identifier les redondances parmi les métriques elles-mêmes.
- Comparaison de groupes : Le test de Mann-Whitney U a été employé pour déterminer si la distribution des valeurs des métriques différait significativement entre les contrats vulnérables et neutres.
- Taille de l'effet : Le Delta de Cliff ( $\delta$ ) a été calculé pour quantifier l'ampleur de la différence entre les deux groupes.
- Intervalles de confiance : Utilisés pour comparer la tendance centrale (moyennes) des métriques entre les groupes vulnérables et neutres.

Principales contributions
L'article aborde quatre questions de recherche (RQ) spécifiques pour évaluer l'utilité des métriques de complexité :

RQ1 (Interdépendance des métriques) : L'étude identifie une redondance significative parmi certaines métriques. Par exemple, le SLOC est fortement corrélé avec le NOI, le NOS, le WMC et le NF. De même, les métriques d'imbrication (NL, NLE) et leurs moyennes présentent une corrélation élevée, suggérant que toutes les 21 métriques ne fournissent pas d'informations uniques pour la détection de vulnérabilités.
RQ2 (Corrélation métrique-vulnérabilité) : L'analyse révèle que, bien que les 21 métriques présentent une corrélation statistiquement significative ( $p < 0,05$ ) avec la présence de vulnérabilités, la force de ces corrélations est généralement faible (coefficients principalement inférieurs à 0,3). Cela contraste avec les résultats obtenus dans les langages de programmation traditionnels où les corrélations sont souvent plus fortes. Par conséquent, aucune métrique isolée ne constitue un prédicteur fort en soi.
RQ3 (Pouvoir discriminatif) : Malgré de faibles corrélations individuelles, le test de Mann-Whitney U confirme que toutes les métriques peuvent statistiquement distinguer les codes vulnérables des codes neutres ( $p < 0,05$ ). La plupart des métriques présentent une taille d'effet importante (ex: SLOC, LLOC, NF, WMC, NL, NOS, CBO, NA, NOI), indiquant que les distributions de ces métriques sont pratiquement différentes entre les deux groupes.
RQ4 (Directionnalité de la différence) : L'étude conclut que les contrats vulnérables présentent généralement des scores de complexité moyenne plus élevés que les contrats neutres pour la majorité des métriques. Cependant, il existe trois exceptions notables où les contrats vulnérables ont des valeurs plus faibles :
- CLOC (Lignes de commentaires) : Les contrats neutres possèdent plus de commentaires, suggérant que la documentation peut atténuer la vulnérabilité.
- NOD (Nombre de descendants) : Les contrats vulnérables ont moins de descendants.
- Avg. NUMPAR (Moyenne des paramètres) : Les contrats vulnérables ont moins de paramètres en moyenne.

Résultats et portée
L'article conclut que les métriques de complexité sont des indicateurs plutôt que des causes directes de vulnérabilité. La principale portée des résultats réside dans les points suivants :

Utilité collective : Bien que les métriques individuelles aient un faible pouvoir prédictif, l'étude démontre que lorsqu'elles sont analysées collectivement, les métriques de complexité possèdent de fortes capacités discriminantes. Cela soutient leur utilisation comme caractéristiques complémentaires dans les outils de détection automatisée de vulnérabilités.
Gestion de la redondance : L'identification de métriques hautement corrélées (ex: SLOC vs WMC vs NF) suggère que les modèles de prédiction de vulnérabilité peuvent être optimisés par la sélection d'un sous-ensemble de caractéristiques non redondantes, améliorant ainsi l'efficacité sans sacrifier la précision.
Nuance contextuelle : Les conclusions mettent en évidence des caractéristiques uniques de Solidity par rapport au logiciel traditionnel. Par exemple, la relation inverse avec la densité de commentaires (CLOC) suggère que, dans le contexte des contrats intelligents, l'absence de documentation est un marqueur de risque spécifique.
Application pratique : Les auteurs proposent que ces métriques puissent être intégrées aux outils d'analyse statique existants pour prioriser les efforts d'audit. Les contrats présentant des scores de complexité élevés peuvent être signalés pour une revue manuelle approfondie, et les développeurs peuvent utiliser ces informations pour adhérer aux meilleures pratiques telles que la minimisation de l'imbrication, la réduction du couplage et la garantie d'une documentation adéquate.

Les auteurs maintiennent une position modeste, soulignant que les relations observées sont des associations statistiques. Ils reconnaissent qu'une complexité élevée est souvent corrélée à un domaine de problème plus large (par exemple, les protocoles DeFi complexes nécessitent naturellement plus de code), ce qui peut être le moteur sous-jacent de l'augmentation du risque de vulnérabilité plutôt que les métriques de complexité elles-mêmes étant le seul mécanisme causal. Des travaux futurs sont suggérés, incluant la stratification spécifique au domaine et l'exploration des métriques de complexité cognitive.