Publié le

L’équipe de sécurité qui ne dort jamais : 0.security et la fin du pentest annuel

Auteurs

Listen in English · L’équipe de sécurité qui ne dort jamais : 0.security et la fin du pentest annuel

0:00 / 0:00

Watch in English · L’équipe de sécurité qui ne dort jamais : 0.security et la fin du pentest annuel

0.security, au sein de la promotion Automne 2026 de Y Combinator, vend une équipe de sécurité autonome : tests sur les pull requests, tests d’intrusion continus et correctifs livrés dans la même PR. Le pari est que l’IA écrit désormais du code plus vite que les audits annuels ne peuvent le vérifier — et que c’est l’étape de vérification, et non le scan, qui est la partie difficile.

Les tests de sécurité ont toujours fonctionné selon un calendrier. Une fois par an, parfois deux, un cabinet externe passe une semaine avec l’application, rédige un rapport, et l’équipe passe un trimestre à le traiter. Le temps que la dernière constatation soit close, le code source a changé entre-temps.

Ce modèle supposait que les logiciels changeaient lentement. Ce n’est plus le cas. Une équipe utilisant des agents de codage livre en une semaine ce qui prenait autrefois un trimestre, et chacun de ces changements constitue une nouvelle surface. Un test annuel décrit désormais un système qui n’existe plus.

0.security est l’une des entreprises de la promotion Automne 2026 (F26) de Y Combinator, bâties sur ce manque. Sa description est directe : une équipe de cybersécurité autonome. Le produit exécute des tests de sécurité sur les pull requests, maintient un pentest continu contre les systèmes en production, surveille les dépendances au regard des vulnérabilités nouvellement divulguées et — la partie qui compte commercialement — livre un correctif dans la même pull request, appliqué en un clic.

  1. Indexer la base de code

    Un graphe des dépôts, des dépendances et de l’infrastructure, ainsi que les conventions que l’équipe applique déjà.

  2. Envoyer des agents détecter et corriger

    Des agents parallèles enquêtent comme un attaquant, puis préparent un correctif plutôt qu’un ticket.

  3. Vérifier en isolation

    Les constats sont reproduits dans des environnements isolés afin que seuls les problèmes confirmés parviennent à l’équipe.

  4. Transmettre le contexte

    L’architecture et les constats passés alimentent l’enquête suivante, ce qui la rend moins coûteuse au fil du temps.

Le flux de travail tel que l’entreprise le décrit : trouver, vérifier, corriger, mémoriser.

Pourquoi l’étape de vérification constitue tout le produit

Le scan coûte peu, et c’est le cas depuis dix ans. Ce qui n’a jamais coûté peu, c’est de savoir quelles alertes comptent. Un scanner qui signale deux cents résultats et se trompe sur la moitié d’entre eux ne réduit pas le risque ; il consume l’attention de la seule personne qui aurait pu corriger le véritable problème.

L’affirmation intéressante ici n’est pas que l’IA peut trouver des bugs. C’est qu’on peut faire en sorte que l’IA les prouve. 0.security affirme que les agents reproduisent les constats dans des environnements isolés et vérifient le correctif avant qu’il ne soit proposé, et que c’est ainsi qu’ils filtrent les faux positifs. Si cela tient, cela fait passer l’unité de travail de « un rapport à trier » à « un patch à relire ».

La recherche publique de l’entreprise constitue la preuve sur laquelle elle s’appuie. Son site répertorie les vulnérabilités divulguées dans le noyau Linux et un long ensemble de piles de fournisseurs — AMD, Qualcomm, Cisco, Arm, Google, Meta, IBM, NVIDIA, Intel, Red Hat — avec le type de traçabilité des revues que les ingénieurs en sécurité reconnaissent. Elle publie également son harnais de test en open source et affirme que plus de trois milliards d’appareils exécutent des logiciels qu’elle a contribué à sécuriser. Ce sont des affirmations de l’entreprise, et non des chiffres audités indépendamment, mais les liens de divulgation sont vérifiables d’une manière que les textes marketing ne sont généralement pas.

15min
aux premiers résultats après la connexion d’un dépôt, comme l’entreprise le décrit pour l’intégration
1
cliquez pour appliquer un correctif, fourni dans la pull request qui a introduit le problème
24/7
la surveillance des dépendances et des CVE, plutôt qu’un balayage trimestriel

Couverture du film ABN Asia sur 0.security et les tests de sécurité continus

La course aux armements que personne n'a demandée

Le contexte inconfortable est que la même capacité existe de l'autre côté. Les attaquants utilisent des modèles pour lire le code, trouver des faiblesses et écrire des exploits, à la même vitesse à laquelle les défenseurs peuvent désormais les utiliser pour les combler. Une entreprise qui adopte l'IA pour l'ingénierie et conserve une revue de sécurité annuelle a automatisé la moitié de l'équation.

C’est l’argument en faveur des tests continus en une phrase : si le code change chaque jour, la posture de sécurité doit être évaluée chaque jour, sinon l’écart entre ce que vous avez livré et ce que vous avez vérifié se creuse chaque semaine.

  1. Test annuel

    Un instantané d’une semaine, facturé par projet, valable jusqu’au prochain cycle de version.

  2. Tester à chaque changement

    La pull request devient l’unité de revue, de sorte que le contrôle a lieu là où le risque est introduit.

  3. Corriger au même endroit

    Un correctif dans la PR vaut mieux qu’un PDF sur un lecteur partagé, car il est relu par la personne qui a écrit le code.

  4. Garder la mémoire

    Ce qui a été trouvé le mois dernier devrait rendre l’investigation du mois prochain plus courte — sinon vous louez deux fois le même travail.

La revue continue n'est pas un test annuel plus gros ; c'est une unité de travail différente.

Ce qu’un acheteur devrait encore demander

Trois questions, et aucune ne porte sur la qualité du modèle.

À qui appartient le résultat ? Un outil qui consigne les constats est un scanner. Un outil qui corrige le code apporte des modifications aux systèmes de production, et quelqu’un au sein de l’entreprise doit assumer cette décision. Dans une entreprise sans dirigeant à la sécurité, ce responsable est généralement absent — c’est ce même manque qui rend utile de faire appel à un RSSI à temps partagé.

Quel est le taux de faux positifs sur notre code ? Demandez un essai sur un dépôt dont vous connaissez déjà les failles. Les affirmations de vérification sont faciles à formuler et coûteuses à prouver.

Que se passe-t-il lorsque le modèle se trompe dans l’autre sens ? Une vulnérabilité manquée est pire qu’une vulnérabilité bruyante, et aucun fournisseur ne garantira le rappel.

0.security en est au début : une entreprise de la promotion automne 2026, une petite équipe et des affirmations qui seront testées par les clients plutôt que par un communiqué de presse. Mais la structure de l’argument est juste, et c’est celle vers laquelle toute la promotion pointe — l’IA crée le problème à la vitesse de la machine, donc la réponse doit elle aussi fonctionner à la vitesse de la machine.

Le test d'intrusion annuel n'est pas mort parce qu'il était mauvais. Il est mort parce qu'il décrit une base de code qui a cessé d'exister en février.

Source : la liste des entreprises Y Combinator F26, le site public et les divulgations de recherche de 0.security, novembre 2026. Les déclarations de l'entreprise sont attribuées comme telles.

Contact : [email protected]

Veuillez noter que la version française est assistée par Ai, des erreurs mineures peuvent donc exister.

Auteur

Ai-Banking-NetworkSecurity (ABN), ABN ASIA a été fondée par des personnes ayant des racines profondes dans le milieu académique, avec une expérience professionnelle aux États-Unis, aux Pays-Bas, en Hongrie, au Japon, en Corée du Sud, à Singapour et au Vietnam. ABN ASIA est l'endroit où l'académie et la technologie rencontrent l'opportunité. Avec nos solutions de pointe et nos services de développement logiciel compétents, nous aidons les entreprises à se développer et à s'imposer sur la scène mondiale. Notre engagement : Plus vite. Mieux. Plus fiable. Dans la plupart des cas : moins cher également.

N'hésitez pas à nous contacter chaque fois que vous avez besoin de services informatiques, de conseils en matière de numérique, de solutions logicielles prêtes à l'emploi, ou si vous souhaitez nous envoyer des demandes de propositions (RFP). Vous pouvez nous contacter à l'adresse [email protected]. Nous sommes prêts à vous aider avec tous vos besoins technologiques.

ABNAsia.org

© ABN ASIA