Plus tôt ce mois-ci, nous avons remporté une prime de bug bounty de 2,5 millions de dollars – la plus grosse prime jamais obtenue par un agent IA. Il s'agissait d'un bug dans une grande blockchain, qui a mis plus de 100 millions de dollars de fonds en danger. Nous avons trouvé ce bug de manière entièrement autonome grâce à V12, notre agent de sécurité IA, et avons travaillé en collaboration avec l'équipe pour résoudre le problème.
V12 n'est pas un outil de sécurité agentique générique. Il détecte régulièrement des bugs critiques de ce type, parmi d'innombrables 0days (notamment des LPE Linux, une évasion QEMU, des UXSS sur Firefox, et des RCE bidirectionnelles sur Postgres et Redis). C'est parce que, tout en construisant un produit, notre mission principale est de rechercher et de développer des outils de sécurité offensive redoutablement puissants. Pour y parvenir, nous avons levé un tour de table seed de 10 millions de dollars mené par Electric Capital, avec la participation de ZachXBT, samczsun, Walden Yan et d'autres.
Nous vous encourageons à essayer V12 vous-même. C'est en libre-service, et vous bénéficierez de 200 dollars d'utilisation gratuite à l'inscription pendant les sept prochains jours.
Partie 1 : Ce que nous faisons
Notre objectif est de construire une cyber-arme nucléaire. Cela signifie construire quelque chose capable de trouver tous les bugs d'un système. C'est particulièrement intéressant, car une telle capacité permettrait d'exploiter des logiciels jusqu'alors considérés comme sécurisés. Cela n'avait pas été possible jusqu'ici, mais l'IA de pointe change la donne.
Nous ne faisons pas de pentest. Le pentest en boîte noire qui simule un attaquant externe ne nous intéresse pas. C'est un marché saturé, et nous ne voulons pas créer un énième produit qui envoie des payloads XSS. Un pentest agentique est excellent pour trouver certains bugs, mais ce que nous voulons, c'est quelque chose qui trouve tous les bugs. Cela n'est pas possible sans lire et comprendre le code. Nous devons nous concentrer sur l'audit de code en boîte blanche, ce qui s'apparente davantage à de la recherche de vulnérabilités.
crédit mème : LiveOverflow
Plus concrètement, cela ressemble à un système capable de raisonner sur le code et toutes les abstractions sous-jacentes, voire d'en créer de nouvelles (par exemple les weird machines). Nous voulons un système qui ne se contente pas de trouver des bugs, mais qui peut inventer des classes de bugs entièrement nouvelles. Cela dit, c'est aussi le domaine de la sécurité qui a le plus résisté à l'automatisation. Une grande partie de la recherche de vulnérabilités consiste à raisonner soigneusement sur le code et à se prouver « non, ça ne peut pas être bugué » ou, à l'inverse, à se demander « attends, et si… ? » Tout cela nécessite une intelligence de niveau humain, qu'il n'a pas été possible de faire évoluer à grande échelle jusqu'à présent.
Bref, ce que nous voulons, c'est un système d'IA qui absorbe une base de code arbitrairement vaste et complexe, comprend comment elle fonctionne réellement, puis utilise cette compréhension pour inventer – pas seulement découvrir – des bugs et des exploits.
Bien sûr, un système capable de vraiment trouver tous les bugs n'est pas réellement possible ; c'est le problème de l'arrêt déguisé. C'est équivalent à prouver qu'un programme n'a pas de bugs, les exploits servant de contre-exemples. On peut créer des programmes arbitrairement difficiles à exploiter. Par exemple, un programme vulnérable si la conjecture de Collatz est fausse. Mais nous avons l'intention de repousser les limites et de construire l'approximation la plus proche qui soit pratiquement possible.
Et personne pour nous guider
Imaginons que nous construisions réellement cette cyber-arme nucléaire. Et maintenant ?
Face à une explosion des capacités offensives, le monde va changer radicalement. Cependant, il est irréaliste de s'attendre à ce que les développeurs – en particulier les entreprises – s'adaptent soudainement par eux-mêmes. Les organisations matures manquent de vision ou d'expertise pour opérer ce changement correctement. Elles ont aussi besoin de solutions – des produits fonctionnels et bien conçus – pas simplement de « fourre-tout d'outils ».
Concernant la capacité d'adaptation des organisations : il est facile de pointer du doigt les nouveaux modèles de pointe et de prétendre que la cybersécurité est résolue. C'est autre chose que de permettre aux développeurs d'exploiter réellement les modèles pour sécuriser leur code. Le développeur moyen demande encore à Claude ou Codex de « relire ma PR pour trouver des bugs » puis « OK corrige-les ». C'est loin d'être suffisant ! Les attaquants utilisent déjà des harnais et des pipelines complexes et agressifs de détection de bugs. Il y a une asymétrie ici. Les défenseurs n'ont ni les ressources pour créer ces pipelines, ni la possibilité d'amortir le coût sur de nombreuses cibles de chasse aux bugs. Ils ont besoin que quelqu'un exploite, canalise et déploie ces modèles pour libérer tout leur potentiel.
Pendant ce temps, les gens sont occupés. Ils sont débordés à essayer de respecter les délais et de livrer les fonctionnalités prévues. Ils n'ont pas le temps de penser à la sécurité ; ils veulent que quelqu'un – ou quelque chose – vienne la régler à leur place. Le produit devrait s'intégrer directement dans leur organisation (par exemple dans leur Slack), comprendre leur flux de travail (utilisez-vous Github ? comment les bugs sont-ils assignés ? qu'utilisez-vous pour le suivi des tickets ? quels agents utilisez-vous ?), et sembler adapté à leur contexte.
Pour la même raison, les défenseurs perdent s'ils n'ont pas un produit utile dès sa sortie de boîte. Il doit être soit entièrement en libre-service, soit accompagné d'un déploiement « white glove ». Il doit avoir le bon facteur de forme (un CLI ? un MCP ? un agent Slack ? un bot Github ? tout à la fois ?) ; il doit être agréable à utiliser (pas de latence, fonctionne sur mobile, boutons là où on les attend, …) ; il doit avoir du sens (modèle de facturation non agressif, contrôle d'accès approprié, sélection logique du périmètre d'audit, …). Il y a un million de choses à réussir pour qu'un tel produit soit réellement adopté.
Bref : construire quelque chose qui absorbe des programmes arbitrairement complexes, les analyse en profondeur et trouve des bugs inédits. Puis intégrer cette capacité dans un produit utile, et prendre les développeurs par la main pour qu'ils puissent réellement l'utiliser et en tirer profit.
Partie 2 : Ce en quoi nous croyons
OK, alors comment y parvenir concrètement ? Tout plan d'action détaillé est inutile (nous sommes une entreprise au stade seed). Il est plus pertinent d'exposer nos principes directeurs et notre vision de l'évolution du monde.
Contre le « safetyisme »
D'abord, nous croyons que le moyen le plus efficace de sécuriser les logiciels du monde est de donner à tous des capacités de détection de bugs. Nous ne croyons pas au « contactez-nous » ni à la « demande d'accès ». L'état final logique est un monde où tous les bugs sont trouvés et corrigés. Restreindre l'accès ne fait que ralentir ce processus. Pour les mainteneurs, s'adapter à un nouveau paysage de menaces est inconfortable mais inévitable, et nous pensons que la meilleure approche est simplement de trouver tous les bugs dès maintenant.
Pour être clair, nous voulons que les logiciels soient sûrs et dignes de confiance. Il est irresponsable de déchaîner des capacités offensives pour lesquelles le monde n'est pas préparé. Mais une grande partie de l'« accès contrôlé » ou de la « vérification cyber » que nous voyons récemment n'est que posture et marketing. Certains utilisent les préoccupations de sécurité comme prétexte pour ne donner accès à personne – et ce faisant, ne protègent personne à grande échelle. Cette année seulement, V12 a protégé ses utilisateurs avec plus de 6 000 audits de sécurité. Nous ne sommes pas contre la sécurité, nous sommes contre le simulacre de sécurité.
Divulgation ouverte
Nous croyons en la divulgation ouverte. La divulgation responsable sera considérée comme une méthode obsolète de signalement et de correction des bugs. Les embargos et la divulgation coordonnée n'ont plus de sens dans un monde où n'importe qui, avec les bons outils, peut trouver et armer une vulnérabilité avec une intervention ou une expertise humaine minimale. Nous l'avons constaté lorsque nous avons découvert et signalé Fragnesia, Pintheft et DirtyDecrypt – des 0days LPE Linux qui ont fini par fuiter avant même que les correctifs n'atteignent les noyaux mainline. N'importe qui peut surveiller les commits publics et recréer trivialement un exploit armé. La seule vraie solution est d'éliminer complètement le patch gap. En pratique, cela se traduit par des mises à jour plus fréquentes (et automatiques) et par des éditeurs qui publient des correctifs le jour même (l'heure même !) où un bug est trouvé. Plus précisément, cela signifie que les défenseurs ont besoin de capacités exceptionnelles de génération de PoC et de correctifs.
Les bug bounties sont morts
Les bug bounties sous leur forme actuelle seront morts, à l'exception des programmes d'acquisition de vulnérabilités pour les bugs exceptionnellement précieux. Tous les autres bugs seront extraits par des outils cyber offensifs comme V12 avant même que le code ne soit livré, c'est-à-dire avant que les attaquants n'aient une chance de commencer à chercher.
Les mainteneurs plient sous le poids des soumissions de bug bounty générées par l'IA. Beaucoup ont annoncé qu'ils mettaient fin aux bug bounties. Maintenant que les bugs sont devenus moins chers que jamais, les seules solutions sont soit (1) cesser de se soucier de la plupart des bugs, soit (2) cesser de les livrer. Par le passé, les deux étaient intenables car, bien que pratiquement tout code soit imparfait, raisonner sur tous les bugs possibles était prohibitif en temps et en coût. Mais aujourd'hui, nous croyons que c'est non seulement possible, mais inévitable.
La sécurité crypto est intéressante
Les projets crypto sont des cibles intéressantes et un point d'entrée important pour notre entreprise. Nous sommes obsédés par la recherche de tous les bugs, et la crypto est actuellement l'endroit où cela compte le plus. Plus de 500 millions de dollars ont été volés lors de piratages rien que cette année. Si V12 peut réussir dans la crypto – si nous pouvons gagner en « mode difficile » – alors nous pouvons gagner partout.
À quelques exceptions près (iOS full chain ?), aucun bug hors crypto n'offre des primes à sept ou huit chiffres. Hors de la crypto, 50 000 $ est encore considéré comme une prime énorme. Dans la crypto, une vulnérabilité critique de perte de fonds vaut des centaines de millions de dollars si elle est exploitée. En général, personne ne veut prendre la sécurité au sérieux, mais les entreprises crypto y sont obligées. Cela signifie que lorsqu'elles choisissent leurs produits de sécurité, elles privilégient la capacité à trouver des bugs plutôt que les tableaux de bord – exactement ce pour quoi V12 est optimisé. Pendant ce temps, hors de la crypto, la sécurité tourne encore autour d'une culture de conformité, et non de substance.
Tous les logiciels sont vulnérables, mais le monde agit comme si ce n'était pas le cas. Cela n'a fonctionné jusqu'ici que parce que les attaquants étaient rares – la compétence technique était le facteur limitant. L'IA supprime cette contrainte. Désormais, si un logiciel n'est pas sécurisé, il SERA exploité.
L'impact est amplifié par le fait que le monde est de plus en plus connecté, et qu'une grande partie du monde existe désormais réellement « dans un ordinateur ». Tout devra devenir beaucoup plus sécurisé très rapidement, ce qui signifie que beaucoup plus d'équipes devront prendre la sécurité aussi au sérieux que les entreprises crypto.
Au fait, pour dissiper une idée reçue courante : les bases de code crypto sont loin d'être triviales en taille, complexité et diversité. Firedancer représente 722 000 lignes de code en C hautement optimisé, Geth + Prysm représente 1,1 million de lignes de code en Go, Zcash en compte 304 000 en C++ et Python (le seul Orchard représente 44 000 lignes de circuits et de cryptographie en Rust). Tous ces projets contiennent des machines virtuelles, du code système bas niveau et des bases de données distribuées. Pour donner une idée, Postgres et CPython tournent tous deux autour d'un million de lignes de code.
L'heure de la vraie sécurité
Les logiciels du monde ont toujours été vulnérables, mais il est désormais impossible de l'ignorer. Le web moderne dépend d'une cryptographie et de navigateurs sécurisés, les modèles de pointe s'appuient sur des TEE pour protéger leurs poids, et les innovations en robotique et en biologie ne feront que renforcer l'importance de la sécurité. En clair, tout code devient un jour du code à haute assurance.
N'oublions pas la complexité croissante des chaînes d'approvisionnement logicielles. Beaucoup de code auquel nous ne pensons pas sera (ou est déjà) à haute assurance. OpenSSH vient certainement à l'esprit, mais qu'en est-il de tous les paquets que nous avons oubliés ? Internet dépend de logiciels que personne n'examine.
La façon dont la sécurité est actuellement pratiquée ne fonctionnera pas. C'est une réflexion après coup, réalisée au mieux. Les équipes se concentrent sur le développement de fonctionnalités et font de la sécurité la responsabilité de quelqu'un d'autre. La plupart des produits de sécurité ressemblent à des pansements qui gèrent les symptômes des bugs, pas à de vraies solutions. Mais dans un monde doté d'une IA puissante, s'il ne reste qu'un seul bug, quelqu'un va le trouver et l'exploiter.
Au contraire, la sécurité doit être continue et exhaustive – chaque PR fusionnée doit être exempte de vulnérabilités. Le chemin pour y arriver ne sera pas facile, et nous n'avons pas tout résolu. Personne ne l'a. Mais le problème fondamental auquel tout cela se résume – trouver des bugs – est ce qui nous obsède depuis dix ans. Avant V12, nous avons fondé Zellic, l'un des principaux cabinets de sécurité au monde, avec plus de 1 500 audits de sécurité pour plus de 500 clients fortement attaqués (par exemple des plateformes d'échange crypto, des bridges, des L1, des wallets, des systèmes d'exploitation open source). Et avant cela, nous avons fondé perfect blue, l'équipe de CTF n°1 au monde pendant 3 ans.
Chaque membre de l'équipe V12 vient du monde des CTF ou de la recherche de vulnérabilités. Regardez ce que nous avons déjà signalé : de multiples LPE Linux, une évasion QEMU, des RCE wormables dans Redis et Postgresql (bidirectionnelles !), MariaDB et Anydesk. Et ce qui est encore plus prometteur, c'est que quel que soit le nouveau logiciel auquel nous confrontons V12, les bugs continuent d'affluer : l'émulateur Dolphin, le NAS d'un employé, le messager Signal.
Dernières réflexions
Un bon tour de table seed offre la meilleure chose au monde : la possibilité de construire ce que l'on aime avec ses amis.
Nous rêvons de ce problème – trouver automatiquement tous les bugs – depuis que nous sommes adolescents. Aujourd'hui, l'IA est enfin assez puissante pour que nous puissions nous y attaquer sérieusement. Nous sommes enthousiastes. Si nous avons raison, ce que nous construisons sera redoutablement puissant, et le monde s'adaptera en conséquence.
Nous voulons être ceux qui feront de cette vision une réalité. Si V12 ressemble à quelque chose dont vous voulez faire partie : rejoignez-nous, nous recrutons !
