Snyk Security Track @ AI Engineer World’s Fair

Introduction au parcours sécurité — Randall Degges, Snyk

Créer des logiciels avec l’IA, c’est presque comme avoir un code de triche : vous livrez ce sur quoi vous travailliez et voyez de vrais utilisateurs s’en réjouir. Mais, comme l’expliquera Randall Degges en ouvrant le premier Security Track de la World’s Fair, trois obstacles empêchent encore de passer à l’échelle. L’IA écrit du code non sécurisé, tout comme les humains ; les agents autonomes en production peuvent dérailler pendant votre sommeil ; et l’accès aux modèles de pointe peut vous être retiré à tout moment pour des raisons qui relèvent, en fin de compte, de la géopolitique. Tout cela se résume à un problème toujours sans solution : utiliser l’IA sans crainte et garantir sa sécurité par défaut.

Agentic Development Security — Ezra Tanzer, Snyk

Un agent chez Replit a ignoré un gel des modifications, supprimé une base de données de production, puis inventé des enregistrements pour le dissimuler, avant d’annoncer que la récupération était impossible. Il se trompait sur la récupération, mais la suppression, elle, était bien réelle, et il n’agissait pas par malveillance. Il voulait aider. Voilà le cœur dérangeant de la sécurité du développement agentique : le risque ne concerne pas seulement le code qu’un agent écrit, mais aussi ce à quoi il peut accéder et ce qu’il décide de faire. Ezra Tanzer dirige la gestion des produits sur ce sujet chez Snyk et l’aborde selon trois piliers : sécuriser ce que les agents génèrent, ce qu’ils utilisent et ce qu’ils font.

Dans le brouillard de l’IA : la décision architecturale dont dépend la sécurité agentique — Manoj Nair, Snyk

Demandez aux derniers modèles de pointe, même ceux qui ne sont pas encore publics, de détecter cinq fois la même vulnérabilité : seule la moitié de leurs tentatives y parvient. Face à un simple outil de vérification déterministe, ils n’ont détecté que 75 % des problèmes au maximum, avec un score F1 de 40 %. Ce chiffre est au cœur de toute la présentation : le générateur et le validateur ne peuvent pas être le même système. Manoj Nair dirige chez Snyk l’équipe qui sécurise quelque 5 000 entreprises, dont la moitié des sociétés du Fortune 500, et les données qu’il a présentées sont inquiétantes. Parmi 4 800 clients, le retard de traitement des problèmes de sécurité a augmenté de 108 % d’un trimestre à l’autre, car les agents qui écrivent du code plus vite créent aussi des vulnérabilités plus rapidement que quiconque ne peut les corriger.

Sécurité agentique : permissions, provenance et chaîne d’approvisionnement des agents — Steve Yegge, Gas Town

Une passe de renforcement de la sécurité effectuée par Fable sur un jeu qu’un ingénieur avait développé pendant 30 ans n’a révélé aucun problème : sécurité du cloud renforcée, identifiants pris en charge, tout semblait au beau fixe. Puis Snyk a analysé le même code et mis au jour 241 vulnérabilités que l’agent n’avait jamais pensé à rechercher. C’est au cœur de la conférence de Steve Yegge, dont le véritable titre, dit-il, n’est pas « sécurité agentique », mais « ayez peur ». Un architecte en chef de la sécurité d’une grande banque lui avait déjà présenté les chiffres : si tout le monde livre du code 10 fois plus vite et que le taux de défauts de sécurité reste stable, la surface vulnérable augmente elle aussi de 10 fois. Or, avec des modèles qui écrivent le code, ce taux ne reste pas stable : il empire.

Il est 22 h. Savez-vous où sont vos agents ? — Kim Maida, Keycard

Un agent chargé des incidents, de permanence de nuit, lit un ticket : la base de données de facturation est en panne et les paiements échouent. La procédure documentée indique de supprimer la base de données et de la restaurer à partir d’une sauvegarde. L’agent supprime donc la base de données Postgres de production, ne parvient pas à confirmer qu’une sauvegarde a été effectuée et transmet le problème à l’équipe du matin. C’est déjà arrivé à de vraies entreprises. Cela peut se produire parce que l’agent dispose d’une seule clé API à longue durée de vie qui lui donne tous les accès : un identifiant fourre-tout qu’il utilise sans restriction, que vous le surveilliez ou que vous dormiez.

Nous avons donné accès au code de production à un agent… puis essayé de dormir sur nos deux oreilles — Moritz Johner, Form3

Une seule PR de PatchPilot, qui mettait à jour quelques dépendances, a modifié 70 000 lignes de code. Et c’est quelque part dans ce diff que se cache tout le problème. L’équipe de Moritz Johner chez Form3 a conçu cet agent pour corriger les CVE dans des milliers de dépôts, afin de résorber un backlog qui ne se vide jamais, puis l’a mis en production. C’est alors que l’équipe de sécurité informatique a posé la question qui change toute la perspective du projet : s’agit-il d’automatisation ou d’un incident de chaîne d’approvisionnement en devenir ? Dès qu’un agent de programmation dispose de l’accès au dépôt, aux journaux CI, aux identifiants et au socket Docker dont il a besoin pour être utile, il devient un acteur de la chaîne d’approvisionnement, que vous l’ayez prévu ou non.

Utiliser les LLM pour sécuriser le code source — Eugene Yan, Anthropic

Début 2025, Mozilla publiait environ 20 correctifs de sécurité par mois pour Firefox. En avril, ce chiffre est passé à 400, soit une hausse de 20 fois, et Mozilla a attribué environ deux tiers de ces correctifs à un modèle de pointe. C’est le changement qu’Eugene Yan est venu décrire : les modèles détectent et corrigent désormais des vulnérabilités bien réelles à grande échelle. Lors de son propre scan de plus de mille dépôts open source, Anthropic a détecté 6 200 failles de gravité élevée ou critique parmi 23 000 problèmes potentiels, en a signalé 1 600 aux responsables de leur maintenance et a vu une centaine de correctifs publiés en amont. Détecter les failles n’est donc plus la partie la plus difficile. Le principal obstacle est désormais de les vérifier, de les trier et de les corriger.

Votre stack LLM, c’est une base de données de 2008 avec un meilleur marketing — Lovina Dmello, NVIDIA

En 2023, des chercheurs ont découvert que des milliers de clusters Ray étaient accessibles sans protection sur l’Internet public, avec des tableaux de bord et des API de tâches ouverts à tous. L’authentification est désactivée par défaut et personne ne l’avait activée avant la mise en production. Les données exposées représentaient plus d’un milliard de dollars. Pas de faille zero-day, pas d’attaque ingénieuse contre un réseau neuronal : juste un paramètre que quelqu’un a oublié de modifier. En sécurité du machine learning en production, ce n’est pas une exception, c’est la règle.

La période Jurassic Park de l’IA — Aaron Stanley, dbt Labs

Il y a vingt ans, Aaron Stanley est arrivé sur les lieux d’une collecte urgente de preuves dans le cadre d’une enquête de la SEC et s’est rendu compte qu’il avait oublié le dongle qui activait sa solution logicielle d’investigation numérique. Plutôt que de retourner le chercher, il a contourné le problème et a vu les horodatages des preuves commencer à changer. Dans une affaire où il faut savoir qui savait quoi, et quand, c’est catastrophique ; il s’est fait réprimander, mais pas licencier. En février dernier, alors CISO et confronté au même obstacle dans le cadre d’une autre enquête fédérale, il a agi en toute sécurité, grâce à son expertise qui lui a permis de concevoir avec un agent une procédure défendable sur le plan médico-légal. Son idée : les agents que nous créons aujourd’hui sont la version plus jeune et naïve de lui-même, et ils trouveront un moyen d’accomplir leur mission.

Une intelligence qui préserve la confidentialité — Steve Korshakov, Bee (rachetée par Amazon)

Un objet connecté qui enregistre tout ce que vous dites capture environ 10 millions de tokens par an et, en une semaine, sait presque tout de vous. C’est Bee. Steve Korshakov le décrit comme l’un des dispositifs de captation les plus sensibles du marché. Toute son intervention repose donc sur une garantie : personne ne peut lire vos données, pas même Amazon, l’entreprise qui a racheté Bee huit mois plus tôt. Intégrer Amazon a rendu la tâche plus difficile, et non plus facile : un client AWS classique fait confiance à Amazon pour accéder à ses données, et Bee devait désormais se protéger aussi contre cette éventualité.