Giovanni Vignone, PDG & fondateur d’Octane Security – Série d’interviews

Giovanni Vignone, PDG et fondateur d’Octane Security, a lancé l’entreprise en 2022 pour répondre au besoin croissant de cybersécurité proactive dans le Web3. À seulement 22 ans, il a entrepris de créer une plateforme alimentée par l’IA qui fonctionne comme un ingénieur sécurité 24/7 — analysant les bases de code de contrats intelligents en temps réel, s’intégrant directement aux pipelines CI/CD, et détectant les vulnérabilités que les audits traditionnels manquent souvent.

Dans cette conversation, nous explorons la mission d’Octane d’intégrer une détection continue et explicable des vulnérabilités dans le cycle de vie du développement logiciel — et ce qu’il faut pour sécuriser l’avenir des contrats intelligents.

Qu’est-ce qui a inspiré la décision de quitter Duke et de créer Octane à plein temps ? Y a-t-il eu un moment particulier qui a clarifié l’opportunité ?

Pendant ma troisième année à Duke, j’ai obtenu un accès bêta anticipé à la plateforme d’OpenAI et j’ai commencé à expérimenter avec de grands modèles de langage sur les contrats intelligents dans la cryptomonnaie. Les résultats m’ont vraiment ouvert les yeux sur ce qui était possible.

Il y a eu un moment précis qui se démarque. J’ai introduit un contrat intelligent dans l’interface de chat et lui ai demandé de trouver des problèmes. Les résultats nécessitaient du travail, mais j’ai immédiatement vu le potentiel énorme d’utiliser les LLM pour détecter des vulnérabilités difficiles à trouver. C’était en mars 2023.

Cela s’est produit à la même période où je constatais toutes ces attaques et exploits dans l’ensemble de l’industrie. J’ai réalisé qu’il y avait un besoin urgent de résoudre ces problèmes de sécurité, et ces modèles nous offraient une manière unique de les aborder. J’ai tout de suite compris que c’était le bon moment pour se lancer à fond dans Octane.

Quels ont été certains des plus grands défis techniques ou opérationnels pour passer d’Octane en concept à son adoption par les grandes entreprises crypto ?

Le plus grand défi technique était de déterminer comment identifier les vulnérabilités et les présenter aux utilisateurs de manière exploitable. C’était très difficile car les vulnérabilités ne sont pas en noir et blanc — elles ont plusieurs dimensions.

Lorsque nous examinons une vulnérabilité potentielle, nous devons prendre en compte plusieurs éléments : quel est l’impact (quelqu’un pourrait-il perdre de l’argent ou un état important ?), quelle est la facilité d’exploitation, quelles mesures peuvent être prises pour la corriger, et quelle est la cause première du problème. Gérer tous ces aspects simultanément et les présenter clairement a demandé beaucoup de travail.

Nous avons consacré énormément d’efforts à transformer chacun de ces composants en produit afin que les clients puissent utiliser Octane pour détecter les vulnérabilités, comprendre rapidement leur gravité et commencer à les corriger immédiatement. Concevoir des systèmes capables de repérer de façon constante ces problèmes dans différents bases de code a nécessité à la fois une expertise technique et de nombreuses données sur toutes sortes de vulnérabilités.

Octane vise à fonctionner comme un ingénieur sécurité IA intégré à chaque équipe de développement. Quels jalons sont nécessaires pour réaliser pleinement cet objectif à l’échelle de l’industrie ?

Notre premier grand jalon consiste à changer la façon dont les développeurs perçoivent la sécurité — les inciter à l’intégrer dès le premier jour plutôt que de l’ajouter quelques semaines avant le lancement. Cela signifie leur montrer que commencer par la sécurité permet réellement de gagner du temps en leur permettant de corriger les problèmes plus tôt.

Nous devons également aider les utilisateurs à voir et à comprendre ce qui se passe lorsqu’ils détectent les vulnérabilités tôt, afin qu’ils puissent expérimenter les avantages directement.

Du côté du produit, nous devons prendre en charge davantage de langages au-delà de Solidity — d’autres langages de contrats intelligents et, à terme, les langages de programmation classiques. Nous travaillons constamment à améliorer la précision de nos modèles et à détecter davantage de types de vulnérabilités.

Comment la plateforme évoluera-t-elle pour traiter les menaces complexes non basées sur le code, comme le phishing ou les exploits basés sur des logiciels malveillants ?

Nous gérons déjà certaines de ces menaces aujourd’hui. Nous signalons les risques de centralisation, ce qui aide les équipes à identifier les clés privées et les rôles particulièrement sensibles.

Nous détectons également les schémas de phishing courants dans les contrats intelligents, comme l’utilisation de tx.origin pour la logique de vérification de l’appelant, ce qui peut conduire à des attaques de phishing. Nous veillons à signaler cela aux utilisateurs.

Actuellement, Octane fonctionne principalement comme un outil de sécurité pré‑déploiement plutôt que comme un système qui détecte les menaces en temps réel. Notre plan est de continuer à élargir ce que nous pouvons détecter avant que le code ne soit mis en production, en donnant aux développeurs les outils pour corriger les problèmes potentiels avant qu’ils ne deviennent de véritables attaques.

Qu’est-ce qui rend l’apprentissage automatique non supervisé — en particulier le clustering — une approche plus efficace pour classer les vulnérabilités des contrats intelligents que les systèmes traditionnels basés sur des règles ?

L’apprentissage automatique non supervisé nous a vraiment aidés à cartographier les différents types de bugs existants. Bien que nous utilisions encore des techniques basées sur des règles pour construire nos modèles supervisés, l’apprentissage non supervisé, en particulier le clustering, nous aide à déterminer quels modèles nous devrions créer et comment les prioriser.

Cette approche nous permet de décomposer nos modèles en pipelines d’analyse plus spécialisés pour différents types de vulnérabilités.

Nous utilisons en fait à la fois le ML supervisé et non supervisé — l’apprentissage non supervisé pour comprendre le paysage et les méthodes supervisées pour créer des capacités de détection précises. Cette combinaison fonctionne mieux que de se fier uniquement aux systèmes traditionnels basés sur des règles.

Pouvez-vous partager un exemple où le clustering a mis en évidence une nouvelle classe de vulnérabilités qui n’avait pas été reconnue auparavant dans les audits ou les revues de sécurité ?

Le clustering ne crée pas réellement de nouvelles catégories de vulnérabilités à partir de zéro — il prend des données existantes et les regroupe de manière significative. Nos données proviennent d’exploits en chaîne réels, de rapports de vulnérabilité publics et d’autres sources de bugs de contrats intelligents.

Ce que l’apprentissage non supervisé fait très bien, c’est qu’il nous aide à affiner notre compréhension des catégories de vulnérabilités existantes. Il repère des motifs et des connexions entre différentes vulnérabilités qui pourraient autrement passer inaperçus, ce qui nous permet de créer de meilleures méthodes de détection.

Grâce à cette reconnaissance de motifs et à ce regroupement de données, nous avons créé des modèles plus nuancés capables de détecter des variations subtiles de types de vulnérabilités connus, plutôt que de découvrir des classes totalement nouvelles de vulnérabilités.

Comment Octane gère-t-il les cas limites où une vulnérabilité ne correspond pas clairement aux catégories existantes de la taxonomie ?

Nous essayons d’équilibrer le niveau de spécificité de notre taxonomie. Plus nos catégories et modèles sont généraux, mieux nous pouvons détecter les cas limites étranges qui ne s’intègrent nulle part. En revanche, des catégories plus spécifiques offrent aux utilisateurs de meilleures explications et nous permettent de détecter les types de bugs connus de manière plus cohérente.

Lorsque nous rencontrons des vulnérabilités qu’Octane ne détecte pas ou qui ne correspondent pas clairement à nos catégories existantes, nous évaluons s’il faut ajouter davantage de données sur cette vulnérabilité à un modèle existant, ou s’il est nécessaire de créer un tout nouveau modèle pour détecter ce type de bug à l’avenir.

Cette approche flexible nous permet d’améliorer continuellement nos capacités de détection tout en conservant un cadre qui a du sens pour les utilisateurs.

Après avoir analysé des milliers de bugs, quels schémas récurrents ou causes profondes se sont démarqués parmi les vulnérabilités des contrats intelligents ?

Nous avons observé plusieurs schémas récurrents. La réentrance reste un problème majeur dans les contrats intelligents. Une autre grande catégorie provient du fait que les transactions sont visibles publiquement dans le mempool, ce qui crée des vulnérabilités où les attaquants peuvent voir les transactions en attente et voler des informations ou provoquer l’échec des transactions — ce que l’on appelle le front‑running, bien que cela se produise de nombreuses manières différentes.

Nous avons également découvert de nombreuses vulnérabilités critiques provenant d’erreurs simples des développeurs. Celles‑ci étaient auparavant largement appelées « erreurs de logique », mais cela reste trop vague. Une erreur courante que nous observons est que les développeurs oublient de mettre à jour les variables d’état dans certains chemins de code où cela est réellement nécessaire.

Ce ne sont que quelques exemples — nous disposons d’une analyse privée beaucoup plus détaillée de tous les bugs que nous avons développée grâce à nos efforts d’analyse de données.

Les contrats intelligents varient largement selon les écosystèmes et les langages. Comment Octane garantit‑il que ses modèles restent efficaces dans ces environnements diversifiés ?

De nombreuses vulnérabilités suivent des schémas communs, quel que soit le langage ou l’écosystème spécifique. Cela nous permet de créer des modèles capables de détecter efficacement ces vulnérabilités dans différents bases de code.

Nous concevons nos modèles pour se concentrer sur les principes de sécurité de base qui s’appliquent largement aux systèmes de contrats intelligents, tout en tenant compte des spécificités de chaque langage. Cette approche nous aide à rester efficaces dans divers environnements sans devoir tout reconstruire pour chaque nouveau langage.

En nous concentrant sur les schémas fondamentaux des vulnérabilités plutôt que sur les détails superficiels, nous avons construit des modèles capables de s’adapter au monde diversifié du développement de contrats intelligents.

Les outils de sécurité basés sur l’IA font souvent l’objet de scepticisme concernant leur explicabilité. Comment Octane garantit‑il que les classifications de vulnérabilités et les alertes sont exploitables pour les développeurs ?

Nous avons consacré beaucoup d’efforts à notre processus de validation back‑end pour vérifier les vulnérabilités grâce à des contrôles supplémentaires.

Nous trions soigneusement nos découvertes afin de séparer les vulnérabilités critiques (qui pourraient réellement impacter le code) des problèmes moins graves ou des avertissements représentant les meilleures pratiques. Cette catégorisation aide les développeurs à se concentrer sur ce qui compte le plus.

Notre interface utilisateur est conçue pour être simple et claire, mettant en avant les problèmes les plus graves afin qu’ils reçoivent une attention immédiate plutôt que d’être enfouis parmi de nombreuses alertes moins importantes. En fournissant des explications claires et en se concentrant sur ce qui est exploitable, nous nous assurons que les développeurs comprennent rapidement et corrigent les vulnérabilités que nous détectons.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter Octane Security.