Live Hacking Session

0:09 Bonjour, je m'appelle Jennifer Granja, je fais partie de la famille de Snyk, je travaille à Snyk concrètement. Snyk est une société qui développe une plateforme de sécurité pour les développeurs, dédiée aux développeurs. Mais aujourd'hui, ce n'est pas une présentation de ma plateforme que je vais vous faire, c'est plus une présentation orientée autour de la sécurisation des applications, avec un petit peu de live hacking, pour vous faire comprendre qu'effectivement, il y a des risques associés à développer des applications, des risques qui sont associés à la manière dont on développe ces applications. Et aujourd'hui, je vais essayer de vous faire passer ce message au travers de ces 30 minutes de workshop. Donc, je vais aller un petit peu plus en détail sur l'agenda, mais comme je l'ai défini, le sujet aujourd'hui, ça va être les applications, qu'elles soient web ou mobile. Toutes les applications qui sont omniprésentes dans votre vie de tous les jours, comme le website Tech.Rocks que vous avez utilisé aujourd'hui, l'application mobile que vous avez potentiellement utilisé pour venir jusqu'ici ou autre.

1:11 Toutes ces applications sont omniprésentes. Et à l'heure actuelle, il y a des systèmes sur vos mobiles, sur vos ordinateurs pour protéger votre navigation. Mais ça ne va pas être le sujet que je vais évoquer aujourd'hui. Le sujet que je vais évoquer aujourd'hui, ça va être en lien avec la manière dont ces applications sont développées. Donc comment aider les développeurs? Je ne sais pas s'il y en a dans la salle, mais comment les aider pour le... Coup à des... J'en ai peut-être un derrière qui a fait oui avec la tête. Donc comment les aider et participer au final à la sécurisation des applications sans séparer l'équipe de sécurité et les développeurs, mais apporter des conseils, apporter des outils qui soient directement intégrés dans leurs outils de tous les jours, plutôt que les imposer, aller sur un outil complémentaire pour pouvoir acter sur ces vulnérabilités de sécurité. Donc c'est les sujets qu'on va aborder aujourd'hui. Et l'agenda va être orienté autour des composants open source que ces développeurs utilisent. Donc on ne va pas parler SAST, on ne va pas parler sécurité des containers, on ne va pas parler cloud security. On va parler des composants open source. Je vais les décrire un petit peu en détail puisqu'on a un public potentiellement de personnes qui connaissent les composants open source et certaines personnes qui ont besoin d'une description.

2:19 Et après, je vais vous montrer comme il peut être compliqué de bien connaître ces dépendances au travers de quelques exemples. Et on va avoir un petit quiz. Jérémy et Anthony, qui vient juste d'arriver, la personne en retard, c'est chez nous, vont distribuer des cadeaux pour les gens qui répondent bien au quiz. Donc, je vous invite à suivre. Et puis, c'est le bon point, c'est ça. Et puis, je vais vous montrer un exemple de vulnérabilité liée à une dépendance et un petit peu de live hacking pour vous montrer comment en cinq minutes, il est possible d'accueillir une application qui utilise ce composant open source et qui peut effectivement ouvrir une backdoor. Enfin, on terminera sur comment y remédier avec 5 minutes où je vous expliquerai effectivement qu'il est possible d'y remédier. Je vous inviterai à... Rejoignez notre stand pour en savoir plus. Donc voilà. Alors, l'open source, désormais omniprésent dans le développement de logiciels. Donc vous le savez probablement tous, maintenant on utilise de l'open source un peu partout. Pourquoi? Parce que ça a de nombreux avantages, la flexibilité, la pérennité, la transparence du code source qui permet une collaboration et tout un volet communautaire de pouvoir travailler sur ces composants.

3:23 Vous les connaissez au travers de langages de programmation qui sont open source et qui permettent pour le coup à vos développeurs de pouvoir développer les applications potentiellement sur lesquelles vous travaillez. Vous les connaissez potentiellement au travers de librairies de développement comme NPM, Papai que j'ai indiqué ici et on va parler NPM aujourd'hui. Et vous les connaissez certainement au niveau des systèmes d'exploitation comme Android et Linux que je vais utiliser tout à l'heure pour la session de l'IVAQ. Donc, cet open source est omniprésent, ces composants open source sont omniprésents. Ils peuvent être sécurisés puisque, comme il a indiqué, il y a une transparence du code source qui permet à la communauté de vérifier le niveau de sécurité de ces composants. La problématique, c'est que parfois, ils peuvent cacher des composants derrière, au final, qui peuvent contenir des vulnérabilités qui ne sont pas forcément visibles lorsque vous les appelez dans votre application. Et puisque ces composants, j'ai complètement oublié cette slide, on va revenir un petit peu, mais puisque ces composants open source, effectivement, sont partout, les librairies qui sont utilisées par vos développeurs, donc les librairies open source de NPM, de...

4:30 Par exemple, Maven de Papai constitue désormais, et c'est une source qui vient du Open Source Security Report de 2022, qui indique qu'au sein des applications modernes, à l'heure actuelle, vous n'avez pas 80% de source code et 20% d'open source, c'est 80% d'open source, donc 80% de ces librairies qui représentent les lignes de code de vos applications, applications modernes comme l'indiqué, et seulement 20% du code source. Ce qui veut dire que lorsque vous effectuez un SAST, c'est seulement 20% de votre application que vous scannez. Lorsque vous effectuez un scan de composition analysis, software composition analysis scan, c'est 80%, donc c'est le reste de votre application que vous scannez. Et pourquoi ces scans open source sont importants? Puisque ces librairies, ces composants au final qui sont amenés par les développeurs au sein d'une application, contiennent des dépendances transitives. Donc, qu'est-ce qu'une dépendance? C'est par exemple un package que vous voyez express, qui est un framework minimaliste pour JavaScript, qui est largement utilisé pour construire une application web.

5:41 Donc, ce que le développeur va voir, ce que le développeur va indiquer dans son fichier manifeste, ça va être dépendance express qui va être utilisée lorsque l'application va être construite. La problématique, c'est que derrière Express, par exemple en version 4.12, ici, vous avez Accept, qui est un composant nécessaire à la fonctionnalité d'Express. Vous avez un composant MAM type en 2.1 qui est un composant aussi, un outil qui est associé à Express. Vous avez un autre composant MAMDB et vous avez au final toute une hiérarchie de composants associés à ces dépendances open source que vous utilisez et qui ne sont pas forcément visibles pour les développeurs. Et je vais vous donner un exemple, puisque Express est largement utilisé, et je vais cliquer sur ce site web qui vous montre au final l'ensemble des associations associées à chaque package. Donc là, vous avez Express qui est la dépendance. direct et associé à Express, vous avez l'ensemble des notes qui apparaissent et qui représentent les dépendances transitives, les transitives de transitives et les différents packages qui sont associés à Express et qui ne sont pas visibles par les développeurs lorsqu'ils l'appellent dans le fichier manifeste.

6:50 La problématique que vous avez, c'est que vous voyez l'ensemble de ces composants transitifs qui sont associés à Express, vous voyez, vous avez une quarantaine de maintainers qui sont associés, qui font partie de la communauté open source, qui ne travaillent pas pour vous, qui ne sont pas collègues de votre développeur et qui potentiellement peuvent être bienveillants, parce que pour la plupart dans la communauté, ils aident au final à développer, à maturer ce décomponent express. Mais il peut y avoir certaines personnes qui sont potentiellement malveillantes et sans avoir la visibilité sur ces composants annexes, ces composants transitifs, vous pourriez avoir par exemple un composant qui ouvrirait une backdoor au sein de vos applications. Donc, c'est là l'idée de sécuriser au final vos applications, aussi bien sur la partie SAS que sur la partie SIA, tout simplement pour pouvoir avoir, et on va revenir sur les slides, pour pouvoir avoir une visibilité sur ces composants-là. La petite image, c'est pour les personnes qui ne comprennent pas très bien les dépendances, c'est les dépendances transitives.

7:53 L'idée, la métaphore derrière, c'est imaginez, je vous invite tous chez Anthony pour un apéro. On vous a scanné juste devant, on a vos noms et prénoms, mais chacun de vous amène une personne, un conjoint, une conjointe, un meilleur ami ou autre, un collègue, et puis chacun de ces conjoints, conjointes, collègues amène d'autres personnes. Vous imaginez bien que ce serait difficile pour Anthony de pouvoir analyser chacune des personnes et pouvoir comprendre qui est là puisqu'il ne pourrait pas vous scanner. L'idée est la même chose, quand les développeurs invitent au final ces dépendances open source au sein de leur application, qui ils invitent d'autres, c'est cette visibilité dont potentiellement vous avez besoin. Et ça, je vais vous le prouver, je vais vous prouver que ce n'est pas seulement Express qui a cette problématique, il y en a bien d'autres et on va faire ce petit quiz dont je vous ai parlé avant pour voir si vous connaissez vraiment vos dépendances. Donc on va parler du package registry NPM, qui est un package registry JavaScript qui est largement utilisé. Il y a à peu près plus d'un million maintenant de dépendances qui sont disponibles.

8:56 Et on va voir les idées reçues qu'il y a sur ces packages à travers de trois questions. La première question, et on va le faire en mode 20 levées, quel est le pourcentage de package sur NPM qui inclut des dépendances transitives? Je vais demander de lever les mains pour les personnes qui pensent que c'est 20%. Personne? 56%? C'est-à-dire la moitié des paquets utilisés en détransitive? Non? 72%? Ça commence à lever des mains. Et 100%? Alors, il y a la moitié de la salle, effectivement, qui a raison. 72%, c'est-à-dire trois quarts. Les verts, ils vont arriver. C'est-à-dire 72%, trois quarts des dépendances directes que vos développeurs utilisent, effectivement, ont des dépendances transitives qui ne sont pas visibles dans leur application. Deuxième question. Quelle est la longueur moyenne arrondie d'une chaîne de dépendance de package sur NPM? Donc, combien de transitives? Et je ne parle pas juste des transitives directes, pour le coup, des transitives de transitives.

10:00 À quel NPM amène ? Levez les mains pour les personnes qui pensent que c'est 1. Deux. Vous savez que je mets les réponses à la fin, c'est ça? Trois. Ça commence à lever des mains. Et quatre. Et la réponse, effectivement, c'est 4. Donc, vous avez jusqu'à... Il faut jeter un coup d'œil. Donc, la réponse, effectivement, c'est 4. Et ça veut dire que vous avez jusqu'à 4 transitifs qui sont associés avec vos packages. Dernière question. Et là, vous voyez 101%, il y a plus d'un million de packages NPM, mais parce que ça date de 2020 pour le coup. La dernière question, c'est combien de packages sur Registre NPM pourraient être considérés comme abandonnés? C'est-à-dire qu'au-delà de la maintenance qui peut se faire en continu et qui peut invoquer des outils malveillants, vous avez aussi un manque de maintenance qui peut inciter ou qui peut engendrer une problématique, une vulnérabilité, une faille de sécurité. Donc, qui pense que 7% à l'heure actuelle des paquets de chorigines MPM peuvent être considérés comme abandonnés?

11:04 C'est-à-dire qu'ils ne sont pas maintenus depuis les 12 derniers mois. Personne à 15%. 15% monsieur, 27%. Une autre, non? Pardon? C'est toutes les versions comprises? C'est une bonne question. Donc c'est effectivement toutes versions confondues, puisque ce qu'on va prendre, c'est les informations relatives aussi aux versions antérieures qui sont, on va dire, pas complètement abandonnées, mais qui ne sont pas maintenues. 12 derniers mois. Et ensuite, 61%. Effectivement. Bon, vous avez tous raison sur celle-là. C'est effectivement 61%. Voilà. Voilà. Ça y est, vous avez pris le coup. Il n'y en a pas d'autres, de toute façon. Donc effectivement, c'est 61% des packages qui ne sont pas maintenus. C'est-à-dire que lorsque vous utilisez la dernière version d'un package, potentiellement depuis les 12 derniers mois, il n'y a pas une maintenance et potentiellement, il peut y avoir des vulnérabilités associées. Donc le risque de l'open source, je voulais plus ou moins démontrer, c'est que vous avez potentiellement une infrastructure moderne associée à une application moderne, mais qui potentiellement se repose sur des composants qui ne sont pas aussi modernes,

12:12 puisque pas maintenus, ou potentiellement peut invoquer des vulnérabilités. Et il y a une étude en juillet dernier, donc une étude qui remonte à trois mois, qui justement met en évidence que sur NPM, ce package enregistré que je vous ai montré, il y a de nombreuses, en tout cas une douzaine qui a été démontrée, malicious data harvesting, donc des exploits qui potentiellement, des composants malicieux qui permettent de... J'ai envie de dire choper des données, je suis désolée, je n'avais pas trouvé le mot, au sein des packages NPM. Donc je vais vous montrer un exemple et c'est la log4shell. Je vois que ça en fait sourire certains, on vous a rabâché avec leur 4shell depuis tellement de temps, peut-être que vous en avez marre. Mais au final, il y a deux semaines, il y a eu encore au final un... une Federal Agency qui s'est fait attaquer ou en tout cas qui s'est fait exploiter au travers d'un log4shell. Donc c'est pour ça qu'aujourd'hui, même si ce n'est pas un composant JavaScript, mais un composant Java, je vais vous montrer effectivement le risque associé à ces composants open source.

13:16 Donc, Log4Shell, qu'est-ce que c'est? Donc, Log4Shell, c'est la vulnérabilité qui a été détectée en décembre dernier, qui est relative à une vulnérabilité d'exécution de code à distance. Donc, c'est la possibilité donnée par ce composant open source de pouvoir attaquer ou exploiter, disons, votre application à distance. Et il est relevé au travers du composant vulnérable qui a été très largement utilisé, c'est Log4J. Donc, c'est le package nommé Log4J qui est largement utilisé tout simplement puisque c'est un composant qui va permettre la journalisation dans le cadre d'applications. C'est-à-dire que lorsque vous loguez à une application, c'est ce composant-là qui va permettre de loguer les informations relatives à votre login et qui va pouvoir donner des informations au back-end ou aider au support ou autre. Donc, ce composant largement utilisé dans les applications mobiles, web, il peut être aussi utilisé dans l'IoT. Donc, quand cette vulnérabilité a été découverte, pour le coup, ça a fait beaucoup de bruit. Et c'est pour ça que potentiellement, beaucoup d'entre vous en ont entendu parler.

14:18 L'impact de cette vulnérabilité, c'est que lorsque une personne se logue dans un scénario normal, la possibilité, l'utilisateur va lancer une... une requête HTTP, c'est-à-dire je mets mon nom, mon password, Jenny, password, password pour le coup, et le serveur HTTP va envoyer le log dans une base de données ou au sein d'un LDAP qui va enregistrer mes informations. Ce qu'ont découvert les cybercriminels ou les personnes qui ont découvert la log4shell pour le coup, c'est que lorsque vous inscrivez un exploit, donc vous parsez un string pour le coup, au sein de ces entités de log ou au sein d'un chat sur un serveur, vous avez la possibilité de créer un referral, donc créer en final un port de connexion ou en tout cas une connexion qui va permettre au final de query des informations sur cette base de données, sur le LDAP server, qui va permettre d'avoir les informations relatives à l'application qui a été par exemple pénétrée,

15:26 les informations par exemple personnelles ou déposer un logiciel malveillant s'il y a des plus grandes vulnérabilités qui sont proposées derrière. Et je vais le prouver au travers d'une démo. Et je mets une démo time parce que ça marche une fois, quatre fois sur cinq. Donc j'espère que ce n'est pas la fois sur cinq qui ne va pas marcher aujourd'hui. Donc je vais arrêter mon écran et on va aller sur une VM, sinon les organisateurs n'auraient pas beaucoup aimé. Donc on va se mettre sur une petite VM, on parlait de Linux juste avant, vous voyez, moi aussi j'utilise des composants open source. Donc j'espère que ça va pour le coup bien s'afficher. Oui, vous devriez avoir. Donc là, j'ai une application vulnérable que je vais lancer sur un Tomcat, puisque ça fait effectivement, c'est le Tomcat qui va permettre au final l'exploitabilité de cette application. Donc, vous voyez, j'ai une vulnérable application ici. Je vais lancer le Tomcat tout de suite et mon application va se lancer sur mon local host.

16:28 Donc, ça va prendre quelques secondes. Vous allez voir, ça va démarrer direct. Parfait. Hackmecorp, application toute simple, on n'est pas allé chercher très loin. Et vous voyez ici, par exemple, que là, lorsque je vais rentrer mon username et password, Retenez pas s'il vous plaît. Oui, je sais. Welcome back admin. Je suis admin d'une application avec un password super sécurisé. Donc là, qu'est-ce qui s'est passé? Au sein de mon application ici, donc là, je suis au sein de mon IDE, je vais un peu nettoyer, ça va être plus simple pour vous pour voir. Ce que j'ai amené, c'est au sein de mon POM XML, qui est ce manifeste dont je parlais tout à l'heure, j'ai appelé au composant log4j. Donc, vous voyez, il est juste ici. Impeccable. Log4j qui me permet derrière ce composant Log4j que j'ai appelé sur mon manifeste, dans ma web app, d'avoir une fonction login servlet qui va me permettre de dire si,

17:31 par exemple, j'ai un admin qui se connecte avec mon admin et passeport. Dans ce cas-là, il y a Welcome Back Admin qui s'affiche. Sinon, else, vous voyez ici, sinon l'information est loguée et envoyée effectivement au backend pour expliquer effectivement la problématique ici. Donc, je requeste ce log tout simplement pour des volontés de troubleshooting. Donc ça, j'ai tous ces composants qui sont mis en place, qui sont courants. dans des applications. Et c'est ça qui va être utilisé par un exploit ou par une personne malveillante qui va utiliser la log4share. Donc maintenant, on va ouvrir un terminal. Je vais juste ouvrir mon RIMI, comme ça, je vais faire des simples copier-coller. On va aller de manière un peu plus simple. Donc, ce qu'on va faire, c'est que de notre côté, on va juste ouvrir un HTTP serveur sur le port 80. C'est juste parce que là, à l'heure actuelle, l'application, elle est sur mon local host et j'ai besoin d'un HTTP démon pour pouvoir communiquer. Donc, on va tout simplement l'ouvrir.

18:35 Et mes raccourcis ne marchent pas. Oops. Vous voyez, celui-là, il est caché. Donc là, j'ai un serveur HTTP qui est ouvert sur mon port 80. Ça va être important après pour l'exploit. Je vais installer, je vais ouvrir un listener. Le listener, je vais l'utiliser tout simplement pour ensuite envoyer mes requêtes malveillantes. Donc, c'est ce qui va me permettre de... C'est ce qui va me permettre pour le coup de faire ce qu'on appelle un reverse shell. Donc, c'est ça qui va me permettre à partir de mon ordinateur ici de pouvoir attaquer ou exploiter cette application. Donc là, j'ai listening sur le port 9001. Et ensuite, je vais pouvoir lancer l'exploit. Parce que là, ce qu'on croit souvent, c'est que ces exploits, au final, ils sont difficiles à trouver. Vous avez des exploits qui sont à l'heure actuelle disponibles sur GitHub, bien sûr sur le Dark Web. Et là, vous avez un exploit pour le coup qui est disponible sur Python 3. Donc là, c'est pour une démonstration.

19:37 Mais vous voyez, je vais lancer mon exploit. Et pour pouvoir créer ce string que je vais devoir copier dans mon admin, l'exploit va me demander quel est du coup l'IP. Alors là, c'est localhost, donc c'est assez facile pour moi. Ensuite, va me demander le HTTP démon, où il est, donc le LDAPREF server sur lequel je vais pouvoir communiquer. Donc là, c'était sur 80. Et le listener shell qui a été mis sur 9001 ici. Donc là, j'ai toutes les informations qui vont permettre à ce petit exploit de créer le string que je vais copier. On va le copier tout de suite et que je vais directement coller dans ma barre d'admin ici. Donc, au lieu de mettre admin, je vais mettre pour le coup ces strings et je vais cliquer sur login. Et vous allez voir, ça va mouliner un peu tout simplement, mais on va pouvoir voir cette connexion s'effectuer parce que là, vous voyez, j'ai mon listener. Donc, la commande que j'ai envoyée juste avant, le N4 sur le port 9001 qui a été effectivement connecté.

20:44 Donc connection receive sur mon localos le 127.001 et on voit ici que la LDA préférence résulte à une redirection sur cette exploit class. Et là maintenant ça y est au final je me suis rendu compte que mon application me permettait de pouvoir accéder, en tout cas me laisser la porte ouverte, c'est la première phase d'attaque, c'est vérifier l'ouverture de la porte. Donc là je suis une personne mal intentionnée, j'ai une application qui est ouverte pour moi et que je vais pouvoir attaquer. Et là, la première information, par exemple, que je vais demander, c'est où I am, Jenny. Je vais pouvoir LS, c'est-à-dire voir l'ensemble de l'application et les informations relatives. Je peux clouer la DB, je peux effectivement aller plus loin dans mon attaque. Donc vous voyez en trois étapes, j'ai vérifié qu'une application était ouverte pour pouvoir effectivement la pénétrer et j'ai pu rentrer sur cette application juste en ayant un simple exploit que j'ai trouvé potentiellement sur le Darknet et qui m'a permis de constituer ce string sans que j'ai vraiment à m'embêter à le constituer puisque j'ai pu le faire en quelques minutes.

21:51 Et c'est en ça où ces composants open source peuvent être dangereux parce qu'ils peuvent amener à ce type de vulnérabilité sans que vous soyez vraiment au courant et sans que vous ayez cette information. Donc je vais partir de... On va retourner sur les slides. Parfait. On va retourner sur les slides. Maintenant, comment y remédier? Et c'est là où on pourrait vous faire une démonstration personnalisée de comment Snyk fonctionne, mais je vais vous donner un peu dans les grandes lignes comment y remédier, parce que je n'ai pas envie que vous parliez tous. En plus, pour certains, peut-être que vous avez faim. Mais la manière d'y remédier, c'est de mieux gérer, au final, ces dépendances open source. Donc, vous pouvez les maintenir en continu, les corriger en continu. Ça va être important, mais au final, c'est cette visibilité qui va être importante. Puisque même si on vend des outils, donc je fais partie d'une entreprise qui vend au final des logiciels, ce n'est pas le logiciel qui est le plus important, c'est le modèle associé qui va être le plus important.

22:52 C'est-à-dire, c'est votre stratégie que vous allez associer qui va être la plus importante pour pouvoir sécuriser vos applications. De manière traditionnelle, on mettait en avant, ou peut-être vous mettez encore en avant, des tests qui sont effectués après développement, qui sont beaucoup basés sur de l'audit, par exemple des pentests, qui sont tout aussi importants, puisque au final, les deux outils se complètent et c'est important d'avoir les deux visibilités, et qui prennent en compte code et infrastructure sécurisés de manière indépendante, alors que là, vous voyez, l'ensemble est important, puisque par exemple, cette vulnérabilité peut être pénétrée parce que je suis sur un Tomcat qui ne pourrait peut-être pas fonctionner dans un autre écosystème. Donc, code et infrastructure, les sécuriser de manière séparée, ça peut être problématique. où ça peut vous engendrer un manque de visibilité. Maintenant, une approche moderne de la sécurité, c'est des tests en continu. Vous les faites déjà potentiellement au sein de votre pipeline, mais c'est encore shift left. Ça va encore plus vers la gauche. Elle est directement dans l'IDE de vos développeurs pour les accompagner sur connaître la visibilité sur ces dépendances open source qu'ils amènent.

23:55 Donc, leur donner la visibilité sur ces vulnérabilités relatives aux transitifs qui sont associés. C'est basé sur les remédiations parce qu'au final, vous devez travailler main dans la main avec vos développeurs. Donc, si vous, personnel de la sécurité, par exemple, vous trouvez la vulnérabilité et que vous l'envoyez au développeur, s'il n'y a pas de remédiation associée, il n'est pas garanti qu'ils vont adapter les bons conseils de remédiation. Donc, c'est important aussi d'avoir plus d'accompagnement pour les développeurs pour pouvoir remédier ou comprendre comment remédier une vulnérabilité, au-delà aussi de les éduquer sur ces volets de sécurité. Et enfin, avoir une approche holistique, c'est-à-dire inclure le volet d'infrastructure, connaître aussi les vulnérabilités relatives à vos containers, connaître les vulnérabilités relatives aux fichiers de configuration que vous importez au sein d'une application. Donc bien sûr, comme je l'ai mentionné, Snyk peut aider. Snyk peut aider sur la partie open source, c'est-à-dire qu'on va vous donner des visibilités sur les transitives. On vous dira par exemple si ce jQuery drop, au final, contient des vulnérabilités au travers d'une transitive.

24:58 Et Snyk va pouvoir... effectivement aider sur cette partie de la lock for shell, non seulement pour trouver la vulnérabilité, mais aussi pour la corriger, accompagner le développeur à la corriger et le prévenir, puisque Snyk va pouvoir effectivement vous aider à garder cette visibilité et se maintient ce monitoring sur ces dépendances open source qui changent tous les jours, sur lesquelles des composants sont ajoutés tous les jours, sur lesquelles des transitifs sont ajoutés tous les jours. Donc il y a un monitoring constant effectivement effectué. Donc c'est la dernière slide. Bien sûr, si vous voulez une démonstration de la solution, n'hésitez pas à venir sur notre stand. N'hésitez pas à venir sur notre stand. On est tout à l'entrée, juste à côté du vestiaire. Donc n'hésitez pas. Dans tous les cas, il y a Anthony et Jérémy qui vous ont tous scannés. Ils vont vous envoyer des e-mails. Donc vous pouvez aussi répondre à cet e-mail. Donc n'hésitez pas à venir nous voir. Merci. Et puis n'hésitez pas.