Bruno:
Avant, la cybersécurité ressemblait un peu à un jeu d'échecs. Chaque coup était pensé, chaque mouvement nécessitait un œil attentif et une équipe solide pour surveiller toutes les cases du plateau. Mais voilà que l'IA a débarqué sur l'échiquier, rajoutant quelques cavaliers supplémentaires dont personne ne connaît spécifiquement les déplacements. Mais alors, comment l'IA a-t-elle changé le cycle de vie des vulnérabilités ? Les failles sortent-elles du bois plus vite qu'on ne peut les patcher ? Et surtout, peut-on confier la sécurité de nos applications à des LLM qui n'ont parfois jamais vu une ligne de cœur fonctionner ? Pour répondre à ces questions qui font transpirer jusqu'au clavier des Red Team, je ne rends ça pas à Néo, mais il s'y connaît, en bug qui sort des sentiers battus. Benoît, bonjour.
Benoit:
Bonjour.
Bruno:
Alors Benoît, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaissent peut-être pas ?
Benoit:
Donc moi c'est Benoît, j'ai 38 ans, je suis dev depuis à peu près 15 ans maintenant. Aujourd'hui je suis CTO et cofondateur d'une boîte en sécurité Application Security qui s'appelle ComteVous où on fait la bulle d'un multi-management IA et c'est, la deuxième boîte dans le domaine de la sécu dans laquelle je bosse c'est un domaine qui est fascinant parce.
Bruno:
Que tu as un rôle, La cyber, c'est effectivement un sujet qui est fascinant. On a déjà fait quelques épisodes autour de ça. C'est vrai qu'il y a un côté un peu... Je ne sais pas si tu le perçois, mais dans le monde des développeurs et développeuses, il y a quand même parfois une impression que le monde de la cyber, c'est un peu une élite. Des gens un peu spéciaux, qui ont des idées un peu folles. Puis il y en a aussi qui sont juste là pour te mettre des murs partout et t'empêcher de bosser. Mais ce que je trouve intéressant, tu viens de nous le dire, c'est la deuxième boîte que tu as créée dans ce monde-là. Et ce que tu m'avais proposé comme épisode, c'est la différence, ce que l'IA a apporté entre ce que ça a changé dans la création d'une boîte cyber. Donc, pour commencer, simplement, est-ce que tu pourrais nous raconter un peu avant l'IA ? Ça ressemblait à quoi de créer une boîte dans le monde de la cybersécurité ?
Benoit:
La cybersécurité, oui, c'est un domaine d'expertise, mais il y a plein de domaines d'expertise, je l'avais donné l'autre. La sécurité, c'est souvent trouver des bugs à des endroits à la frontière des systèmes. Et du coup, c'est pour ça que c'est intéressant, parce que tu vas aller ouvrir des trucs à droite, à gauche, et tu as besoin de comprendre, d'ouvrir le capot, moi j'aime bien dire ouvrir le capot, de deux systèmes en même temps pour dire « Ah oui, mais en fait, quand lui, il fait ça, lui, il comprend pas forcément. » Et donc, oui, il y a des gens qui sont exceptionnels et qui disent la matrice en clair. Je ne dis pas la matrice mais il y a beaucoup il y a aussi des gens qui vraiment sont sur la sécu un peu administrative gouvernance, machin qualifié, standardisé et, la première boîte dans laquelle j'étais on était sur de l'application aussi déjà où, en fait c'est que tu es quand même dans un domaine tu as besoin d'aller comprendre comment une app marche, comment elle fonctionne ce qu'on faisait à l'époque, c'est de la protection d'ailleurs tu avais reçu notre site IO à l'époque JB Avia, je sais pas quel numéro d'épisode malheureusement désolé.
Bruno:
JB était venu sur deux épisodes on en a fait deux, il y en avait un notamment où il nous avait raconté justement une faille qui était dans, Screen, l'entreprise qu'il avait effectivement confondée à l'époque et t'évoquais ce truc où t'as deux systèmes qui communiquent et ce qui était assez fou dans cette faille que lui évoquait c'était un alignement de trois planètes, en fait il y avait les trois failles qui a exploité dans le bon sens, dans le bon ordre et dans une bonne séquence qui faisait une phase, ce qui signifie quand même un niveau de complexité assez élevé.
Benoit:
Un peu abyssale et qui du coup n'est pas forcément facile à exploiter derrière, c'est ce qui est un peu le... on en reparlera après, mais c'est un peu ce qu'on fait chez nous là. Et du coup, le avant-après, en fait, avant, tu as vraiment besoin de déjà comprendre beaucoup plus comment marchent les choses. Oui, tu vas toujours écrire beaucoup de codes. Tu as besoin de... D'être un peu plugé dans le système tout le temps, de suivre tout ce qui se passe, aujourd'hui, en fait, sommariser de l'information, faire des résumés, tout ça, l'IA marche vachement bien. Et donc, en fait, pour moi, c'est un démultiplicateur de puissance. Si tu fais n'importe quoi, avec de l'IA, tu feras toujours n'importe quoi. Mais tu feras dix fois plus n'importe quoi. Si tu faisais les choses bien, entre guillemets, bien évidemment. Et bien, ça va t'aider à faire dix fois plus. Et donc, typiquement, nous, par exemple, où on lit beaucoup de vulnérabilités chez Scrinon, vous avez un peu ce genre de choses aussi. En fait, aujourd'hui, on va laisser le LLM les lire, première fois, faire de la catégorisation, ce genre de choses, et on va le vérifier. Et en fait, il y a quand même une différence entre vérifier et créer le contenu. C'est quand même vachement plus dur de créer le contenu initialement. Il faut bien écrire le machin. Alors que tu lis, tu dis, ouais, ok, c'est bon, ça passe. Ça va te permettre d'avancer beaucoup plus vite. Après, donc ça, c'est très sécu. il y a beaucoup de tâches humaines comme ça, qui sont un peu mieux via l'IA et il y a, aussi des trucs qui sont dans toutes les startups ou autres, tu vas avoir des clients, tu les écoutes tu vas leur parler, et pendant que tu leur parles il faut prendre tes notes parce que sinon tu te rates aujourd'hui en fait tu peux laisser tourner un micro ça fait un transcript tout seul qui est quand même vraiment pas dégueu, puis ensuite tu vas le passer en un summarizer qui va te sortir juste les highlights, tu prends la somme de tous ces trucs là tu les mets dans un bout de produit Notebook LM par exemple, tu lui demandes tout à manger et tu lui dis ok mais est-ce qu'il y a des sujets qui ressortent au global, et tu vas trouver des trucs tu vas trouver des nouvelles choses que avant en fait un, soit tu trouvais pas parce que t'as pas le temps, t'es dans ton truc, tu vas à fond et puis en fait t'oublies ah bah merde il m'a dit ça, oui c'est vrai qu'il me. Soit c'était quelqu'un dont en fait c'était le job globalement c'est beaucoup de gens au produit qui faisaient ça et qui font toujours ça d'ailleurs parce que c'est pas parce qu'il y a des IA qu'il n'y a pas besoin de gens au produit, au contraire mais ça pareil, ça démultiplie l'effort et du coup ça permet d'aller vachement plus vite. Après il y a plein d'autres sujets bêtes mais avant c'est vraiment tout bête, t'as des stickers sur le laptop il faut fabriquer des stickers quand tu fais une start-up c'est quand même normal, t'en fais là tout le monde, évidemment bah on va faire tes propres, stickers, c'est un peu embêtant sauf si t'es artiste et que t'es designer ou que t'as déjà un designer si t'as pas bah avant il fallait passer par une plateforme à droite à gauche et puis ça y terre c'est long, bah aujourd'hui tu fais hé bonjour le grand chat est-ce que tu pourrais faire un sticker qui ressemble globalement à ça, avec dans ma charte graphique que tiens voilà je t'ai envoyé le pdf que j'ai le truc, débrouille-toi et bon voilà c'est cool t'auras un truc qui marche pas mal en l'occurrence une petite blague j'ai essayé de faire j'ai fait ça récemment et on a un petit fantôme comme logo et je crois que c'était Google il m'a mis soit un bras, soit trois bras j'ai pas pu avoir deux bras c'était pas possible, on n'est pas encore au dernier moment ce genre de choses fait qu'en fait aujourd'hui, et d'ailleurs on le voit avec toutes les startups IA et Naval, tu peux arriver à faire, aller vraiment très loin avec moins de monde parce que tu te démultiplies à coups d'erreur.
Bruno:
Alors, sur une bonne partie de ce que tu décris, c'est des choses qui s'appliquent effectivement à tout type de start-up, pas uniquement dans le monde de la cyber, parce que la notion de sticker, pour le coup, il n'y a pas que les applications cyber qui en ont besoin. Ce que tu évoquais au début sur le sujet des vulnérabilités, alors effectivement, il y a quand même, il y a beaucoup de vulnérabilités qui sortent chaque jour. Elles sont effectivement plus ou moins critiques. Il y a toujours le sujet, en fait, sur les IA, sur leur capacité à... Est-ce qu'ils vont halluciner ou pas, est-ce que leur catégorisation elle est effectivement valide ou pas comment est-ce que vous vous assurez que ce premier filtre ou ce premier tri qui est fait est fait de manière pertinente c'est quand même assez critique pour vous quand même.
Benoit:
Nous on fait du vulnerability management c'est le cycle de vie de la vulnérabilité et donc en gros c'est toutes les étapes, qui peut y avoir dans la vie d'une vulne entre elle a été trouvée, elle est connue elle est publiée, tu la crèves dans ton système, tu la remédies à la fin c'est bon on l'est fixé et plus de problème et il y a un mot ou un autre nous on est beaucoup là aujourd'hui au commencement dans l'absec dans le triage, et donc en fait c'est des vulnérabilités qui sont connues elles ont été publiées, t'es sûr qu'il y a une vulnérabilité qui existe in the wild, elle a été connue est-ce que chez toi elle s'applique ? C'est une très bonne question et c'est typiquement ce que nous on va faire avec Akudia et autres mais ça te permet aussi de caler le modèle sur quelque chose parce qu'en fait c'est pas il va complètement halluciner et dire « Eh tiens, regarde-moi ce bout de code, combien tu vois de vuln ? » Ben là... Globalement, t'es un peu en train de donner le bâton pour te faire battre. C'est plutôt, je sais que ce truc-là existe, regarde ce truc-là, est-ce que tu penses que ça s'applique, est-ce que les conditions sont réunies pour ça ? Et donc, pars de cet antisèche, entre guillemets, pour arriver à qualifier ce qui se passe. Donc ça, c'est dans le triage. Bien sûr, il y a aussi trouver de la vulne, où justement tu donnes potentiellement le bâton à faire battre, mais c'est pareil. Tu peux aussi dire, oui, mais en fait, ce que je cherche, moi, je suis habitué, je sais que, il y a des rideaux sans javascript, il y a des cql injections il y a ces trucs là, voilà la définition de ce que c'est, regarde si mon code n'a pas ce genre de problème et là l'IA en fait, elle va quand même vachement moins les finir tous les reasoning models, en fait quand tu leur donnes un manger en gros tu démarres un petit peu le contexte ça continue, ça suit, ça va aller dans la ça va pas partir n'importe où et va te dire ah non mais en fait t'as un gros problème de je sais pas.
Bruno:
Chez l'injection mais donc ça veut dire que Sur ce que vous faites chez Convu, ce n'est pas une analyse du code pour essayer de trouver dans le code des choix d'implémentation qui potentiellement ouvriraient des portes particulières. C'est d'aller vérifier l'ensemble des composants, plugins, librairie qu'on peut utiliser pour voir s'il y a des vulnérabilités découvertes sur ces éléments-là.
Benoit:
Oui, ce bout de domaine de la CQ s'appelle le Software Component Analysis, SCA. On adore les sigles, on sait qu'il y en a plein partout.
Bruno:
Et d'ailleurs, vous avez souvent des sigles identiques pour des choses différentes. Donc, il faut savoir...
Benoit:
Quand même, pas tant que ça, mais en fait, il y a des confusions. Mais même nous, on se plante. J'essaie de réviser régulièrement parce que je m'en rate quand même beaucoup et ouais en SCA tu t'intéresses aux composants de ton système de ton cluster, de ton serveur de ton container de ton application, tous ces paquets open source que tu utilises parce qu'en fait les applications modernes sont construites sur les épaules légères comme on dit c'est très rare, c'est même inconnu les gens qui font tout de zéro est-ce que tout le monde a un operating system sur son serveur, machin. Et du coup, il faut t'intéresser à, oui, mais est-ce que t'es bien à jour ? Parce qu'en fait, du vieux code, potentiellement, quelqu'un, il a trouvé un truc qui va pas, et il a été corrigé depuis, et il faut, bah, te mettre à jour, te mettre à jour tes correctifs. Sauf que, ça marche bien, tu peux faire ça, il faut le faire. Mais, il y a beaucoup de trucs, il y a. Et même dans ton app, t'as plein de paquets. Et en fait, tous ces paquets, ils marchent ensemble à telle version. Est-ce que quand tu mets celui-là à telle version au-dessus, est-ce que ça continue de marcher ? C'est une bonne question. Et donc, il y a un risque à mettre à jour de casser ton truc. Donc, pour le faire, il faut quand même... Si tu dois le faire, il faut le faire pour une bonne raison dans l'idée. Plus, il y en a plein. Il y a pas tant de... Enfin, il y a beaucoup de devs, mais il n'y a pas tant de security officer. Et la personne qui va qualifier, normalement, c'est le security officer plus que le dev. Et donc, du coup, en fait, tu es un peu en train de courir dans tous les sens et de dire, mais lesquels je prends ? Nous, effectivement, ce qu'on fait, c'est, aujourd'hui, en tout cas, on commence surtout par ça, c'est essayer de t'aider à te dire, certes, tu as ce paquet, il est bien une version qui est dans les versions qui sont censées être vulnérables, mais est-ce que vraiment, tu es dans les conditions requises pour que ça s'applique vraiment, qu'il y ait un problème de sécurité ? Parce que ce n'est pas parce que tu as le paquet que tu as un vrai problème de sécurité. Ça se trouve, tu n'appelles jamais la fameuse fonction dans le paquet qui a un problème. tu l'appelles jamais ben y'a pas de problème finalement.
Bruno:
Ah je vois.
Benoit:
Ou c'est une faille c'est écrit là c'est écrit ouais c'est une faille Windows ouais mais toute ma prod elle est sur Linux ou sur Mac, n'intéresse pas, tu vois.
Bruno:
Mais donc, ça veut dire que vous avez quand même une certaine analyse du code pour voir si, effectivement, au-delà d'avoir le composant qui comporte la vulnérabilité, c'est est-ce que tu vas utiliser la partie du composant qui est vulnérable.
Benoit:
Et donc, nous, en fait, on réanalyse, on prend la vulnérabilité, on va l'enrichir de choses. On va l'enrichir de conditions d'exploitabilité, de quels sont les symboles, en gros, qui sont vulnérables, et assez trouver si ton code va appeler ces symboles, s'il les appelle de façon vulnérable si t'es dans des conditions vulnérables et c'est, et c'est beaucoup plus que la majorité de ces systèmes là parce qu'en fait on a tous, on est beaucoup à avoir des punditbots chez GitHub qui te dit hé t'as le paquet il est pas à jour voilà la paire merge-la et ça marche très très bien quand t'es toute petite moi je suis toute petite boîte aujourd'hui ça marche très très bien mais dès que t'es gros bah en fait, il n'y a plus personne qui appuie sur le bouton tout seul et c'est la pauvre personne de la sécurité qui doit faire le tri qui sait pas forcément comment marche l'app et en fait les fameuses conditions dont je parle, elles dépendent de l'app et de comment est fichue l'app, donc en plus il faut qu'elle, elle comprenne le code de l'app, et le code il varie tout le temps, donc souvent ça part au dev, le dev il dit, ouais mais t'es mignon, mais en fait ça s'applique pas, une fois, deux fois, trois fois, quatre fois on se parle plus quoi, et donc c'est à ça qu'on sert, on cherche à te dire ok, ces vules là elles sont intéressantes et tu devrais les faire intéressantes sans sécu il faudra que tu les fixes, toutes celles là, globalement c'est défaut positif d'un point de vue sécurité il n'y a pas de risque parce que tu n'es pas dans les conditions qui risquent certes tu as le paquet mais c'est pas vraiment applicable chez toi.
Bruno:
Est-ce que vous vérifiez aussi l'évolution des fameuses conditions peut-être qu'à un moment tu dis en fait là c'est bon t'as pas de risque mais peut-être que 4 mois après on commence à faire appel à la fameuse fonction qui passe par.
Benoit:
Là nous on fait ça parce qu'on réanalyse régulièrement ce qui se passe, De manière générale, en fait, tu vas quand même avoir envie de fixer ces trucs-là. Et donc, les directions dans lesquelles on se dirige aussi, c'est de t'aider à les fixer plus facilement. En te disant, ok, ça, ça fixe, et by the way, ça ne cassera pas ton application quand tu fixes. Parce que quand t'appuies sur la fameuse paire d'Apple, finalement, tu joues un peu à la roulette de ouais, mais en fait, ça se trouve, ça va casser parce qu'ils ont changé quelque chose dans la version que j'ai pas vue et tu peux refaire tourner tous tes tests et ainsi de suite, mais potentiellement, ça va arriver aujourd'hui, GitHub, ils ont changé un bout d'API. Du jour au lendemain, il n'y a plus rien qui marche et donc ouais. Nous on suit ça on va te le dire on va te redire au besoin bon ça c'était pas applicable parce que t'appelais pas le code là on voit que t'as bougé un bout de code maintenant c'est applicable attention il faut que tu t'en occupes pareillement t'étais pas sous Windows maintenant t'as des serveurs Windows attention il faut que tu t'en occupes, et dans le but quand même de justement simplifier cette volumétrie et dans le SCA particulièrement et dans l'appsec, l'application security le SCA, il doit mouiller à peu près 9 sur 10 voire 95% des trucs qu'on t'envoie qui en fait sont pas vraiment applicables dans ton cas, et du coup ça fait beaucoup parce qu'en fait c'est du temps quand t'es dans une boîte que tu passes pas en feature puisque t'as demandé au dev d'aller fixer donc ils ont pris ce temps là prend le temps qui dans beaucoup de boîtes c'est à peu près 10% consacré à la sécu ce 10% consacré à la sécu il y a plein d'autres sujets, et en fait, tu t'es occupé d'un truc qui était marqué critical, mais qui en fait n'a aucun intérêt, globalement, t'as acheté de l'argent par la fenêtre. Ce qui est dommage, parce que t'as plein d'autres trucs vachement intéressants à faire, ailleurs.
Bruno:
Ok. Attends, juste une question qui m'a échappé, c'était sur... Attends, c'est sur les sujets de détection. Attends, ça ne me revient pas. Non, c'est moi. Sur ces gains qu'apporte l'IA aussi, est-ce que l'IA va faciliter aussi la détection de toutes ces vulnérabilités ? Est-ce qu'il y a une capacité à aller analyser du code et voir des comportements qui sont problématiques ?
Benoit:
Un peu comme je te disais tout à l'heure, tu peux quand même dire à ton IA, une RIDOS c'est ça par exemple, et donc va en trouver dans le code RIDOS c'est un regular expression denial of service c'est un truc qui est très dangereux sur les serveurs, sur les serveurs Node parce que Node est single threadé et en fait du coup quand il passe une regex, il s'arrête et il fait la regex et il passe à la suite après donc tu réponds à 10 000 personnes et d'un coup tu réponds à plus personne, donc c'est très dangereux, et en fait qu'est-ce que c'est ça, c'est que t'as écrit une expression régulière un peu trop gourmande un peu trop entre guillemets mal écrite, et du coup moi si je t'envoie un pélode qui satisfait les conditions qui est souvent un peu long mais pas forcément très long un peu long et bah ton savoir il marche plus et en fait du coup trouver cette regex bah c'est quand même c'est un langage c'est un petit langage les regex et donc bah c'est pas il faut pouvoir les analyser il faut les trouver et bah une bonne façon de faire c'est pas la seule du tout tu peux aussi le faire de façon plus directe mais on sait tous.
Bruno:
Qu'aucun être humain ne sait lire les regex de manière native.
Benoit:
? C'est pas si simple, surtout qu'on parle des regex, mais en fait, il y en a différentes variantes en différents langages. Donc en plus, c'est oui, mais toi, t'écris des trucs en JS ? Bref. Et donc, tu lui donnes à ton petit coding agent, et puis tu lui dis, vas-y, cherche, et tu vas en trouver. Et par exemple, tu vas trouver ce genre de choses, et tu vas trouver de la vulnérabilité, entre guillemets, à foison, peu en disant, ok, cherche-moi ce type de vulnérabilité dans tout l'écosystème, et tu vas en trouver à droite, à gauche, et tu vas en sortir. A l'inverse, quand tu te consacres que sur un truc, et tu dis, ok, les gens de, je ne sais pas, Curl, c'est un bon exemple, parce que ça a été assez regardé. Les gens de Curl, si tu leur dis, je veux que tu regardes dans le Curl, et que tu trouves des vulnérabilités au LLM, le LLM, il est gentil. Tu lui demandes de trouver des vulnérabilités, il trouve des vulnérabilités. Est-ce que ce sont des vraies vulnérabilités ? Pas sûr, parce que justement, là, tu es un peu en train de le mettre à halluciner assez gentiment. Et donc, il va globalement t'halluciner des trucs qui vont faire des reports. Ces reports, typiquement, le mainteneur de curl, justement, il en a reçu plein. Et il a dit, les gars, franchement, arrêtez, quoi, c'est trop, là, je n'arrive pas à suivre. Parce que moi, après, il faut vraiment que je vérifie, quand même. Et si je demande au coding agent, globalement il va faire une fois sur une chanson de que ce soit faux, donc ça vaut vraiment que je vérifie sérieusement, c'est utilisé partout, Curl donc c'est grave, et donc c'est embêtant, ça prend du temps ce qui est drôle avec Curl c'est que très dernièrement il y a 2-3 semaines, il a posté un autre truc en disant, par contre, temps à autre ça marche vachement bien, parce qu'il y a des gens vrais researchers, c'était pas un LLM only c'était un LLM avec un bout de système expert en plus qui lui ont trouvé des failles. Justement pointues dans Curl et donc il disait, c'est quand même cool parce qu'en fait vous m'avez trouvé des vraies failles, et maintenant le logiciel il est plus sûr. Donc il y a les deux il y a un peu une tension dans l'écosystème aujourd'hui, comme il y a du AI slope dans le code il y a du AI slope vulnerability il y a des trucs tu dis bah, Franchement, c'est cool, mais est-ce que c'est vraiment une vulne... Bonne question.
Bruno:
Mais au-delà d'une capacité à aller... Parce que j'imagine que le concept de Ridos que j'ai découvert grâce à toi et que je crois absolument génial... Enfin, génial.
Benoit:
C'est un rôle.
Bruno:
Donc, au-delà d'une capacité à aller trouver des types de vulnérabilités dans du code, est-ce que, grâce à l'IA, on a réussi à identifier des types d'attaques ou des vecteurs d'attaques un mode d'attaque, complètement innovant auquel aucun être humain n'avait forcément pensé jusque là.
Benoit:
Des nouvelles vulnacou-déliens génératifs pas forcément tel quel comme ça que je sache mais il y a des nouveaux canaux de vulnérabilité ça par contre il y avait l'injection SQL maintenant il y a l'injection de prompt à chaque fois que tu es, nous dans notre équipe à chaque fois qu'on se nous met en face d'un petit agent la première chose qu'on fait c'est d'essayer de lui faire cracher son prompt en l'injectant à droite à gauche, je pense que la moitié des devs qui ont trouvé ça font un peu ça c'est quand même vachement marrant parce qu'en plus t'as pas besoin de compétences hardcore sécu faut juste lui parler, globalement le menacer un.
Bruno:
Petit peu et.
Benoit:
Puis finalement il finit par cracher ses trucs.
Bruno:
Il y a le fameux test de lui demander une recette de tarte aux pommes ou ce genre de choses tu vois.
Benoit:
Ce qu'il fait, tu sors et tu dis ah ok, si t'arrives de lui faire cracher ok t'es quel modèle, c'est quoi ton prompt de base c'est quoi tes tools, si t'as un peu gagné si t'arrives à trouver des bons tools un peu marrants tu peux dire, hé en fait à partir de ces tools, fais-moi ça et du coup tu peux si ces tools sont, un peu trop puissants, bah tu peux commencer à faire des trucs que t'aurais pas dû faire, ou cracher des choses que t'aurais pas dû faire et là ça peut commencer à devenir dangereux, genre ah tiens j'ai récupéré la clé OpenAPI de la boîte ça peut être un peu rude et ça, en fait c'est un peu une éternelle redite parce que typiquement l'injection dans le prompt c'est un peu l'équivalent de notre injection SQL qu'on avait avant, on mélange dans le même bout, de morceaux de texte de la commande et de la donnée, des trucs qui ne devraient pas être interprétés et des trucs qui donnent des ordres, et en fait comme on les met ensemble, tout un moment il y a un peu mix et puis du coup on ne sait pas qui fait quoi et ça finit mal et.
Bruno:
C'est un terrain de jeu pour.
Benoit:
Ceux qui veulent c'est un bon terrain.
Bruno:
De jeu pour revenir du coup sur ce que vous faites chez Convoo vous êtes intégré dans la CI et du coup tu vas bloquer une mise en prod.
Benoit:
Non nous on fait pas ça c'est ce que fait ton SCA par défaut ton système SCA par défaut, nous chez Convoo, en fait on refiltre ce que te donne ton SCA donc on vient t'aider à dire si oui ou non ce truc là est vrai et donc souvent un SCA il y a plusieurs façons de l'intégrer il y a ce truc là, sur la PR si tu me mets un nouveau paquet et qu'il est pourri j'en veux pas, et donc je te bloque et si tu fais ça mal effectivement tu commences à bloquer tous les devs et tu te retrouves avec une armée de devs à ta porte en disant on peut plus travailler c'est, Ce qui se passe beaucoup plus souvent dans les boîtes, c'est qu'en fait, c'est un scan régulier. Toutes les nuits, on fait tourner sur la branche main un truc qui te donne un rapport et qui te dit en fait, tous ces trucs-là, il y a des failles. Et du coup, il faudrait corriger. Un petit truc intéressant avec le SCA qui est différent de beaucoup d'autres types de vulnérabilités, c'est que c'est des vulnérabilités qui apparaissent. Tes devs, ils ont fait bien le travail, ils ont mis le bon paquet, ça va. Six mois après, il y a quelqu'un qui trouve une vulnérabilité, ton code, il est en prod. Et maintenant, il y a une vulnérabilité dedans. mais avant il n'y avait pas de vulnérabilité, elle était là de toute façon l'attente, mais elle n'était pas découverte et donc maintenant il y a un problème, et donc maintenant il faut revenir retravailler le code et donc il est déjà en prod, donc bloquer la CI des gens parce qu'il y a un truc qui est là depuis 6 mois, c'est un bon moyen de se mettre tout le monde à dos, dans une boîte, mais du coup nous ce qu'on vient faire c'est de te dire oui en fait dans ton rapport là. Certes ton SCA initial t'as dit, hé ça, il faut s'en occuper c'est grave, il est dans la version critique Par exemple, c'est un Ridos, tu vois. OK, c'est un Ridos, il faut s'en occuper. Sauf qu'en fait, nous, on va regarder ton code et dire « Ouais, mais ton code, c'est un front-end. », le frontend, c'est un dashboard, parce que beaucoup de gens font du front en javascript, moins de gens font du node, il y en a quand même pas mal, mais moins de gens font du node, en fait un ridos dans le frontend du coup tu vas bloquer un tab ça se trouve, ça revient à partir d'une entrée utilisateur dans le formulaire, donc c'est lui-même qui peut se bloquer son propre tab, ça ne l'empêchera jamais de faire pomter et d'avoir un nouveau tab et de se recommencer et l'application elle est toujours, disponible, et du coup c'est absolument pas critique comme faille, c'est un truc il faudra peut-être s'en occuper, mais c'est même c'est à la limite de savoir si c'est vraiment une faille c'est plutôt un performance bug que vulnerability, et critical vulnerability et donc nous on vient de dire ça t'es.
Bruno:
Peut-être dans des contextes où c'est tellement complexe à exploiter qu'en fait la probabilité que quelqu'un de non, non, mal intentionné te tape dedans il n'y a plus de chance que ça arrive mais.
Benoit:
Bon après c'est quel niveau de risque que.
Bruno:
T'acceptes.
Benoit:
C'est quoi ton threat model entre guillemets quoi et c'est pareil de, t'as pu faire passer un tool qui te dit, parce qu'il y a aussi des tools qui te disent oui mais en fait la fameuse fonction elle est appelée dans ton code ou elle n'est pas appelée oui mais, ça se trouve la fonction elle est dans ton code mais en fait dans ta prod, potentiellement, tu l'appelles jamais parce que c'est du code mort, c'est pas impossible ou il est derrière un feature flag machin et tout pareil, est-ce que c'est vraiment important ou pas c'est compliqué si c'est du code mort parce que plus personne l'utilise et quand il est derrière un feature flag qui en plus est désactivé, t'as pas de risque finalement. Et donc, arriver à récupérer toutes ces conditions, c'est globalement ce qu'on essaie de faire, en partie, en grosse partie à coup d'analyse statique, pour essayer de vraiment lire ton code, lire tes fichiers de configuration, ton fichier Kubernetes, tes variables d'environnement, où est-ce que t'es, et te dire, au vu de tout ce que t'as config et vu ce qu'on voit dans l'exploitation, t'es dedans, mais tu peux aussi, on a aussi un peu une petite sonde qu'on déploie moins quand même, une petite sonde Runtime, et qui te permet de dire, ouais mais en fait je vois le code tourner, je l'ai vu tourner ou je l'ai pas vu tourner qui est un peu historique enfin si on vient de notre passé puisque chez Screen c'est ce qu'on faisait, on faisait de Runtime Runtime Protection à l'époque, là on fait juste de Insight.
Bruno:
J'avoue J'ai retrouvé entre temps la question qui m'avait échappé tout à l'heure, c'était sur, t'évoquais le fait que t'indique que tel composant, tu peux le mettre à jour parce que c'est safe dans le contexte. Comment vous faites pour garantir que quand justement tu vas le mettre à jour, le reste de ta chaîne, en fait, va pas péter parce que...
Benoit:
C'est là où c'est pas forcément si simple. Qu'est-ce que... Pourquoi ça pourrait péter ? T'as mis le composant, ils ont entièrement changé comment ça marchait en dessous. Là, t'es assez mal barré, tu auras un problème. Mais en fait, tu peux voir, toi, en analysant le code de la dépendance, si tu l'avais lu, si ton LLM le lit en l'occurrence, de dire, ça a beaucoup changé en dessous, attention, il y a un risque. Mais la meilleure façon de faire globalement, c'est d'écrire un test et de le faire jouer pour regarder si la feature continue de marcher. Ce qui n'est pas si simple, il faut booter là pour remettre les bonnes ressources, la base de données, les machins, pour que ça tourne. Mais ça pourrait être aussi beaucoup plus un peu basique la fonction, les paramètres, ils ont changé de sens, et bien là en fait, oui, ton code il l'appelle, mais comme ils ont changé de sens ça va faire n'importe quoi, et ça c'est pas très difficile à regarder, parce qu'en regardant les diffs de ce qui est changé sur la librairie, tu vois le contrat change, et si le contrat change, potentiellement il faut que tu fasses gaffe donc c'est ce genre de compatibility, scoring que tu peux faire mais surtout tu peux aller un cran plus loin et toi-même écrire ce bout de test écrire cette chose pour faire ça qui est aujourd'hui des directions dans lesquelles on va on l'a pas encore fait la révédiation mais c'est typiquement le genre de, c'est nos prochains gros trucs sur lesquels on bosse.
Bruno:
Donc ça veut dire que vous êtes capable d'estimer la complexité que peut représenter la mise à jour d'un composant.
Benoit:
C'est le but de faire ces trucs là c'est de dire à la fin dire ok non seulement, cette vulnérabilité elle est grave ou pas grave dangereuse ou pas grand chose donc tu devrais le faire ou tu devrais pas le faire mais en plus quand tu dois le faire by the way celle là franchement c'était pas très dur du coup on t'a fait une paire t'as plus qu'à appuyer sur le truc celle là, va peut-être falloir mettre un peu de jus de cerveau et potentiellement elle est sur un truc de ton app qui est assez central parce qu'on voit qu'il est appelé de partout, va peut-être falloir que tu sérieusement que tu chambres tes devs et que tu leur dises les gars voilà tout ce que j'ai comme preuve allez regarder. Peut-être que l'AI arrivera à le faire toute seule un jour, mais pour l'instant, prendre les devs. Et là, cette fois-ci, au lieu de leur envoyer un peu n'importe quoi, alors c'est critique, mais en fait, ce n'est pas du tout applicable, tu leur envoies un vrai truc, tu peux leur dire « Oui, regarde, je vois que c'est appelé à tel endroit, tel endroit, j'ai les fichiers dans le code, j'ai l'endroit, j'ai la ligne, je sais que c'est appelé à travers trois paquets, parce que j'ai tracé, nous, on te trace les appels, on te dit c'est appelé par là, par là, par là. » Et du coup, tu as un argumentaire qui, un, va convaincre les devs, mais aussi en le plaire parce que ça va leur faciliter une grosse partie de l'analyse pour ces choses là, parce que c'est vers ça qu'on va et du coup tu peux prioriser l'effort et dire ok bah en fait tout ce qui est facile et critique par exemple je le fais le plus vite possible les autres qui ont besoin potentiellement je peux mettre, en sécurité on appelle ça un compensating control je crois un truc devant genre une règle de ton WAF web application firewall, pour empêcher un payload néfaste de passer ok c'est pas parfait les WAF c'est vraiment jamais parfait, mais ça quand même te permettra de dire ok mais pendant une semaine, on va s'acheter un petit peu de répit, on va respirer et on va pouvoir fixer ce truc-là proprement, tranquillement en l'ayant bien regardé.
Bruno:
Et donc, j'essaie de construire ma question en même temps parce que, première intuition de question, c'était quand tu mets à jour ton composant, donc certes, de ce que je comprends, vous éliminez le risque de, il y a un changement majeur dans le composant qui va générer un problème dans ton code, mais t'es pas à l'abrique en mettant à jour ton composant, en fait, peut-être que maintenant, il importe un nouveau composant qui va poser problème dans ton environnement. Ça peut aller plus loin. Ma question, c'était du coup, est-ce que vous avez vous une capacité entre guillemets à recréer de manière factice l'environnement d'un client pour voir s'il y a des updates qui fonctionnent ou juste en analysant le code de tous ces composants vous arrivez à voir les...
Benoit:
Donc tu peux aller quand même vachement loin à coup de statique et regarder vraiment ce qui se passe nous la velléité c'est quand même pas de dire on va refaire ton appli chez nous et la relancer parce qu'en fait déjà c'est un peu casse gueule, petit b quand t'es une map, enfin une boîte un peu grosse, en vrai t'es pas très envie que je télécharge ton code source par défaut. Donc, il y a bonne chance que l'analyse, en fait, elle se passe à moitié chez toi dans un des clusters et autres. Mais par contre, en fait, t'as déjà une suite de dev, t'as déjà une CI, en fait. Et ça tombe bien, parce que nous, on est déjà connecté à ton source code manager, ton Git, ton GitLab, enfin, ton GitHub, ton GitLab, et qui a plugé un truc. Et donc, en fait, si nous-mêmes, on injecte un test qui va bien, on peut le faire tourner, dans ton infra, c'est déjà fait, et ça va directement nous donner une réponse, en disant, bah, oui, ça marche, ça marche pas. Et comme probablement la première version de ce test sera nulle. Mais ok, ça tombe bien puisque tu peux gentiment l'itérer et laisser ton cursor, ton clock code, ton machin. Idéal, tourner dessus et dire ok mais maintenant t'essayes de comprendre pourquoi il marche pas et tu vois qu'en fait c'est parce que là il y a moitié de l'app qui marche plus parce que les paramètres sont dans le mauvais sens et ainsi de suite. Donc c'est plutôt comme ça que t'as envie d'aller faire ces trucs là. T'as envie de le faire le plus possible en statique en vrai. Mais, pour le valider sérieusement, potentiellement à un terme, tu veux quand même arriver à j'ai fait tourner le code parce que toujours aujourd'hui, en lisant du code, tu peux pas dire vraiment, exactement pour sûr, je suis sûr qu'il va faire ça. C'est la joie du code.
Bruno:
Mais ce que je trouve intéressant dans ce sujet-là, où du coup tu vas réussir à analyser effectivement ce nouveau composant et son comportement, c'est que, alors à moins que vous ayez un LLM révolutionnaire que personne n'a, mais en général t'as une contexte window qui est quand même restreinte par rapport à une taille de code base, surtout quand t'as souvent pris l'exemple de Node.js où on sait que quand t'appelles un paquet Node.js, t'en as tout plein qui arrive avec, donc ça t'expose ta contexte window donc ça veut dire que vous êtes obligé de quand même morceler l'analyse comme tu nous as indiqué cette notion de chemin ça veut dire que dans mon premier, réflexion que j'ai sur ce que tu me dis c'est qu'en fait vous êtes quasiment obligé de reproduire une notion de runtime pour voir effectivement les imbrications des différentes.
Benoit:
Choses quand on fait du triage, effectivement si tu donnes tout le code à un LLM il va te dire, ça ne rentre pas tu peux utiliser ce que nous on fait en fait on n'a pas un workflow on ne met pas tout dans le contexte et on lui demande de se débrouiller on fait un agent avec une tool calling loop au sens des gens d'anthropique c'est une boucle fort ou une boucle wild si tu veux, qui dit j'envoie ce truc là au LLM et je lui donne la possibilité de me répondre des ordres, des tools, et s'il m'en renvoie un j'exécute cet ordre et je remets le résultat dans la contexte window pour lui donner pour la suite et je m'arrête quand le LLM arrête me donner un ordre et il me dit j'ai bon j'ai fini je suis content de moi. Et on fait ça mais même en faisant ça en fait quand il y a beaucoup de paquets le LLM il fait ah ouais mais il y a beaucoup de boulot là quand même je vais dire que je sais pas ça m'a l'air plus simple. Et du coup, tu peux assez lui dire non mais gars, arrête de dire un machin. Ça ne suffit pas. Et donc effectivement, nous, on a... À partir de la donnée qui est en fait dans ton app et de ton manifeste, dans ton manifeste de paquets, il y a écrit j'utilise telle version, telle version, telle version du logiciel. Dans le package manage, enfin dans le package repository, il y a écrit oui mais telle version en fait, elle dépend de telle version de paquets. Et du coup, tu peux dire ok, je peux refaire tous les liens. Puisque je peux refaire les liens, je peux donc faire une analyse moi-même en disant, dis-moi toi LLM, entre ce paquet et ce paquet, comment c'est appelé ? Qui va appeler quoi ? Et du coup, j'arrive à refaire le chemin de proche en proche. Ça ressemble un peu à ce que fait l'exécution. C'est une exécution qui est abyssalement lente par rapport à une vraie exécution, mais c'est une exécution que toi, pauvre humain, quand tu fais de la qualification de vulné, c'est ce que tu fais. T'as un bon IDE avec un LSP, c'est le language serveur, qui te permet de cliquer sur go to definition or go to usage, c'est ce que tu fais. Tu dis, ok, mais attends, ce truc-là, il appelle quoi, ça vient d'où, tu cliques, tu cliques tu cliques, tu te balades, jusqu'à tomber sur un truc qui est un appel dynamique parce que ça arrive en plein de langages et en fait là tu dis, ah oui mais en fait là du coup c'est dans une variable je peux pas juste cliquer il faut que j'allume mon cerveau et que je regarde qu'est-ce que ça pourrait être c'est justement la plus-value du LLM là-dessus par rapport à un analyseur statique de base qui fait jusque partie du code parce que le LLM il a une petite intuition. Et qui va du coup te dire ah oui mais en fait moi je pense que ça devrait aller là et du coup tu vas rebrancher tes chemins, et à la fin, t'as, ok, bah, voilà. Maintenant, j'ai des chemins. Ces chemins, c'est quand même pas très gros. Je te les donne à manger, je te dis, maintenant, conclue, mon grand. Et il te dit, bah, ouais, en fait, là, t'as un problème. Oui, il y a clairement un problème. Je vois que t'es accessible. By the way, la fonction, tu l'appelles avec des paramètres qui n'ont pas l'air sanitisés particulièrement, dans ce que je vois dans l'application. Donc, c'est un vrai problème. Parce que ça pourrait être, ouais, ok, t'appelles la fonction, mais en fait, tu l'appelles avec une constante. À moins que t'aies mal choisi ta constante c'est quand même pas un problème.
Bruno:
Ce fonctionnement aujourd'hui que vous avez c'est uniquement via des LLM ou est-ce que vous avez des moteurs différents non LLM et est-ce que vous avez vous prenez des LLM sur étagère bête et méchant avec juste du prompt un peu ou est-ce que c'est fine-tuné ?
Benoit:
Alors nous on utilise des LLM qui sont des LLM entre guillemets sur étagère, c'est les modèles d'Open AI, Anthropic et autres qu'on compare régulièrement pour savoir quel est le meilleur en ce moment pour faire ce qu'on fait, on les fine-tune pas aujourd'hui, peut-être qu'on les fine-tunera un jour mais il y a quand même une vraie vérité dans ce que nous on fait de déployer dans les vraies grosses boîtes et dans les vraies grosses boîtes, globalement ils ne veulent pas que le code source ils sortent et donc ils veulent potentiellement utiliser leur propre déploiement de leur OpenAI et autres et donc le fait qu'ils soient fine-tunés serait un problème parce qu'ils n'auront pas ton fine-tuning du truc tu pourrais te débrouiller pour faire déployer le machin mais ça commence à devenir abyssal. Donc le plus possible enfin le moins on a besoin de fine-tuner le mieux en sport plus on peut utiliser des trucs sur étagère c'est la façon dont on les appelle et c'est cette embouille de comment est-ce que tu fais ces appels qui sont importantes et qui vont être un peu, différenciants et qui sont aussi différenciants de ce que toi tu peux faire parce que t'es absec tu peux demander à Claude de t'écrire un truc qui qualifie les vulnes ça marche aujourd'hui pourquoi pas mais en fait, c'est pas si simple justement c'est un peu profond il faut y passer un peu de temps et ça te revient c'est ce que nous on te propose, mais sinon enfin le tool calling loop c'est vraiment une tool calling loop il a trois tools le LLM c'est lit des fichiers lit des dossiers et fait des greppes, il y a quelques autres tools en vrai de parsing de langage un peu plus avancés, mais conceptuellement c'est vraiment juste ça c'est un agent certes mais c'est pas un agent qui fait de la modif c'est un agent de lecture donc en plus c'est vachement plus sain et facile il y a moins de chances que ça parte n'importe où que ça parte n'importe quoi, Ce qui n'empêche pas que quand c'est nous qui faisons ton analyse, elle est isolée dans un truc complètement temporaire, dans un compte AWS différent. C'est quand même un truc, on ne sait jamais où ça peut partir, donc tu fermes. Mais ultimement, c'est moi ce que j'aime bien dans la CQ et dans les startups en DevTool, très souvent, c'est avec ces vieux pots, c'est des technologies vraiment, des technologies classiques que tu utilises, que tu utilises de façon différemment, un peu avancée, que tu fais des trucs qui sont vraiment marrants et très très cool.
Bruno:
Et à quelle mesure, parce que j'imagine que parfois il y a quand même besoin, de valider, enfin tu vois tu as un retravail humain, est-ce que c'est fait quand vous avez un client, est-ce que vous en interne chez Konevoo, vous avez ce retrait de validation parce que du coup il est fait en interne chez chacun.
Benoit:
Et des fois que j'ai oublié de répondre à la moitié de ta question qu'est-ce qu'on fait autre chose que des LLM tout à l'heure et on fait aussi autre chose que des LLM parce qu'en fait il y a, par exemple les conditions environnementales est-ce que c'est du Linux ou c'est du Windows tu peux quand même le trouver assez facilement genre je sais pas tu regardes le Dockerfile et tu vas voir et donc t'as plein de trucs comme ça que tu peux faire, le LLM moins t'en fais mieux tu te portes en termes d'hallucination potentiellement, mais ça n'empêche pas qu'en fait la versatilité de ce qu'on fait il est vulné, il y en a plein il y en a de plus en plus, le fait qu'en fait tu peux pas non plus tout générer ou tout écrire toi-même, c'est d'ailleurs comme ça, pour ta première question quelle est la grosse différence entre, une boîte dans la sécu avant et après en fait avant il y avait beaucoup plus d'humains pour fabriquer tous ces bouts de règles qu'aujourd'hui et donc et donc du coup, pardon j'ai oublié la fin de ta question la deuxième question.
Bruno:
C'était sur est-ce que vous avez besoin de faire une revalidation humaine.
Benoit:
Ouais la revalidation humaine, Oui et non. Alors qu'en fait, on va surtout valider les conditions d'exploitabilité, est-ce qu'on a bien compris la vune, est-ce qu'on a bien enrichi toute la donnée, pour pouvoir ensuite faire ton analyse, parce que nous, en fait, interne à convoire, on n'a pas accès au code du client, on ne veut surtout pas lire ton code. Donc non, on pourrait te proposer du service et dire, on a quelqu'un qui peut le faire pour toi, mais en fait, ce qu'on vend, c'est un LLM pour le faire, et donc le but, c'est qu'il ne le fasse pas et qu'il n'hallucine pas. Et en vrai, reasoning model, à qui tu demandes des preuves c'est un gros truc important, tu lui demandes des preuves et tu lui dis ok, si tu vois quelque chose tu me dis exactement, et ça tu peux quasiment automatiquement valider cette preuve, soit avec un autre LLM soit même juste en disant ok, est-ce que dans la ligne 42 il y a bien le bout de texte qui me dit qu'il y est et ça te permet déjà de vraiment caler ton truc beaucoup mieux, après on rappelle que ce qu'on fait avec c'est d'aider au triage et entre guillemets la concurrence c'est un humain, c'est un humain qui devait faire ça qui fatigue et donc potentiellement on va se tromper, c'est complètement possible, mais déjà on fait tout pour que ça n'arrive pas on évolue en permanence le système pour que ça arrive de moins en moins mais c'est des systèmes. Intelligents experts et donc de temps à autre c'est un peu diffus, en sécu souvent parfois c'est un peu genre sur la ligne de ouais t'es vraiment sûr, bah je suis pas complètement sûr et donc ce qu'on cherche à faire c'est un, un rapport pareil que l'humain va pouvoir vérifier parce que en fait ces gens-là, il ne faut pas les virer, au contraire, ils ont plein d'autres trucs à faire, et typiquement, en fait, si, comme je disais tout à l'heure, au lieu de recréer le contenu, recréer l'analyse, si c'est juste la vérifier, ou regarder si, ouais, make sense, c'est bon, je suis convaincu, on peut passer à la suite. Donc c'est plutôt notre client qui a vocation à vérifier, entre guillemets, mais la façon dont nous on perçoit cette chose-là, c'est plutôt il faut qu'on arrive à lui montrer qu'on est assez bon, et qu'on est capable de vraiment avoir un bon taux de réussite, qui est le plus possible et qui vient sur temps à 100% mais, lui-même il sait qu'en fait il n'ait jamais été parfait dans ces trucs là et à partir du moment où il arrive à se dire ok mais en fait ça va me faire économiser plein de temps dans mon quotidien parce que j'ai vraiment des sujets beaucoup plus intéressants type production security, ou qu'est-ce qu'il se passe quand le machin quand le mec touche à tel formulaire puis tel formulaire puis tel formulaire et en fait il se retrouve admin. C'est c'est ça qu'on essaye de faire c'est mettre de l'huile dans le rouage et typiquement d'ailleurs, je te disais tout à l'heure, on réanalyse ce qui vient d'un autre système de SA mais dans l'idée on repousse aussi le finding, enfin la recommandation, c'est affixé, c'est pas affixé, ailleurs que dans le système. En gros, on ne veut pas te donner un nouveau dashboard, parce que dans la sécu, c'est un peu un vrai problème. Un dashboard te reproduit et tu te perds. Donc le but ultime, c'est quand même de te dire, non mais t'as un workflow, il marche à peu près aujourd'hui, mais tellement bien qu'il marche mieux, ça tombe bien. Nous, on est une AI pour faire ça. Alors certes, on ne fait pas tout avec de l'air tout le temps, mais vu de loin, le but, c'est qu'on fait ça pour toi. On va t'aider à ce que ça soit beaucoup plus fluide et que tu puisses trouver les bons trucs et passer ton investissement sécu sur la bonne chose.
Bruno:
Pour terminer, on a évoqué un petit peu tout à l'heure, enfin surtout toi, t'as évoqué l'injection de Prompt, la Prompt Injection, mais t'as évoqué aussi que vous aviez cette capacité à voir qu'il y a des... Notamment il y a certains appels SQL ou autres qui sont non-sanitized, donc qui ont besoin d'être retravaillés est-ce qu'aujourd'hui on a des moyens de détecter de faire ce même système là sur des promptes et de pouvoir dire à quelqu'un écoute là ton prompt t'es à risque parce que si quelqu'un arrive.
Benoit:
Alors nous on fait pas du SAST, Static Application Security Testing c'est trouver dans ton code à toi pas celui de tes dépendances, aujourd'hui on fait pas ça il y a d'autres boîtes qui le font potentiellement c'est quelque chose où on ira après parce que c'est effectivement un domaine où classiquement, la découverte de vulnérabilité se fait à coup d'une grosse regex en gros, et ben le regex, elle est souvent un peu fou, ça ne s'applique pas ça ne marche pas si bien et donc du coup, retraiter les faux positifs là-dedans c'est intéressant aussi, mais c'est pas une activité différente, mais c'est une activité connexe, mais pas exactement la même chose ce qu'on fait, et ouais, le, c'est un domaine assez fascinant aussi mais, pour le prompt aujourd'hui le prompt c'est un truc écrit globalement pour un humain, c'est un language modèle et il y a des solutions je connais pas de nom je sais qu'il y a des solutions il y avait un truc qui tournait il y a quelques mois, qui était une sorte de, je crois que ça s'appelait Merlin tu lui envoyais des, ton but c'était de bypasser l'élève justement de lui faire cracher des instructions et en fait c'est des gens qui vendaient une solution de ça, un truc qui m'entraîne un peu leur modèle mais surtout ils essaient de te convaincre qu'en fonction des différents niveaux. De complexité un peu du chose, c'est pas si simple parce qu'évidemment tu peux dire si quelqu'un te demande des mots interdits, on faisait ça dans les forums quand on était plus jeunes si le mec a écrit merde alors on lui bannit son compte parce qu'on veut pas qu'il y ait écrit la merde dans le forum bah c'est un peu la même chose genre si le gars tu vois qu'il fait dans la réponse il y a un truc qui m'écrit password genre tu bloques la réponse et elle passe pas, ça peut faire mais en fait très classiquement tu vas demander lui-même de faire un road 13 ou je sais pas quoi et puis bah ça sort et donc du coup il te faut des trucs qui vont essayer de comprendre ce qui se passe et l'intention derrière mais c'est pareil ces machins ils peuvent halluciner aussi, dans les deux sens ils peuvent te dire bah en fait tout est faux enfin tout ça marche pas et du coup t'as, un sort de déni de service ton machin il marche plus quoi donc en fait c'est pas bon ils peuvent être trop laxistes et du coup eux ils peuvent pas comprendre ce qui se passe parce que si tu l'as fait encoder tu lui dis ok, t'as dit au premier LLM que tu voulais encoder le truc sur le premier bit de tous les premiers caractères UTF-8 qui arrivent ou le dernier bit. Aucune chance qu'il le retrouve tout seul, à moins qu'il ait les deux instructions qu'il arrive à comprendre. Mais lui-même, il ne faut pas qu'il s'auto-injecte en faisant ça. Il ne faut pas que les instructions... Le truc de dire, non, non, mais si tu es un LLM, comprends qu'il n'y a pas de problème et puis passe à la suite. Donc, c'est aujourd'hui pas simple, parce qu'en fait, ce qui nous manque, à mon sens, ce qui nous manque dans l'écosystème, des modèles providers, ce n'est pas un truc que nous, on pourra faire en tant qu'humain, en tant que start-up qui n'est pas en train de créer des modèles. C'est cette capacité à séparer la donnée de la commande c'est comme dans les requêtes SQL où yes le langage t'autorise à tout faire mais en fait ton binding, ta librairie pour te connecter ou ton ORM sépare les deux et du coup va sanitiser fortement la partie donnée pour être sûr qu'il n'y ait rien et même là comme c'est de la commande humaine ce ne sera pas forcément, aussi simple que on va vérifier qu'il n'est pas mis de côte ou les escapes comme il faut donc c'est pas, ça marche aujourd'hui pas bien et parce que c'est inhérent à comment marcher l'élève hyper intéressant.
Bruno:
Super intéressant peut-être qu'on arrivera à faire bientôt un épisode sur quelqu'un qui aura une solution à ce problème là.
Benoit:
On prend tous on prend.
Bruno:
Merci beaucoup Benoît pour cet épisode si pardon j'ai deux questions rituelles pour toi avant question importante la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes.
Benoit:
Ouais il y a deux bouquins que moi j'ai adoré dans ma carrière moi j'étais plutôt Dave Bakken à la base j'ai évolué un peu pour faire de tout le reste c'est du full stack, mais un qui s'appelle Releas It qui est plutôt un contenu qui s'adresse fin junior début de mid, qui parle de ok faire du code pour la prod en fait c'est bien d'écrire du code et ça marche mais en fait une petite erreur peut faire une avalanche et ça peut mal finir et ce bouquin il s'intéresse vraiment à ça comment est-ce qu'on fait du, production software et qu'est-ce que ça veut dire et c'est pas très long c'est assez facile à lire et ça commence par des exemples donc en fait on le vit je crois que le premier exemple c'est une compagnie c'est un aéroport, une compagnie aérienne qui ne pouvait plus faire voler pendant une semaine ou deux parce qu'il était par terre, complet quoi, le deuxième bouquin c'est un peu dans la continuité, c'est plutôt pour des gens qui sont dans l'idée un peu plus senior c'est des trucs très back-end qui s'appelle « Designing Data Intensive Application ». Pour le coup, un gros bouquin assez long, assez deep, assez complexe et qui, entre guillemets, reprend un peu les bases de, ok, tu sais faire du SQL très bien, mais est-ce que tu sais vraiment comment les transactions... Qu'est-ce que ça veut dire, une transaction sérieusement ? Et au fait, une transaction distribuée, ça veut dire quoi ? Et voilà. Ça reprend tous ces trucs-là un peu à la base et ça remet les bons fondamentaux au bon endroit. Et typiquement, chez Screen, là, on l'achetait à tous les devs quand ils arrivent, on leur donnait, tiens. Tu l'auras comme ça.
Bruno:
Ton premier jour, c'est ça.
Benoit:
C'est ton premier jour. Tu ne vas pas le lire ton premier jour, mais tu l'auras à lire parce qu'on considère que ça va bien te formater l'esprit pour faire ces trucs où on prend de la volumétrie de données en continu. Parce que du screen, c'était des ordinateurs qui parlaient d'ordinateur, en gros. C'est dans la moindre mesure ce qu'on fait aussi chez ComteVous. Pour l'instant, je l'ai acheté une fois dans le bureau. Je ne l'ai pas encore mis à tout le monde. Et ça... Franchement, ça remet les bases au bon endroit et ça pousse bien.
Bruno:
Ok, canon. Podcast, est-ce que tu es plutôt espace ou tabulation ?
Benoit:
C'est toujours une bonne question, pas si simple. Moi, en vrai, j'appuie sur Tab dans mon Vim, mais ça fait des espaces. Et en vrai, c'est mon linter qui, depuis GoFormat, c'est mon linter qui a raison. Je m'en fiche. À partir du moment où j'arrive à lire le code derrière, tout va bien. Je suis très heureux, mais moi, j'appuie sur la touche Tab, mais ça fait des espaces.
Bruno:
Très bien. Merci beaucoup, Benoît.
Benoit:
Merci à toi.
Bruno:
Et merci à tous d'avoir suivi cet épisode. Merci à Jean-Baptiste de nous avoir mis en relation avec Benoît pour rendre cet épisode possible. Et merci, du coup, à Jean-Baptiste aussi de m'avoir mis en relation avec plein de gens, parce qu'il y a plein d'invités qui vont arriver prochainement sur le podcast grâce à JB. Donc, merci beaucoup JB. Merci à tous bien évidemment de partager ce podcast autour de vous, que ce soit auprès de Dev, que ce soit auprès de gens dans l'infra ou dans la cyber, ou dans des tas d'autres métiers techniques, parce qu'on essaie d'aborder tous les sujets. Et je pense qu'on bénéficiera tous d'apprendre un petit peu le métier de tous les autres. Donc voilà, merci beaucoup. Et puis si vous avez envie de contribuer à ce podcast, de l'aider à se développer, je vous invite à aller checker le Tipeee en description si vous avez envie d'y participer et peut-être aussi de récolter au passage quelques goodies. Je vous remercie beaucoup. Je vous souhaite une très bonne fin de semaine. Je vous dis à la semaine prochaine. Et d'ici là, codez bien.
