Gérer l'Urgence : L'art de prioriser les vulnérabilités en fonction des risques

0:00 Là, on va se plonger dans un monde où toutes les vulnérabilités sont des bombes à retardement, où chaque ligne de code peut être un potentiel piège, et où l'art ultime, c'est de savoir quoi désamorcer en premier. Vous savez, vous, ou pas? Qu'est-ce qu'il faudrait désamorcer en premier? Non? Moi, j'en connais une qui sait exactement ce qu'il va falloir désamorcer en premier. Elle s'appelle Havaya Garti, elle est security analyst chez Snyk. Elle va nous dévoiler les secrets de gestion des risques en cybersécurité. Je vous demande un tonnerre d'applaudissements pour Havaya Garti. C'est Beyoncé maintenant. Je vous laisse la zapette. Merci. Bonjour à tous, bonjour à toutes. Alors aujourd'hui, je vais vous parler d'un sujet qui nous concerne tous, de près ou de loin. C'est l'explosion des vulnérabilités.

1:02 Et plus précisément, comment passer de ça à ça. Parce que dans un monde... Où les vulnérabilités sont en constante augmentation, il est important de faire ressortir les vulnérabilités qui comptent vraiment afin de pouvoir mettre les ressources nécessaires sur les vulnérabilités qui sont les plus importantes. Et ça me rappelle une discussion que j'ai eue avec un ami à moi. On était dans un café, on buvait un café. Antoine, il est absèque. Et du coup, à un moment donné, la question du comment ça se passe au boulot est arrivée. Et il m'a dit, franchement, on est submergé par les vulnérabilités. On ne sait plus où donner de la tête. Et c'est là que ça devient intéressant, parce que comme je le disais, la question n'est pas de tout fixer, mais plutôt de faire ressortir ce qui est réellement important et pertinent dans nos projets, nos applications et notre entreprise. Et donc la bottom line, c'est en fait de se focaliser sur l'essentiel, et donc de vraiment comprendre prendre le risque réel qui pourrait impacter finalement notre entreprise.

2:17 Je m'appelle Havaya, je suis sécurité analyste chez Snyk, je suis ingénieure aéronautique de base et j'ai un MBA en système d'information et cybersécurité. Et donc aujourd'hui, on va commencer par parler de l'explosion des vulnérabilités. On va parler des défis que les absèques et les développeurs ont à surmonter à cause de cette augmentation. On va parler du risque et surtout aussi comprendre pourquoi la sévérité, qui est en fait le standard universel utilisé aujourd'hui pour prioriser les vulnérabilités, ne suffit plus. On parlera des conflits entre les facteurs objectifs, qui sont propres à la vulnérabilité, et des facteurs contextuels qui parlent de l'environnement dans lequel se trouve la vulnérabilité. On va comprendre pourquoi c'est très important. On ira voir un exemple pratique, parce que finalement, on veut mettre la théorie en pratique et vraiment comprendre comment faire ce genre de choses et comment faire la curation des vulnérabilités, finalement.

3:18 Et puis, on résumera le tout ensemble. Alors c'est parti, commençons par le commencement, donc l'explosion des vulnérabilités. Comme on peut le voir ici, depuis les années 2000, on voit que les vulnérabilités, le nombre de vulnérabilités recensées chaque année est en constante augmentation. Et on voit surtout aux alentours de 2017 qu'il y a en fait un pic. que de là part vraiment la réelle augmentation que l'on connaît aujourd'hui et cette explosion de vulnérabilité dont on parle souvent. Et je ne sais pas si vous le savez, peut-être qu'il y en a certains ici qui savent la réponse, mais ce pic en 2017, il arrive à cause de deux changements, deux changements principaux, on va dire. Le premier, c'est que jusqu'à cette année-là, en fait, pour pouvoir répertorier et recenser les vulnérabilités, tout le processus était assez manuel. C'est-à-dire qu'il fallait remplir des formulaires, il fallait tout inscrire, c'était un long processus. Et en 2017, on se rend compte qu'il faut automatiser tout ça et qu'il faut faire en sorte que les vulnérabilités puissent être exposées plus rapidement et plus facilement.

4:28 La deuxième chose, c'est que du coup, il y a des industries et des entreprises qui s'introduisent et qui naissent pour pouvoir scanner les projets des utilisateurs et pour pouvoir divulguer les vulnérabilités, pour avoir une vision complète et globale des vulnérabilités, ce qui est très important pour pouvoir ensuite comprendre le risque, mieux le gérer et du coup, in fine, pouvoir prioriser les vulnérabilités. Et donc en fait, ces deux changements, ils font en sorte qu'il y a une certaine prise de conscience. autour de ce concept de cybersécurité, et que les gens commencent à comprendre qu'il faut impérativement divulguer, exposer les vulnérabilités, et surtout les répertorier, leur donner un CVE, donc un numéro de série, le nom de la vulnérabilité, pour pouvoir mieux sécuriser les projets et les entreprises de manière générale. Et c'est là en fait que commencent un petit peu les défis entre les appsecs et les développeurs. Donc on a d'un côté les appsecs qui veulent tout sécuriser, maintenant, tout de suite, et puis on a les développeurs qui doivent développer rapidement pour pouvoir suivre les besoins du marché.

5:37 Seulement voilà, les absèques d'un côté, ils font face à certains défis, à une certaine adversité, parce que la complexité des attaques est de plus en plus grande, donc ça devient de plus en plus complexe, il faut tout le temps se mettre à jour à ce sujet, il y a tout le temps des nouveaux types d'attaques aussi, et les attentes de l'industrie sont de plus en plus élevées. C'est-à-dire qu'on a des réglementations et des certifications, et là aussi, encore une fois, ce sont des choses avec lesquelles il faut se mettre à jour, tout le temps. Donc ça devient de plus en plus compliqué. Et puis d'un autre côté, avec les développeurs, donc il est à la vitesse du développement, ça on l'a dit, et puis aussi il y a cette pression constante de tout le temps devoir fixer, de tout le temps devoir patcher les vulnérabilités qui existent déjà dans le code de production. Et ça c'est très important parce qu'évidemment ça met la pression à tout le monde. Voilà. Alors, j'espère que vous êtes bien prêts, bien installés. Buzzword, shift left.

6:38 Alors, le principe est simple, c'est intégrer la sécurité dès les premières phases de développement. Parce que oui, connaître ses points faibles et savoir où se trouvent nos vulnérabilités dès la partie du développement, ça aide. Et aussi, pouvoir corriger et rectifier ces vulnérabilités dès la première phase de développement, c'est bien. Mais sans une priorisation correcte et efficace, on reste noyé. Et c'est ça en fait que mon ami Antoine a essayé de me dire, c'est que finalement on ne sait plus aux données de la tête, et puis ce qui se passe c'est qu'on a l'impression de tout le temps courir, afin de devoir tout le temps éteindre des feux, sans pouvoir vraiment se focaliser sur ce qui est important. Et c'est pour cela qu'il est important d'avoir une identification précoce des vulnérabilités, de pouvoir mieux comprendre et gérer le risque, pour ensuite prioriser les vulnérabilités qui comptent vraiment et mettre nos ressources sur ce qui est réellement important.

7:42 Alors avant de parler du risque, j'aimerais qu'on comprenne un petit peu, et il est important je pense aussi de comprendre, la façon traditionnelle de prioriser les vulnérabilités. C'est en fait à l'aide de la sévérité. Donc il y a un CVSS score, c'est un score d'une échelle de 0 à 10. qui nous parle de la sévérité, du niveau de sévérité des vulnérabilités. Et donc chaque vulnérabilité a son CVSS score, sa sévérité. Et rien que cette année, en 2024, et ce sont des données d'octobre, donc le nombre a déjà encore augmenté, on recense plus de 24 000 vulnérabilités critiques. Donc je ne parle même pas des vulnérabilités high, medium, low, vraiment juste les vulnérabilités critiques, plus de 24 000, c'est quand même énorme. Alors évidemment, on ne les a pas toutes dans notre projet, mais quand même, c'est un nombre assez conséquent. Et moi, c'est là que j'ai quand même eu un déclic, parce que quand je parlais avec Antoine, il m'a dit« Oui, mais cette analyse du risque, moi, je ne suis pas convaincue.

8:47 » Parce que je lui ai un peu expliqué, j'étais justement dans mes recherches. Il me dit« Moi, je ne suis pas convaincue. Je ne vais quand même pas laisser passer une vulnérabilité critique, ne pas la fixer. Et puis quoi? Qu'est-ce qu'on fait? Si jamais finalement elle est exploitée, je suis bien. Et en fait, c'est là que j'ai compris que ce n'était pas la notion du risque qui était un problème, c'était ce consensus et ce standard universel que l'on utilise, qui est donc la sévérité de la vulnérabilité. Et que du coup, les gens, oui, forcément, je peux comprendre, avaient peur de mettre ça de côté et de dire, une vulnérabilité critique, je ne la fixe pas, parce que dans le cadre... de mon entreprise, elle n'est pas risquée. Bon, c'est quand même un peu délicat. Et du coup, on a commencé à parler de la Real World Threat Distribution, donc la distribution de la probabilité des vulnérabilités d'être exploitées. Et là, c'est assez intéressant parce qu'en fait, on voit ici que la majorité des vulnérabilités ne seront jamais exploitées.

9:55 C'est-à-dire que finalement, si on regarde la probabilité d'exploitation, on se rend compte que la majorité des vulnérabilités ne sont peut-être pas si risquées que ça pour notre entreprise dans la vie réelle. Et là, on passe d'un côté théorique de la sévérité et on rajoute une certaine perception de probabilité pour nous raconter toute l'histoire. Oui, mais pas tout à fait toute l'histoire. Parce qu'en plus de tout ça, il faut bien rajouter le contexte. Parce qu'une vulnérabilité, dépendamment de l'environnement dans lequel elle se trouve, elle pourrait être plus risquée ou moins risquée, et on va y venir. Et je pense que c'est à ce moment-là qu'Antoine a eu une prise de conscience, parce qu'en fait, dans le passé, Antoine était pentester. Et il m'a dit, au fond, c'est vrai, avec mon expérience et le boulot que j'ai fait à l'époque, c'est vrai que finalement, je me rends compte qu'effectivement, la majorité des vulnérabilités n'étaient pas exploitées.

10:56 Et donc, c'est là que tout d'un coup, on se rend compte que quand on ouvre nos œillères, il se fait une ouverture où on comprend et on prend conscience que ces données-là peuvent être utiles dans la priorisation des vulnérabilités au jour le jour, dans nos entreprises, dans nos projets, dans nos applications. Et ça, c'est important. Et maintenant qu'on a pris conscience de ça, on peut parler de la définition du risque. Donc le risque, c'est une combinaison entre l'impact et la probabilité. L'impact... qu'une vulnérabilité pourrait avoir si elle est exploitée, et la probabilité que la vulnérabilité soit exploitée. Et pour chacun de ces paramètres, donc l'impact et la probabilité, nous avons des facteurs objectifs, et des facteurs contextuels. Les facteurs objectifs, comme je l'ai dit, ce sont des facteurs qui sont des caractéristiques propres à la vulnérabilité. Donc ça va être par exemple le CVSS, donc la sévérité de la vulnérabilité, et ça peut être aussi par exemple CISA, donc CISA c'est un catalogue qui répertorie et qui recense toutes les vulnérabilités qui ont

12:11 une exploitation véridique. Donc il y a vraiment un fait, on a trouvé un code qui peut exploiter et faire une vaste exploitation de la vulnérabilité. Donc une exploitation réelle, un code qui fonctionne. Si maintenant je le prends et que je l'exécute, voilà, j'ai réussi mon coup alors que je ne suis pas attaquant et je ne m'y connais pas plus que ça. Et puis il y a les facteurs contextuels, donc de l'autre part, qui eux sont les facteurs qui parlent de l'environnement et du contexte dans lequel la vulnérabilité se trouve. Donc ce sera par exemple la criticité du projet, du coup dans le cadre de mon entreprise. Ça peut être aussi par exemple ce sujet de reachability. Est-ce que la fonction vulnérable... À travers laquelle l'attaquant devra procéder. pour pouvoir exploiter cette vulnérabilité. Par exemple, dans les bibliothèques open source, est-ce que cette fonction est utilisée? Parce que s'il n'est pas utilisé, forcément, mon risque y baisse.

13:14 Donc ça, c'est important aussi. Je dis mon risque y baisse et pas mon risque est de zéro parce qu'il n'y a pas de risque zéro. Ça, il faut le comprendre aussi. On peut toujours être vulnérable lorsqu'il y a une potentielle vulnérabilité, mais le risque peut être plus élevé ou plus bas. Et ce qu'il faut comprendre aussi, c'est que le risque, il est dynamique. Et ça, c'est important aussi de se le rappeler, parce que c'est une question de visibilité. Et au plus on aura de données, au plus on connaîtra les configurations, on aura une visibilité sur quels projets ont un network externe, quels projets utilisent Windows, est-ce qu'on utilise Mac, etc. Au plus on connaîtra vraiment toutes les données concernant le projet ou l'application, on pourra avoir un risque qui est plus détaillé et plus précis. Et donc c'est important de le retenir parce que du coup, notre risque peut vraiment varier en fonction de ces données. Alors, on va passer à un exemple pratique.

14:18 Et moi, je vais me prendre un petit verre d'eau. Et je vais vous laisser un petit peu ruminer toute cette théorie avant qu'on passe de la théorie à la pratique. Voilà. Si vous pouvez penser à des questions aussi. Comme ça, on pourra utiliser les dix dernières minutes. Exemple pratique. Alors, j'ai choisi une vulnérabilité, ce n'est pas par hasard, elle est critique, et puis on va un petit peu comprendre ensemble comment est-ce qu'on fait ça et à quel niveau de risque est-ce qu'on peut arriver. Alors cette vulnérabilité, c'est une vulnérabilité dans le service CUPS, qui est une bibliothèque open source de langage C. C'est une vulnérabilité qui est... a fait beaucoup parler d'elle en septembre 2024, donc il faut savoir qu'elle était trending sur Twitter, parce qu'énormément de gens en ont parlé, ça a vraiment fait le buzz à ce niveau-là. Et du coup, forcément, quand on parle de risque, d'ailleurs, le risque augmente. Parce qu'on parle de cette sévérité, donc ça intéresse beaucoup de gens, les attaquants se disent« bon, si ça intéresse beaucoup de gens, c'est que beaucoup de gens l'utilisent, on a peut-être quelque chose, on peut peut-être attaquer beaucoup de gens en une fois».

15:30 Mais donc pour revenir à cette vulnérabilité, donc vulnérabilité dans le service CUPS, qui en fait permet à un attaquant d'introduire une imprimante malveillante dans le système de l'entreprise. Et une fois que cette imprimante malveillante est introduite, si un employé envoie un travail via cette imprimante malveillante, sans le savoir évidemment, le code est exécuté. Et une fois qu'il est exécuté, l'attaquant a la main sur tout. Il peut faire ce qu'il veut, il peut changer les données, il peut prendre les données, il peut faire ce qu'il veut. Donc forcément, là, on dirait bien que c'est critique. Alors, on va regarder un petit peu les données pour essayer de comprendre qu'est-ce qui se passe. Donc, en fait, de manière générale, et justement parce qu'il y a des réglementations et parce qu'il y a une prise de conscience autour de la cybersécurité, on sait bien qu'on met des systèmes de protection et de détection en place. Par exemple, un firewall.

16:32 Ce qui veut dire que si un attaquant va vouloir introduire une imprimante malveillante via cette vulnérabilité, il va devoir d'abord dépasser le firewall en premier. Donc déjà là, la probabilité d'exploitation baisse un petit peu. Ensuite, on a aussi de manière générale, aussi à cause de ces réglementations, des business units qui vont être séparés. Donc on va avoir par exemple le business unit de production, du système de production, qui va être par exemple sur un conteneur séparé. Et puis on va avoir la business unit des imprimantes, qui va peut-être être reliée par exemple à certaines choses qu'on voudrait imprimer, par exemple le menu du prochain happy hour. Donc du coup... Si l'attaquant arrive à mettre la main sur ce système-là, étant donné que ce n'est qu'une business unit, il va peut-être avoir les données du menu, mais ce ne sont pas des données confidentielles, ce ne sont pas des données qui sont importantes.

17:38 Et du coup, il y a encore un autre truc aussi que je voulais dire, c'est par exemple la maturité d'exploitation, le niveau de maturité d'exploitation. Alors il est de proof of concept. Il faut savoir que proof of concept, c'est un niveau qui est assez théorique. Et pour passer de la théorie à la pratique, comme on le sait tous, il y a quand même... Un certain processus à faire. Donc ça veut dire que l'attaquant va devoir avoir beaucoup d'expérience et de connaissances pour pouvoir faire cela. Encore une fois, la probabilité d'exploitation baisse. Et si on parle un petit peu de contexte aussi, il y a ce fameux« reachability». Parce qu'il faut savoir que cette vulnérabilité est présente à cause d'une fonction spécifique. Donc si on n'utilise pas cette fonction, finalement, on n'est sans doute pas si vulnérable que ça. Alors pas de panique, évidemment on ne va pas faire ça pour chaque vulnérabilité. Et du coup, je voudrais qu'on prenne un pas en arrière pour voir l'image globale. Et ici, on peut voir un projet avec des vulnérabilités de sévérité critique, mais finalement, le score est plutôt bas.

18:45 Et donc, on se rend compte qu'on arrive vraiment à faire ressortir les vulnérabilités qui comptent vraiment et que la vulnérabilité qui compte vraiment, ce n'est pas forcément une vulnérabilité qui est de base critique. Ça peut très bien être, par exemple, une vulnérabilité médium qui va tout d'un coup avoir un score plus élevé. J'en discutais tout à l'heure avec quelqu'un, d'ailleurs. Donc voilà, je l'utilise maintenant. Et voilà. Et donc, du coup, en fait, ici, on le voit. Et alors, encore une fois, il faut bien dire qu'il y a des systèmes qui sont automatisés aujourd'hui pour pouvoir faire cette priorisation et cette analyse qui est basée sur le risque. Donc, on ne doit absolument pas passer à travers chaque vulnérabilité et l'analyser comme nous venons de le faire maintenant ensemble. Je vous l'ai dit. juste vous montrer en fait et essayer de prouver quelque part qu'une analyse qui est basée sur le risque, elle est bien plus pertinente que la sévérité en elle-même qui ne prend que les caractéristiques qui sont propres à la vulnérabilité. Et si on prend encore un pas en arrière, on voit par exemple ici un projet où la moitié de ces vulnérabilités, si on regarde l'analyse qui est basée sur le risque, donc en mauve et en mauve plus foncée,

19:57 on peut voir les vulnérabilités high et critique. On voit qu'il y en a quand même beaucoup. Donc il y a bien la moitié en tout cas des vulnérabilités qui sont high et critiques. Et une fois qu'on applique une analyse qui est basée sur le risque, on voit vraiment ici, du côté droit, en tout petit, qu'on arrive à mettre en valeur les vulnérabilités qui comptent vraiment et les vulnérabilités qui sont réellement pertinentes dans la vie réelle pour l'entreprise. Et c'est à ce moment-là qu'on peut enfin pouvoir mettre les ressources nécessaires sur celles qui comptent vraiment. Et je voudrais juste revenir à la vulnérabilité qu'on a un petit peu analysée ensemble et montrer que d'une sévérité de 9, on passe à un score de 318. Bon, c'est d'une échelle de 0 à 1000, c'est comme ça qu'on le fait chez nous, point de vue granularité. Mais ce que j'essaye de dire, c'est que de 9, sur la même échelle, on est passé à 3.

21:00 Alors ça, encore une fois, c'est pour une entreprise bien spécifique et ce n'est qu'un exemple. Et peut-être que dans votre entreprise ou dans une autre, le score sera plus élevé ou plus bas, encore une fois dépendant du contexte. Mais on voit bien ici la différence que l'on obtient quand on analyse les vulnérabilités en se basant sur la sévérité et quand on analyse les vulnérabilités en se basant sur le risque. Alors, on va récapituler. Il y a trois points pour moi qui sont importants. J'en ai mis quatre là, mais voilà, on va parler. Et le premier point, c'est qu'on ne peut pas tout fixer. Et en fait, ce n'est pas grave, ce n'est vraiment pas le but. Le but, c'est de nouveau de pouvoir mettre en valeur les vulnérabilités qui sont pertinentes et qui nous importent réellement. Deuxièmement, la sévérité, donc ce standard universel qui est utilisé pour prioriser les vulnérabilités, dans un monde qui est en constante augmentation de ce point de vue-là, ça ne suffit plus.

22:06 Et donc il faut bien comprendre qu'on doit utiliser le contexte pour pouvoir mettre en valeur ces vulnérabilités-là. Parce que la sévérité, ce n'est qu'une partie de l'histoire. Et nous, on veut l'histoire complète. Et ensuite, troisième point, le risque, évidemment. Le risque, c'est comme une boussole qui nous donne des informations concernant la probabilité d'exploitation des vulnérabilités, qui nous donne des indications par rapport au contexte de la vulnérabilité, l'environnement dans lequel la vulnérabilité se trouve. Et c'est grâce à ça... qu'on va pouvoir mettre nos ressources de façon efficace, afin de pouvoir fixer les vulnérabilités qui comptent vraiment, de façon rapide. Simple, efficace et surtout automatique. Si vous avez des questions, n'hésitez pas. Merci beaucoup. Merci, bravo.

23:14 Merci. Et bien maintenant, nous allons ouvrir 10 minutes de session questions-réponses. Alors, qui se lance? Qui se lance? Ah, on a une première main tout au fond, toujours le quatrième rang. Ah, ça va jusqu'à la fin, je la tiens là. Oh, mais on a des gens au-dessus! Coucou! Ah, sympa! Oh! C'est la première fois qu'on a des gens au-dessus! Bon, pardon, ils sont peut-être un petit peu mieux installés que vous. Bonjour, merci beaucoup pour cette présentation. Je trouve ça très pertinent, évidemment, de prendre tout le contexte en plus de la sévérité. Ma question est plus par rapport, surtout quand on fait du B2B, en SAS, on signe un contrat dans lequel on a des SLS. Et en fait, la seule chose qui est prise en compte sur la vulnérabilité, c'est justement cette criticité. Et donc, comment est-ce que vous avez déjà ces cas-là? Comment vous faites dans ces cas-là? Oui, alors c'est une très bonne question parce qu'effectivement, on a beaucoup d'utilisateurs qui, eux aussi, ne regardent que la sévérité.

24:19 C'est un petit peu aussi comme Antoine, duquel je parlais dans ma présentation. qui, lui, n'osait pas mettre de côté cette sévérité, parce qu'effectivement, c'est un consensus. Je pense qu'on doit vraiment, et c'est pour ça que je suis là aussi, pour essayer de faire comprendre aux gens qu'une analyse qui est basée sur le risque, en fait, finalement, elle est bien plus pertinente parce que chaque vulnérabilité est différente, en fait. Elle a la même propriété en elle-même, mais une fois qu'elle se retrouve dans tel ou dans tel projet, c'est complètement différent. Et je pense que c'est ça qu'il faut petit à petit essayer de faire comprendre et de faire changer cette conscience qui est autour, en fait, de la sévérité, parce que c'était très bien avant, avant quand on avait moins de vulnérabilité et qu'on pouvait tout fixer, ou fixer ce qui était critique et ce qui était high, c'était très bien. Mais maintenant, malheureusement, ça ne suffit plus parce qu'il y en a trop et qu'on n'arrive plus à suivre et que le marché en demande beaucoup aussi des développeurs de devoir tout le temps...

25:24 Continuer à développer du code rapidement. Et voilà. Du coup, je pense que c'est vraiment... Je comprends et je pense qu'il faut essayer d'expliquer et de faire voir vraiment la vision complète des choses pour peut-être un petit peu faire changer ce standard. Merci, Havaya. Il y avait une deuxième question, il y avait une autre main levée. Ici, alors le micro va vous arriver incessamment sous peu, je l'espère, en célérité certainement aussi, peut-être. Merci pour la présentation. Pour les environnements cloud, on entend beaucoup parler des CNAP comme WIS par exemple, où ils vont voir le contexte, notamment vraiment tout l'aspect de run. Comment vous vous placez? C'est là où vous avez l'air vraiment orienté, très code, mais aussi on va dire sur l'infra qui tourne derrière. Du coup, c'est vrai qu'on a certains éléments, justement, pour un petit peu parler de l'environnement dans lequel la vulnérabilité se trouve. Donc, ça va être, par exemple, de savoir si le code est exécuté sur, par exemple, est-ce qu'il a une connexion, un public facing?

26:34 Est-ce qu'il peut parler avec l'extérieur? Est-ce qu'il a accès à un network externe? On va regarder aussi justement les données en runtime, donc en temps réel, parce qu'avant c'était plutôt statique et on essaye vraiment d'aller vers un stade où du coup les données, elles sont constamment mises à jour. On va regarder aussi par exemple dans quel environnement OS la personne lance son code, donc est-ce que ça va être Windows, Linux, etc. Et voilà, je pense que c'est quelque chose qui est très important, justement pour avoir toutes les données pour pouvoir se baser là-dessus et avoir un risque qui est assez complet. Merci, Havaya. Une autre question. Non, aucune main. Ah, donc à droite. Oui. Le micro va arrêter. Ah non, pas de... Merci beaucoup. J'aurais voulu savoir l'effort qui doit être fait pour avoir le contexte. Parce que, excusez-moi, je suis... Ah ok, voilà, je vois.

27:37 C'est vrai que les outils qui nous ramènent les CVE sont assez simples. Parce qu'en fait, ils scannent. Et là, quel est l'effort nécessaire pour avoir tout le contexte, y compris avec du contexte d'infra? Pour que ça puisse fonctionner correctement? Votre question, j'essaie de la reformuler pour être sûre que j'ai bien compris. C'est de quels sont les outils à utiliser pour pouvoir connaître le contexte dans lequel la vulnérabilité qu'on a scannée se trouve, c'est ça? Non, en fait, ma question, c'est de savoir quelle est la différence entre l'implémentation d'un outil comme vous vous présentez versus un cyberwatch qui vient juste de remonter les... Les sévérités de ce que j'ai sur mon infrastructure? Je ne suis pas sûre d'avoir compris, alors vous pouvez répéter. Comment est-ce qu'au-delà, quand vous scannez le code, vous allez voir que dans le code, il y a des failles qui sont exploitables, quel est l'effort nécessaire pour pouvoir avoir le contexte? Pour pouvoir dire, ok, en fait, oui, la faille est présente, mais elle n'est pas utilisable. Oui. Qu'il y ait la phase préparatoire, en fait, pour que l'outil soit vraiment efficace. Voilà, oui.

28:38 Alors, ça dépend évidemment des outils. Par exemple, chez nous, c'est vrai que du coup, on a plusieurs principes. On a par exemple le principe de reachability qui utilise un modèle AI pour pouvoir justement scanner le projet et comprendre en fonction des dépendances qu'on utilise. pour pouvoir détecter si telle ou telle dépendance utilise in fine la fonction qui est vulnérable ou la bibliothèque open source qui est vulnérable, parce qu'il y a différents stades de reachability. On a par exemple, comme je le disais, des insights qui entrent en compte, et ça, ça vient plutôt justement, par exemple, de Kubernetes, qui va venir dire quels sont les éléments ou les configurations qui sont utilisées. J'imagine que ça peut différer en fonction des outils et des produits, mais voilà, c'est vrai qu'on a toutes sortes d'outils qui sont basés aussi sur l'IA et des outils aussi qui sont là pour voir justement les configurations et mieux comprendre le contexte et le business impact des utilisateurs.

29:42 Et puis par exemple aussi, les utilisateurs peuvent définir par eux-mêmes quels sont les projets qui sont plus pertinents, plus critiques que d'autres. Si c'est un projet qui est vraiment central, ils peuvent le noter avec une certaine note et ce sera pris en compte finalement dans l'algorithme du score. Merci, il y avait une autre question pour monsieur. Un, deux, trois, quatrième rang. Mais c'est le vrai. Bonjour. Bonjour. Merci. C'est pour moi. Le vrai quatrième rang. Merci. Ma question est fortement liée à la question précédente. C'est vraiment lié au contexte et je trouve que la notion de reachability est hyper importante. Est-ce que dans l'outil Snyk, vous prenez en compte par exemple les chemins de pénétration, c'est-à-dire le fait de pouvoir rebondir en prenant le contrôle à partir d'une première vulnérabilité, de traverser le réseau et de pouvoir ensuite accéder à des ressources qui peuvent être plus critiques? Est-ce que c'est quelque chose qui est pris en compte dans le score?

30:43 Alors, on regarde d'une part les dépendances. Donc, si par exemple, on utilise une bibliothèque open source qui a certaines dépendances, de manière générale, c'est ce qui se passe. On va regarder dans toutes ces dépendances et donc essayer de revenir à la vulnérabilité. Donc, on va vraiment détecter des vulnérabilités qui sont peut-être plus loin dans cet arbre de dépendance. Donc, ça, c'est d'une part. Et si la question était plutôt basée sur la chaîne de vulnérabilité qui peut être utilisée, donc peut-être utiliser d'abord une vulnérabilité et puis une autre et puis une troisième pour arriver à ses fins, ça, on en parle beaucoup, mais je ne pense pas qu'on le fasse chez Snyk. Mais par contre, oui, tout ce qui est arbre de dépendance et donc les vulnérabilités, vulnérabilités qui sont plus loin et en amont, ça oui, tout à fait, on sait le détecter grâce à ce système de reachability. Parfait. Une autre question éventuellement? Ah, pardon, là-bas, oui, effectivement, je ne vous avais pas vu.

31:47 Et ce sera la dernière puisqu'il nous reste une minute. Alors, merci pour la présentation. Moi, j'ai une question qui recoupe un peu avec la présentation sur construire demain avec l'IA. C'est-à-dire que quand on voit le graphe, en fait, on voit qu'il y a beaucoup de vulnérabilités qui continuent à pulluler et que nos équipes ici passent toute leur vie à corriger les dépendances. C'est du gaspillage. Et moi, j'ai une question par rapport à ça. Est-ce qu'il y a des initiatives comme des pandas bots sur GitHub qui essaient de corriger les vulnérabilités dans les paquets d'open source qui sont détectés? Est-ce qu'il y a des initiatives qui vont dans ce sens? Et la question corollaire, c'est est-ce qu'aujourd'hui, au niveau des assistants de code ou autres, on a des initiatives qui corrigent des dépendances à la source. Alors, merci pour votre question. Sur GitHub, tout d'abord, je ne pense pas qu'il y ait une analyse qui soit basée sur le risque. C'est vrai qu'on regarde un petit peu les vulnérabilités qui sont exposées via GitHub, les GitHub Advisories.

32:51 Et là-dessus, en tout cas, moi, je n'ai jamais vu un score ou quelque chose qui est vraiment basé sur le risque, tout simplement parce que je pense que GitHub, c'est vraiment là. la plateforme avec toutes les bibliothèques open source qui s'y trouvent. Et finalement, ils n'ont pas justement ce contexte parce qu'il faut qu'il y ait un certain programme qui puisse voir le contexte et avoir une visibilité sur le contexte de l'utilisateur. Donc personnellement, moi, je n'ai vu que des vulnérabilités qui avaient justement une sévérité, un CVSS score, mais pas quelque chose qui soit basé sur le risque. Et la deuxième partie de la question? Oui? Oui, oui, oui, ok. Du coup, effectivement, comme je l'ai dit, chez Snyk, on trouve les vulnérabilités justement à la source, dans les dépendances, et puis ensuite, on donne ce score qui est basé sur le risque, qui est basé sur toutes les données qu'on a

33:59 ou que les utilisateurs ont activées sur leur compte. Donc ça, c'est une chose. Et concernant l'IA, je sais que nous, on a essayé un petit peu de voir, par exemple, sur ChatGPT ou des choses comme ça, comment est-ce que ça marche. Je pense qu'on n'est pas encore arrivé à un stade où vraiment ce genre de choses peuvent réellement donner une réponse qui soit complète. On n'en est pas encore là. Et c'est vrai qu'en fait, en tout cas, nous, notre vision des choses, c'était de faire un score qui soit vraiment transparent pour les utilisateurs, pour qu'en fait, chacun d'entre nous puisse comprendre. Donc, si quelqu'un veut vraiment connaître la formule, il peut la connaître. Il n'y a aucun souci. Et vraiment, le but ici, c'était d'avoir une visibilité et d'essayer de faire comprendre le risque pour justement que les utilisateurs et que les entreprises, de manière générale, veuillent l'adopter. Et donc, en fait, quelque part, on a fait exprès de ne pas utiliser des outils comme l'IA. ou des modèles machine learning, etc.

35:02 Parce qu'on ne voulait pas avoir une boîte noire. On voulait vraiment avoir une transparence totale concernant le risque. Merci beaucoup, Havaya. Merci infiniment d'être passée parmi nous pour cette huitième édition du Tech.Rocks Summit. Bravo!