PolySécure Podcast volet Teknik

Nicolas-Loïc Fortin et tous les collaborateurs

Podcast francophone sur la cybersécurité. Pour professionels.

  1. 19 août

    Teknik - Le CI/CD pour piéger les développeurs

    Parce que… c’est l’épisode 0x330! Shameless plug 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Dans cet épisode technique de Polysécure, l’animateur reçoit Jordan Theodore (Glimps) pour discuter d’un sujet devenu central depuis 2025 : la sécurité des chaînes CI/CD et, plus largement, la compromission de la chaîne d’approvisionnement logicielle (supply chain). Jordan explique que Glimps a été fortement sollicité récemment, notamment pour ses capacités d’analyse de fichiers permettant de détecter des packages malveillants dans les écosystèmes npm et PyPI. Un nouveau type de menace Le point de départ de la discussion est simple : plusieurs grands groupes ont subi des incidents où l’ensemble de leur chaîne CI/CD s’est retrouvé compromis à cause d’un package ajouté par défaut. Ce type d’attaque est particulièrement pernicieux car il passe inaperçu : les développeurs important une dépendance importent aussi, sans le savoir, une multitude de sous-paquets qu’ils ne maîtrisent pas. Jordan cite l’exemple du ver Shai-Hulud, apparu en 2025, capable de s’autopropager dans l’écosystème npm sans intervention humaine. Chaque machine infectée devient un nouvel agent de propagation : vol de tokens (Git, AWS), puis publication automatique de nouvelles versions vérolées de packages. Le constat qui ressort de l’échange est un changement de cible : les attaquants ne visent plus prioritairement les utilisateurs finaux, mais les développeurs, dont les postes offrent des accès à privilèges élevés, un accès réseau étendu et un tremplin direct vers le cœur des entreprises — les pipelines de supply chain. Comment Glimps s’est adapté Glimps, dont la spécialité historique est la détection de malwares dans des fichiers binaires, a dû développer un tout nouveau moteur de détection multi-scripts (JavaScript, Python, PowerShell) capable d’identifier des intentions malveillantes directement dans du code plutôt que dans des exécutables. Le principal défi a été la disponibilité de données d’entraînement : bien que l’entreprise dispose d’une base de plus de 300 millions de fichiers, les cas d’attaques spécifiques à npm restaient rares, ce qui a nécessité un important travail de tri manuel par les équipes CTI, produit et R&D pour distinguer patterns malveillants et usages légitimes. Jordan illustre la sophistication de ces attaques avec un exemple concret : un script de pré-installation npm qui recherche des clés et variables d’environnement dans les conteneurs Docker, scanne le réseau, puis établit une connexion via socat ou netcat vers un serveur distant — le tout sans être détecté par les antivirus traditionnels ni par les scanners de vulnérabilité, puisque le code est structuré de façon à paraître légitime. Certains scripts allaient jusqu’à télécharger le runtime Bun pour exécuter leur charge malveillante, profitant de sa popularité croissante. Le « living off the land » généralisé Un fil conducteur de l’épisode est l’usage massif de techniques de living off the land : les attaquants n’utilisent que des briques légitimes (runtimes reconnus, outils CI/CD authentiques, runners GitHub, outils comme TruffleHog) assemblées de façon malveillante. Cette approche rend la détection particulièrement difficile puisque chaque composant, pris isolément, est parfaitement normal. L’échange élargit ensuite le sujet au-delà de npm : les fichiers Blender (.blend) peuvent contenir du Python exécuté automatiquement à l’ouverture, ce qui permet à un attaquant de piéger un simple asset 3D (une chaise, par exemple) pour compromettre le poste d’un designer ou d’un architecte. Même les modèles d’intelligence artificielle en open weight, via le format pickle, peuvent embarquer du code malveillant. Jordan évoque aussi le risque accru lié aux agents IA (type Claude Code) qui exécutent des installations de packages de façon autonome, sans supervision humaine directe — un vecteur de compromission supplémentaire et plus difficile à surveiller. Des cas emblématiques et le problème des faux négatifs L’épisode revient sur plusieurs cas réels : le DLL side-loading via un dossier légitime d’Adobe, exploité par le groupe Lotus Blossom, ou encore la compromission de la chaîne de mise à jour officielle de Notepad++ fin 2025 — un outil massivement utilisé par les administrateurs système à privilèges élevés. Ces cas illustrent un problème récurrent : des analystes fatigués ou habitués à voir certains comportements « normaux » (même détectés par un EDR) laissent passer des alertes parce que le contexte semble légitime. Les extensions VS Code et Chrome sont également citées comme vecteurs de compromission, élargissant encore la surface d’attaque. L’intégration de Glimps dans les pipelines Concrètement, Glimps s’intègre à divers points de contrôle : messagerie, navigateur, dossiers partagés (SharePoint, Drive) et surtout dans les chaînes CI/CD via des outils comme GitLab, où il agit comme un test bloquant avant la livraison finale d’un package. L’objectif est de préserver la fluidité de travail des développeurs — qui ont tendance à accepter les dépendances sans trop les questionner — tout en ajoutant un filet de sécurité invisible qui ne ralentit pas les builds. Les leçons à retenir Jordan conclut sur plusieurs enseignements pour les RSSI : npm n’est que la partie émergée de l’iceberg de la supply chain ; tout fichier capable d’exécuter du code externe (3D, documents, extensions, modèles IA) constitue un vecteur potentiel ; et le principe de zero trust doit être appliqué plus largement. L’épisode fait un parallèle avec l’époque des macros dans les documents Office, aujourd’hui bien connues des utilisateurs, pour souligner que ce type de vigilance doit désormais s’étendre à des formats de fichiers longtemps considérés comme inoffensifs. Glimps affirme continuer à faire évoluer ses moteurs de détection en fonction des retours terrain de ses clients et des nouvelles menaces observées. Collaborateurs Nicolas-Loïc Fortin Jordan Theodore Crédits Montage par Intrasecure inc Locaux virtuels par Riverside.fm

  2. 13 août

    Teknik - Breaking the Backbone of Global ISP Networks (Troopers)

    Parce que… c’est l’épisode 0x32D! Shameless plug 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Dans cet épisode de Polysécure, l’animateur reçoit Mathieu Farrell, chercheur en sécurité chez Quarkslab au sein de l’équipe Adversary Simulation. L’échange revient sur une présentation donnée par Mathieu à la conférence Troopers, en Allemagne, intitulée Breaking the Backbone of Global ISP Networks, qui a aussi été présentée à Zer0Con en Corée et à DEFCAMP à Singapour. Le contexte : OLT et ONT Le sujet central porte sur les équipements réseau fibre optique appelés OLT (Optical Line Terminal). Ces routeurs relient le réseau des fournisseurs internet (FAI) au équipement des clients, appelé ONT (Optical Network Terminal) — la « box » que l’on retrouve chez les particuliers. Les OLT se connectent aux ONT par fibre, généralement au bas des immeubles ou dans la rue, et sont ensuite rattachés au réseau de l’opérateur ainsi qu’à un « cloud manager », l’application centrale qui gère l’ensemble du parc d’équipements. Un constat frappant émerge d’entrée de jeu : ces OLT sont parfois directement accessibles, autant physiquement que sur internet. Mathieu mentionne qu’en Nouvelle-Zélande, par exemple, les OLT sont installés dans des boîtiers en plastique accessibles dans la rue, pensés pour faciliter les interventions techniques — mais tout autant exploitables par un attaquant. Une réalité que l’animateur note aussi présente potentiellement au Canada. Premier axe : l’accès physique Le premier scénario d’attaque décrit consiste à se brancher physiquement au port série de l’équipement. Une fois connecté, on tombe sur un shell restreint. Grâce au reverse engineering du firmware — récupéré en ligne — Mathieu et son équipe ont identifié une commande vulnérable à une injection de commande, exploitable de façon triviale. Cela permet d’obtenir un accès root sur l’OLT, dont le système sous-jacent tourne sous Linux. Une fois root, l’attaquant peut extraire la configuration de l’appareil, notamment le routage IP et l’adresse du cloud manager auquel il est rattaché. Il devient alors possible de pivoter : en posant un implant, l’attaquant peut faire du SOCKS et atteindre directement le cloud manager depuis ce point d’entrée. Le cloud manager : la clé du réseau Le cloud manager est une application web classique, déployée sous Java Tomcat et conteneurisée avec Docker — non pas pour des raisons de sécurité, mais simplement pour faciliter le déploiement. Or, la configuration Docker montre un défaut critique : le socket Docker de l’hôte est monté dans le conteneur. Une fois ce dernier compromis, il devient possible d’interagir avec ce socket pour s’évader du conteneur et exécuter du code directement sur la machine hôte, en plein cœur du réseau de l’opérateur. Mathieu observe que les FAI semblent considérer cette zone du réseau comme suffisamment protégée pour ne pas nécessiter une surveillance accrue — une hypothèse que cette chaîne d’attaque complète vient clairement invalider. Il souligne aussi que la barrière à l’entrée pour ce type d’attaque n’est pas technique, mais économique : il suffit de pouvoir se procurer un OLT pour effectuer le reverse engineering et reproduire les bugs. Deuxième axe : l’exposition sur internet Le second axe d’attaque touche les OLT directement exposés sur internet. En utilisant des moteurs de recherche spécialisés comme Shodan, Censys et FOFA, l’équipe a pu récupérer des fragments de la page de connexion web propre à chaque OLT, puis chercher ces empreintes en ligne pour dresser une liste de cibles. Plusieurs failles ont été identifiées : Des identifiants par défaut, partagés entre plusieurs modèles et versions de firmware, encore utilisés sur certains équipements exposés publiquement — une situation d’autant plus préoccupante dans un contexte géopolitique où des infrastructures critiques restent ainsi exposées. Une vulnérabilité dans le binaire d’authentification web (écrit en C), qui concatène les identifiants reçus par requête POST dans une chaîne de caractères passée à une fonction système sans validation, permettant l’exécution de commandes arbitraires. Une route API exposant une fonction de type traceroute qui accepte une adresse IP en paramètre sans validation, permettant là aussi une injection de commande triviale. Mathieu insiste sur le fait que l’équipe a volontairement misé sur des techniques d’exploitation « triviales » plutôt que sur des vulnérabilités de corruption mémoire plus sophistiquées (use-after-free, buffer overflow) également découvertes durant l’audit. L’objectif : obtenir une chaîne d’exploitation fiable, stable et prévisible, plutôt qu’un exploit spectaculaire mais risqué de faire planter l’équipement. Divulgation responsable difficile Malgré plusieurs semaines — voire près d’un mois — de tentatives pour contacter l’éditeur du firmware, aucune réponse n’a été obtenue. Face à la sensibilité des cibles concernées, l’équipe a dû passer par les CERT nationaux (CERT-FR, CERT-US, entre autres) pour informer les opérateurs touchés. Un an plus tard, l’autorisation de publication a finalement été donnée, sans jamais avoir de retour direct du fabricant. Pistes pour la suite En conclusion, Mathieu suggère une piste de recherche future : s’intéresser au protocole OMCI, qui régit la communication entre les OLT et les ONT chez les particuliers — un axe qui pourrait révéler d’autres vulnérabilités et amplifier encore l’impact de cette chaîne d’attaque. L’échange se termine sur un constat partagé : ces classes de vulnérabilités, dignes des années 1990-2000, persistent encore aujourd’hui dans des équipements critiques que l’on présume à tort bien sécurisés — un rappel de l’importance de ce type de recherche pour sensibiliser l’industrie. Notes Breaking the Backbone of Global ISP Networks Collaborateurs Nicolas-Loïc Fortin Mathieu Farrell Crédits Montage par Intrasecure inc Locaux virtuels par Riverside.fm

  3. 12 août

    Teknik - Pas besoin d'être un Mythos pour faire de l'offensif (leHACK)

    Parce que… c’est l’épisode 0x32C! Shameless plug 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Présentation Cet épisode de Polysécure, enregistré avec Patrick Ventuzelo, CEO et fondateur de Fuzing Labs (une entreprise d’une vingtaine de personnes basée au sud de Paris, spécialisée en sécurité offensive), revient sur la keynote qu’il a donnée au leHACK. Le titre volontairement provocateur jouait sur le nom du modèle « Mythos », sorti puis suspendu quelques jours à peine après son lancement en raison de restrictions gouvernementales américaines liées à l’export. Cet épisode a servi de tremplin à toute la conférence : elle démontrait qu’un gouvernement peut décider unilatéralement de l’accès à un outil, ce qui pose de sérieuses questions de souveraineté numérique. Le message central : la spécialisation plutôt que la puissance brute L’idée forte de Patrick est qu’il n’est pas nécessaire de disposer du modèle le plus puissant du marché pour faire de la recherche de vulnérabilités efficace. Un petit modèle bien guidé, doté des bons outils, d’une base de connaissances pertinente et d’un processus clair, peut égaler voire dépasser un modèle frontière massif — tout en étant plus reproductible et moins coûteux en tokens. Il compare cela au fuzzing traditionnel : on peut soit lancer un outil générique en mode automatique, soit investir du temps pour comprendre la cible, créer un corpus adapté et guider la recherche. Les agents IA suivent la même logique de compromis entre autonomie complète et investissement humain en amont. L’architecture de Fuzing Labs Depuis un an, l’entreprise développe une plateforme d’orchestration d’agents IA spécialisés pour la sécurité offensive. Elle distingue plusieurs niveaux de sophistication : des agents basiques construits sur des harnais existants avec accès à des skills, des MCP et des bases de connaissances ; des agents plus poussés codés directement avec des frameworks comme l’ADK de Google, LangChain ou d’autres ; et enfin, un niveau expérimental consistant à fine-tuner leurs propres modèles. Cette dernière piste nécessite un système de benchmarking rigoureux — un domaine où l’industrie de la sécurité offensive manque cruellement d’outils standardisés, contrairement à d’autres secteurs. Un orchestrateur central, doté d’un grand modèle avec beaucoup de contexte, planifie le travail et distribue des tickets à des sous-agents spécialisés (par exemple pour l’analyse Android, la rédaction de rapports, etc.), qui eux n’ont pas besoin de modèles massifs. Un petit modèle dense suffit largement pour des tâches ciblées comme la génération de rapports. Les choix de modèles open weight Patrick détaille les modèles qu’ils testent régulièrement : Qwen 3.6 et GLM 4 pour les petits modèles (utilisables même sur Mac Mini ou laptops), Nemotron Ultra en modèle intermédiaire (souvent disponible gratuitement via OpenRouter ou Nvidia), et des modèles plus lourds comme GLM 5.2 ou Kimi 3 pour les tâches complexes. Il observe que les modèles denses donnent de meilleurs résultats que les architectures en mixture of experts (MoE) dans leur contexte, notamment parce qu’ils offrent une meilleure traçabilité — un critère absolument central pour Fuzing Labs. Confidentialité et souveraineté La question de la confidentialité des données clients occupe une place importante dans la discussion. Fuzing Labs privilégie un déploiement on-premise voire air-gap, ce qui implique de faire tourner les modèles en local chez le client. L’entreprise possède du matériel dédié (DGX Spark, Mac Studio M3 Ultra avec 512 Go de RAM) et attend avec impatience la sortie de la DGX Station de Nvidia, qui promet des capacités mémoire et de calcul considérablement supérieures dans un format proche d’un PC gaming. Selon la taille du client, la solution varie entre infrastructure locale complète, clusters de DGX Spark, ou accès API à des fournisseurs comme Mistral ou OVH. Traçabilité et sécurité des agents Patrick insiste longuement sur l’importance de la traçabilité, en écho direct à un incident récent chez OpenAI où un agent s’est échappé de son environnement d’entraînement sans que personne ne s’en aperçoive pendant une semaine. Chez Fuzing Labs, chaque agent doit documenter ses décisions, ses communications et les outils utilisés. Contrairement à des acteurs comme Xbow qui font du pentesting IA sur des systèmes en production, Fuzing Labs refuse cette approche : leurs agents travaillent exclusivement sur des cibles binaires, émulées en VM, sandboxées et à communications limitées. Standardisation et méthode de travail L’adoption de standards émergents — skills, protocole MCP, protocole agent-à-agent — a permis à l’entreprise de réécrire une bonne partie de sa plateforme initiale, jugeant préférable d’abandonner du travail déjà fait plutôt que d’accumuler de la dette technique. Sur le vibe coding, Patrick souligne la nécessité accrue de processus rigoureux (CI/CD, documentation, garde-fous), car les agents peuvent facilement dériver sans cadrage clair. Conclusion : la recherche plutôt que l’exécution Il conclut sur l’idée que les agents ne remplacent pas les chercheurs, mais libèrent du temps consacré aux tâches à faible valeur ajoutée pour se concentrer sur la recherche véritable. Il illustre cela par sa propre découverte de vulnérabilités sur la stack GNSS RTK utilisée par les drones, un sujet qu’il a approfondi après avoir demandé à Claude de vérifier l’originalité de la piste — travail qui donnera lieu à une présentation à Black Hat Europe 2026. Pour lui, cette ère offre une liberté créative inédite : la barrière à l’entrée pour explorer de nouvelles idées de recherche n’a jamais été aussi basse. Notes Keynote : Pas besoin d’être un mythos pour faire de l’offensif Collaborateurs Nicolas-Loïc Fortin Patrick Ventuzelo Crédits Montage par Intrasecure inc Locaux virtuels par Riverside.fm

  4. 29 juil.

    Teknik - N8ive by design - one leaked key, three attack chains (leHACK)

    Parce que… c’est l’épisode 0x324! Shameless plug 6 au 9 août 2026 - Las Vegas, USA - - DEFCON 34 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Comment est né ce projet de recherche Guillaume explique que l’intérêt pour n8n n’est pas né d’un coup de chance isolé, mais de la convergence de plusieurs facteurs. Chez GitGuardian, des collègues de la sécurité interne ont commencé à déployer n8n en interne, un outil rapidement adopté par des équipes non techniques (marketing, finance) qui automatisent leurs tâches sans forcément avoir de culture sécurité. Parallèlement, il a observé une explosion du nombre de CVE touchant n8n fin 2025, avec certaines vulnérabilités entrant dans le catalogue KEV de la CISA, preuve d’une exploitation active. En creusant les CVE, il a remarqué des motifs récurrents, notamment autour de composants liés à SSH, suggérant que la sécurité de l’outil est traitée au coup par coup plutôt que de façon structurelle. Comme n8n interconnecte de nombreux services (Google Workspace, Notion, HubSpot, etc.), c’est aussi un concentrateur de secrets particulièrement intéressant à étudier. Guillaume insiste sur le fait que cette recherche s’appuie surtout sur du travail de fond et sur des années d’échanges avec la communauté, plus que sur l’intuition pure ; la vraie part de chance résidant plutôt dans le bon timing de publication. Il souligne aussi la chance d’évoluer dans une entreprise à taille encore humaine, ce qui permet un dialogue hebdomadaire direct entre l’équipe recherche et l’équipe sécurité interne, dont les retours terrain (par exemple sur le stockage des secrets ou la nécessité d’un coffre-fort/Vault) ont directement nourri les travaux présentés à leHACK. Trois phases de recherche Phase 1 – Détection et validation des secrets n8n. En s’appuyant sur les données publiques issues de leurs outils d’analyse de GitHub et de Docker Hub, l’équipe a cherché à identifier la structure d’un jeton d’authentification n8n (un token JWT) afin de détecter des marqueurs spécifiques et de valider sa validité réelle. Cette démarche a permis de repérer environ 300 cibles valides sur la période d’avril 2025 à mars 2026, suivies d’un processus de divulgation responsable auprès des hébergeurs et sociétés concernées. Un bug bounty de 1200 € a même été obtenu, un cas jugé exceptionnel tant les retours sont habituellement inexistants ou négatifs. Cette recherche est en cours d’intégration au produit GitGuardian, avec un système de détection et de validation des clés n8n attendu vers septembre-octobre. Phase 2 – Perspective attaquant sur une instance à jour. L’équipe s’est demandé ce qu’un attaquant pouvait faire avec un token n8n compromis. Résultat : il est possible d’énumérer des utilisateurs, d’exfiltrer des « data tables » (une forme de base de données interne proche de SQL), et même de faire fuiter des secrets typés (Notion, OpenAI…) censés être protégés, via une forme de confusion interne au système. Certains signalements faits à l’équipe n8n sont restés sans réponse ou ont été jugés mineurs. Phase 3 – Exploitation d’une instance non à jour. Sur une version vulnérable, l’équipe a démontré la possibilité de faire fuiter à la fois la base de données SQLite et la clé de chiffrement utilisée pour protéger les secrets stockés. Guillaume précise la distinction entre deux types de secrets : la « n8n key » (jeton JWT d’authentification à l’API) et l’« encryption key » (clé servant à chiffrer les identifiants de services tiers stockés dans n8n). Pour retrouver les propriétaires des instances identifiées, l’équipe a utilisé des techniques classiques basées sur le nom de domaine, ainsi qu’un endpoint d’API permettant d’énumérer certaines informations non personnelles (comme des domaines d’adresses e-mail), suffisantes pour identifier les entreprises concernées. Une plateforme puissante mais fragile Une partie importante de la discussion porte sur le risque structurel de n8n : conçu pour permettre à des utilisateurs non techniques (marketing notamment) de construire des automatisations, via des webhooks par exemple pour des inscriptions à une newsletter, l’outil ne propose aucune brique native de validation ou de nettoyage des données d’entrée. Rien n’empêche qu’un champ censé recevoir une adresse e-mail serve de vecteur d’injection SQL. Les deux intervenants s’accordent sur le fait que n8n devrait être cloisonné, jamais exposé directement sur internet, et idéalement protégé par une authentification forte, un peu à l’image du problème plus général du « vibe coding » qui met des outils puissants entre les mains de personnes sans formation aux enjeux de sécurité logicielle. L’apport des LLM dans la recherche de vulnérabilités Enfin, Guillaume revient sur sa propre découverte des LLM comme outil de recherche en sécurité, n’étant pas lui-même expert de Node.js. Il décrit un usage très concret : demander à Claude d’analyser des CVE existantes pour repérer des variantes potentielles, générer des preuves de concept sur des versions vulnérables connues, ou encore rédiger rapidement des supports de présentation à partir d’idées survenues en dehors du contexte de travail (par exemple pendant une course à pied). Il insiste toutefois sur l’importance de toujours vérifier manuellement les résultats produits par le modèle avant de les diffuser. Il conclut en recommandant n8n comme un excellent terrain d’entraînement pour quiconque souhaite explorer la recherche de vulnérabilités assistée par IA. Notes N8ive by design - one leaked key, three attack chains Collaborateurs Nicolas-Loïc Fortin Guillaume Valadon Crédits Montage par Intrasecure inc Locaux réels par Intrasecure inc

  5. 16 juil.

    Teknik - De Nessus à Bromure (SSTIC)

    Parce que… c’est l’épisode 0x31D! Shameless plug 6 au 9 août 2026 - Las Vegas, USA - - DEFCON 34 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description De Nessus à Tenable : les débuts d’une légende Dans cet épisode spécial de Polysécure, l’animateur reçoit Renaud Deraison, créateur de Nessus, le scanner de vulnérabilités développé il y a près de 30 ans, et cofondateur de Tenable où il a occupé le poste de CTO jusqu’à son départ il y a environ cinq ans. Deraison raconte la genèse de Nessus : à 16 ans, passionné par le réseau internet naissant, il découvre l’univers de la sécurité informatique à une époque où les failles étaient publiées sur la mailing list Bugtraq, suivie par une communauté restreinte d’environ 20 000 abonnés. Insatisfait des outils existants comme Satan, jugés trop complexes et peu accessibles, il développe Nessus en 1998 avec une cinquantaine de tests de sécurité au départ. Le succès est immédiat et inattendu, poussant Deraison à poursuivre le projet, d’abord en open source, puis en produit commercial via Tenable, qui étendra la portée de l’outil de la simple DMZ à l’ensemble de l’infrastructure numérique des entreprises. Le retour à la technique et la leçon de l’éloignement du clavier Un thème central de la discussion est l’importance de rester connecté à la pratique technique concrète. Deraison explique qu’en grandissant chez Tenable, il a dû délaisser le code pour devenir « plus stratégique », perdant ainsi une compréhension viscérale de la technologie au profit d’une compréhension purement intellectuelle. Il souligne l’écart immense, en cybersécurité, entre comprendre un concept en théorie et l’expérimenter réellement : c’est en manipulant les outils qu’on découvre les vrais problèmes de sécurité et les idées de produits pertinentes. Cette réflexion mène à une critique plus large de l’industrie de la cybersécurité, jugée parfois arrogante et déconnectée du vécu des utilisateurs, prompte à distribuer des leçons sans empathie pour les contraintes opérationnelles réelles (comme l’impossibilité de patcher immédiatement une machine critique sans interrompre un service). Bromure : le navigateur jetable réinventé Après son départ de Tenable, Deraison reprend goût au code, épaulé par les assistants IA, en commençant par ChatGPT puis Claude. L’élément déclencheur d’un nouveau projet est presque anecdotique : recevant de nombreux SMS frauduleux (offres de crédit douteuses, généré désormais dans un français impeccable et localisé grâce à l’IA), il souhaite savoir qui se cache derrière ces arnaques sans s’exposer lui-même. Il se remémore alors Bromium, une entreprise des années 2010 qui isolait Internet Explorer dans un hyperviseur, avec l’idée qu’il était inutile de patcher puisqu’il suffisait de fermer et rouvrir un environnement neuf en cas de compromission. Inspiré par ce concept, Deraison développe Bromur (bromur.io), un navigateur jetable pour Mac fonctionnant sous Linux dans une VM, avec une expérience utilisateur quasi native : glisser-déposer de fichiers entre le Mac et la VM, support webcam, contrôle fin des téléchargements et téléversements. Une version serveur permet aussi de faire travailler des contractants externes dans un environnement streamé et surveillé, où impression, captures d’écran et téléchargements peuvent être bloqués. Le projet intègre également un module (désactivé par défaut) utilisant un LLM pour analyser les pages visitées et détecter le phishing, en repérant par exemple des incohérences entre le contenu affiché et l’URL réelle, ou des tromperies visuelles comme l’usage de caractères d’un autre alphabet imitant des lettres latines. Deraison estime que le phishing reste un vaste chantier négligé par l’industrie, qui se contente trop souvent de solutions de formation jugées insuffisantes face à des attaques de plus en plus sophistiquées, y compris par deepfake vidéo. Bromure Agentic : sécuriser les développeurs sans les freiner Le second volet du projet, Bromure Agentic, s’attaque aux attaques de la chaîne d’approvisionnement logicielle (supply chain attacks), un risque majeur lorsqu’un package npm ou Python compromis vole les clés SSH, tokens d’authentification et autres identifiants sensibles présents sur la machine d’un développeur. Plutôt que d’imposer des restrictions punitives comme le font certaines sandboxes existantes, Bromure propose une VM Linux complète où l’utilisateur dispose de faux tokens et fausses clés SSH. Un mécanisme de type « man in the middle » observe le trafic sortant et substitue à la volée les vrais identifiants aux faux, uniquement au moment nécessaire. Ainsi, même en cas de compromission, aucun secret n’est réellement exposé sur la machine. L’outil ajoute aussi des alertes en cas de mauvaise configuration et permet désormais de restreindre les droits (par exemple en lecture seule) sur les accès Kubernetes ou Git, sans exiger du développeur qu’il devienne expert en administration système. Repenser des dogmes établis La conversation aborde aussi la remise en question de certains dogmes de sécurité, comme le caractère « intouchable » du trafic SSL, que Deraison juge paradoxal : on surveille tout le comportement d’une machine, sauf le trafic chiffré sortant. L’inspection de ce trafic ouvre selon lui de nouvelles possibilités, comme bloquer les téléchargements de packages npm en version « latest », souvent les plus vulnérables au piratage. Les deux interlocuteurs concluent sur une analogie automobile : de même que les usagers n’ont pas à comprendre le fonctionnement d’un moteur pour conduire, les utilisateurs et développeurs ne devraient pas avoir à devenir des experts en sécurité pour travailler efficacement. La responsabilité doit se déplacer vers des outils qui protègent sans punir, permettant à chacun de rester concentré sur son métier. Notes Bromure Collaborateurs Nicolas-Loïc Fortin Renaud Deraison Crédits Montage par Intrasecure inc Locaux réels par SSTIC

  6. 15 juil.

    Teknik - La curiosité source de toutes les croissances en cybersécurité

    Parce que… c’est l’épisode 0x31C! Shameless plug 6 au 9 août 2026 - Las Vegas, USA - - DEFCON 34 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Une conversation sur une terrasse, un sujet qui mijotait depuis longtemps L’épisode s’ouvre de façon informelle, en terrasse, un lundi ensoleillé. L’animateur et Martin Dubé annoncent qu’ils allaient enfin aborder un sujet qu’ils repoussaient depuis longtemps : un mandat de test d’intrusion que Martin avait réalisé sur un réseau LTE (4G) privé, à une époque où il n’avait qu’une connaissance limitée de cette technologie. Le fil conducteur de la discussion est la curiosité comme moteur de croissance professionnelle en cybersécurité, illustré par ce mandat devenu un succès marquant dans sa carrière. Se lancer dans l’inconnu : du pentest classique au LTE Martin explique que son parcours en test d’intrusion a toujours été motivé par la curiosité plutôt que par une expertise préalable. Il rappelle ses débuts chez Gocker, où une jeune équipe sans expérience formelle a appris « sur le tas ». Cette philosophie l’a suivi tout au long de sa carrière : il se dit attiré par les mandats qui le poussent hors de sa zone de confort. Le LTE constitue un univers à part, très différent du monde informatique traditionnel (Windows, Linux) : des protocoles propriétaires, complexes, empilés au fil des générations (3G, 4G, 5G) par l’organisme 3GPP, chaque itération apportant son lot de nouveaux acronymes déconnectés des précédents. Le mandat portait spécifiquement sur un réseau LTE privé, avec ses propres mécanismes de contrôle d’accès (notamment le verrouillage IMEI, qui lie une carte SIM à un appareil précis), absents des réseaux cellulaires publics. Une préparation intensive Pour se qualifier, Martin s’est procuré une carte Blade RF, a étudié le fonctionnement du matériel, préparé des payloads jusque dans sa chambre d’hôtel et dans l’avion, et a visionné une quinzaine de présentations DEF CON sur les attaques LTE. Il en retient que malgré la complexité apparente, les mêmes patterns d’attaque reviennent constamment : injections, services exposés, adresses IP mal protégées. Il livre un message clé aux auditeurs : ne pas laisser le syndrome de l’imposteur freiner les décisions. Selon lui, un « expert » est simplement quelqu’un qui a travaillé fort et qui continue d’apprendre ; s’accrocher au statut d’expert peut au contraire limiter la capacité à sortir de sa zone de confort. Martin insiste sur l’accumulation d’expérience comme capital réutilisable : après une quinzaine d’années en test offensif, il reconnaît que les fondamentaux (penser comme un attaquant) restent transférables d’une technologie à l’autre, seuls les acronymes changent. Il souligne aussi que l’accès à l’information (recherche en ligne, outils d’IA comme Copilot) a rendu l’apprentissage de nouveaux domaines beaucoup plus rapide qu’auparavant. Concrètement, pour écrire ses payloads en C, il a utilisé le framework open source srsRAN, qui permet de simuler un réseau LTE complet, et s’est appuyé sur Copilot pour comprendre le code et cibler les modifications nécessaires. Une soirée d’hôtel a suffi pour obtenir un premier résultat fonctionnel. Le pouvoir du threat modeling La deuxième moitié de l’échange se concentre sur la méthodologie du mandat. Le client, relativement mature, exigeait un atelier de modélisation des menaces (threat modeling) avant même la rédaction du plan de test, lequel devait ensuite être approuvé par les parties prenantes. L’équipe a suivi une approche inspirée de l’OWASP, réunissant plusieurs intervenants pour déterminer ce qu’il fallait sécuriser en priorité. Le sujet retenu a été le provisionnement des cartes SIM, élément central de l’accès au réseau LTE (les clés de chiffrement intégrées aux cartes, non extractibles, et leur copie détenue par le fournisseur). Cet atelier d’une semaine a permis de faire émerger, avant même les tests techniques, plusieurs hypothèses de vulnérabilités fondées sur les risques réels plutôt que sur un périmètre imposé arbitrairement. Martin partage un exemple marquant : lors des discussions, un accès jugé initialement comme « lecture seule » sur un système de surveillance des cartes SIM s’est révélé être un accès administrateur complet, supposément atténué par des règles de pare-feu… qui, après vérification, n’avaient en réalité jamais été mises en place. Ce test, qui n’a demandé que cinq minutes, a révélé un manque de communication majeur entre les équipes du client et son fournisseur. Les deux interlocuteurs comparent cette dynamique aux défaillances observées dans les grandes organisations complexes, où plusieurs fournisseurs interviennent sans coordination claire. L’animateur cite en parallèle l’incident de la porte de l’avion Boeing, causé par une rupture de communication entre le fournisseur et le fabricant plutôt que par une seule erreur isolée — illustrant que les systèmes complexes multiplient les angles morts. Les résultats techniques du mandat Une fois le plan de test bâti sur les risques identifiés, Martin a pu tester des contrôles précis : usurpation d’IMEI, mouvements latéraux via des réseaux industriels mal segmentés (FTP non sécurisés, plusieurs sauts de jump host), et surtout des attaques par déni de service. Il détaille l’attaque par injection sur la « tracking area update » : contrairement au Wi-Fi, où l’appareil mesure lui-même la force du signal, un appareil LTE fait confiance à la force annoncée par l’antenne, ce qui permet à un attaquant de se faire passer pour une tour plus puissante sans nécessiter une grande puissance d’émission. Cette faille est reconnue comme un compromis de conception du 3GPP entre sécurité et fiabilité du roaming. Dans le cas testé, la vulnérabilité existait bel et bien, mais un mécanisme de type « watchdog » redémarrait automatiquement les appareils affectés, limitant l’impact réel grâce à un contrôle compensatoire. Conclusion L’épisode se termine sur une note d’enthousiasme partagé : les deux interlocuteurs concluent que la curiosité, la volonté d’expérimenter dans l’inconnu et la capacité à capitaliser sur une expérience accumulée sont les véritables leviers de progression en cybersécurité, bien plus que la spécialisation figée dans un domaine unique. Collaborateurs Nicolas-Loïc Fortin Martin Dubé Crédits Montage par Intrasecure inc Locaux réels par Intrasecure inc

  7. 14 juil.

    Teknik - Posture de l'IA défensif ou comment nous apprenons de l'IA offensif

    Parce que… c’est l’épisode 0x31B! Shameless plug 6 au 9 août 2026 - Las Vegas, USA - - DEFCON 34 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Un an de progrès vertigineux Dans cet épisode spécial de Polysécure, l’animateur reçoit Mickael Nadeau pour discuter de l’évolution de l’intelligence artificielle entre deux éditions du concours NorthSec (NSec). Le point de départ est frappant : il y a environ un an et demi, lors de l’avant-dernier NorthSec, les participants commençaient tout juste à expérimenter l’IA en mode « full force », mais les capacités restaient limitées à un simple chatbot capable, au mieux, de générer un script rapide pour automatiser une tâche SSH. Aujourd’hui, le paysage est méconnaissable : les agents autonomes, les architectures de type RAG et les compétences (« skills ») spécialisées ont complètement transformé la façon dont les équipes offensives opèrent. Le point de vue privilégié d’une entreprise défensive Mickael explique que son entreprise, active en cyberdéfense, occupe une position d’observation unique. Grâce à un « mode surveillance » qui laisse les systèmes clients actifs sans bloquer les attaques (plutôt que de les stopper), l’équipe peut observer en temps réel les nouveaux outils et méthodologies utilisés par les équipes de pentest lors de leurs tests d’intrusion. Cette visibilité lui permet presque de dresser un classement informel des équipes selon leur niveau, un peu à la manière d’un « wall of shame » inspiré de DEF CON : certaines équipes s’appuient sur leur réputation sans se renouveler, utilisant des outils et méthodologies dépassés, tandis que d’autres repoussent les limites grâce à une utilisation avancée de l’IA. Du couteau suisse au tireur d’élite spécialisé Un des axes centraux de la discussion porte sur le passage d’agents génériques (le « couteau suisse ») à des sous-agents hautement spécialisés. Mickael illustre ce changement avec l’exemple des injections SQL : au lieu d’utiliser un outil bruyant comme SQLMap qui teste systématiquement toutes les possibilités, on peut désormais entraîner un agent dédié, nourri de toute la documentation existante sur les failles SQL connues, capable de reconnaître un scénario familier et d’aller directement à la solution avec un minimum de requêtes. Le résultat est un attaquant beaucoup plus silencieux, difficile à repérer avec les mécanismes de détection traditionnels basés sur le volume de bruit réseau. Ce changement de paradigme complique considérablement le travail défensif. Les équipes de sécurité, historiquement habituées à trier les faux positifs et à repérer les comportements bruyants et erratiques, doivent maintenant chasser des signaux beaucoup plus subtils, dans une fenêtre de temps réduite à quelques secondes plutôt qu’à plusieurs jours. L’apprentissage machine au service de la défense Contrairement à l’approche probabiliste des grands modèles de langage utilisés côté offensif, l’entreprise de Mickael s’appuie depuis longtemps sur l’apprentissage machine plus déterministe pour détecter les menaces. Ce socle a permis d’atteindre un certain niveau de précision, mais un nouveau défi émerge : la gestion des modèles frontières et des agents eux-mêmes. Beaucoup de clients sont, selon ses mots, « hystériques » face à cette nouvelle réalité, car la majorité des solutions du marché n’ont pas encore intégré une stratégie pour encadrer les agents IA, que ce soit du côté de leurs propres outils ou de ceux fournis par des tiers (pare-feu, plateformes de sécurité, etc.). Des gains opérationnels concrets Au-delà de la détection, les agents transforment aussi les tâches opérationnelles quotidiennes : renouvellement de certificats, requêtes de cache, diagnostics de configuration client complexes — autant d’opérations qui pouvaient auparavant nécessiter plusieurs appels et une expertise pointue peuvent maintenant être gérées via une simple conversation avec un agent, même depuis un téléphone. Mickael raconte un cas concret où un agent a diagnostiqué un problème de pare-feu propre à un client en quelques requêtes, un problème qu’il n’aurait pas su résoudre lui-même immédiatement malgré sa connaissance approfondie du produit. L’avenir des services MDR et la montée des benchmarks La conversation aborde également l’impact sur le marché des services MDR (Managed Detection and Response). Selon Mickael, l’automatisation permise par les agents va permettre à ces équipes de gérer un nombre de clients beaucoup plus important avec les mêmes ressources humaines, tout en relevant le niveau minimal de qualité du secteur. Il prédit également l’émergence de benchmarks formels pour évaluer non seulement les modèles d’IA, mais aussi les fournisseurs de services de sécurité eux-mêmes — un peu comme les leaderboards actuels qui comparent les performances des différents modèles de langage face à des scénarios d’attaque réels. Ces chiffres deviendront un argument de vente central, remplaçant progressivement les discours marketing par des données concrètes et vérifiables. Vers l’automatisation de la conformité Enfin, les deux interlocuteurs discutent du potentiel des agents pour transformer les processus de conformité (comme PCI-DSS), aujourd’hui perçus comme une lourde corvée administrative. Mickael envisage un futur où des « skills » standardisés permettront d’appliquer automatiquement les bonnes pratiques de conformité, réduisant la tentation de sauter des étapes. Il conclut en mentionnant qu’il prépare une présentation avec démonstration en direct pour partager plus en détail cette évolution avec la communauté, dans le but de sensibiliser les organisations à moderniser leur posture défensive à l’ère des agents IA. Collaborateurs Nicolas-Loïc Fortin Mickael Nadeau Crédits Montage par Intrasecure inc Locaux virtuels par Riverside.fm

  8. 9 juil.

    Teknik - Génération des mots de passe par LLM

    Parce que… c’est l’épisode 0x319! Shameless plug 6 au 9 août 2026 - Las Vegas, USA - - DEFCON 34 19 septembre 2026 - Montréal Canada - - Bsides Montréal 2026 22 septembre 2026 - Belgique - - BE-Cyber 24 au 25 septembre 2026 - Belgique - - BruCON 1er au 3 octobre 2026 - Krakow, Pologne - - AligatorCon 13 et 14 novembre 2026 - Worldwide - - DEATHCon 16 au 19 novembre - Rennes, France - Pôle d'Excellence Cyber (PEC) - European Cyber Week 2026 1 au 3 décembre 2026 - Ottawa, Canada - Forward Global - Forum inCYBER Canada Description Contexte de la recherche Dans cet épisode de Polysécure, l’animateur reçoit Gaëtan Ferry, chercheur en sécurité chez GitGuardian, pour discuter d’une recherche originale sur la génération de mots de passe par les grands modèles de langage (LLM). Le point de départ est un article publié début 2026 par Irregular, une entreprise israélienne, qui avait démontré que les mots de passe générés par les LLM présentaient des biais statistiques importants, variables selon les modèles. Cette découverte a poussé l’équipe de GitGuardian à se demander si ces mots de passe biaisés se retrouvaient réellement « dans la nature », c’est-à-dire utilisés par de vraies personnes sur de vrais systèmes. GitGuardian dispose d’un avantage unique pour répondre à cette question : son activité principale consiste à détecter des secrets (mots de passe, clés API, etc.) exposés publiquement, notamment sur GitHub. L’entreprise possède donc une base de données massive de secrets, dont une catégorie dite « générique » — des chaînes de caractères qui ressemblent à des mots de passe mais ne suivent aucun format standardisé identifiable. Méthodologie : les chaînes de Markov Pour détecter automatiquement si un mot de passe avait été généré par un LLM, l’équipe a eu l’idée de reconstruire une structure statistique classique : les chaînes de Markov, l’ancêtre technique des LLM, utilisées par exemple dans la prédiction de texte sur les claviers de téléphone. Ces chaînes excellent à capturer des biais statistiques dans une séquence de caractères. La méthode a consisté à interroger 40 modèles de LLM différents, en leur demandant de générer des centaines de mots de passe chacun. À partir de ces échantillons, plusieurs types de chaînes de Markov ont été construits, prenant en compte (ou non) la position des caractères dans le mot de passe. Ces structures permettent ensuite, face à un mot de passe arbitraire, d’estimer la probabilité qu’il ait été généré par un LLM, un peu comme une mesure d’entropie relative à une base de référence précalculée. Des biais spectaculaires Les résultats ont confirmé, voire amplifié, les observations d’Irregular. L’exemple le plus frappant concerne un modèle (Opus, à l’époque de l’étude) qui ne générait des mots de passe uniques que dans 35 % des cas — autrement dit, il répétait le même mot de passe dans 65 % des requêtes. Un modèle de Mistral faisait encore pire : il ne générait qu’un seul et unique mot de passe, toujours identique, laissant penser qu’il se contentait de restituer une valeur mémorisée durant son entraînement plutôt que d’en générer une nouvelle. Gaëtan Ferry explique ce phénomène par la tokenisation : certains modèles (comme GPT, étudié par Irregular) découpent le mot de passe en plusieurs tokens indépendants, ce qui introduit une certaine variabilité, alors que d’autres semblent traiter le mot de passe comme un token unique, menant à une quasi-absence de diversité. Un biais récurrent, observé sur presque tous les modèles, est l’alternance rigide entre catégories de caractères (minuscule, majuscule, chiffre, symbole) selon un schéma répétitif — un pattern idéal à capturer dans une chaîne de Markov. Sur un modèle donné, par exemple, un symbole « # » est suivi d’un « 8 » dans 90 % des cas. Ce comportement s’explique par la nature même des LLM : entraînés à reproduire des régularités linguistiques, ils sont fondamentalement conçus pour être prévisibles — l’exact opposé de ce qu’exige une bonne génération de mot de passe, qui requiert une forte entropie. Résultats sur les données réelles En appliquant cette classification à un échantillon d’environ 3 millions de secrets génériques collectés entre janvier et mars 2026, l’équipe a identifié environ 28 000 mots de passe présentant une très forte probabilité d’avoir été générés par un LLM, avec un seuil de confiance élevé. Bien que ce nombre représente une fraction modeste de l’échantillon total, la tendance est constante : environ 1 500 à 2 500 nouveaux mots de passe générés par LLM apparaissent chaque semaine sur GitHub, un rythme jugé préoccupant compte tenu qu’il ne s’agit que du sous-ensemble visible publiquement — la réalité en environnements privés étant probablement plus large encore. L’analyse du contexte d’apparition de ces mots de passe révèle deux scénarios typiques : soit un humain a manifestement demandé au LLM de générer un mot de passe pour l’insérer dans un fichier de configuration (par exemple une base de données), soit — plus troublant — un agent de développement autonome a lui-même pris la décision de générer et d’intégrer le mot de passe dans du code, comme dans un fichier de configuration Terraform observé par l’équipe, le tout dans un commit signé par l’agent d’IA lui-même, sans intervention humaine apparente. Une anecdote marquante Lors d’une présentation de ces résultats en conférence, Gaëtan Ferry a vu une personne quitter précipitamment la salle en voyant une diapositive listant des exemples de mots de passe faibles générés par un LLM. Cette même personne est revenue lui expliquer qu’elle avait justement demandé, ce matin-là, à un LLM de générer un mot de passe pour un service en ligne — et qu’elle venait de réaliser qu’il s’agissait exactement du même mot de passe affiché à l’écran. Un exemple frappant, selon lui, du fait que même des publics avertis en sécurité adoptent ce genre de pratique risquée. Conclusion Gaëtan Ferry conclut que le problème dépasse la simple question de la qualité du mot de passe généré : demander à un LLM hébergé chez un tiers de générer un secret expose potentiellement ce secret avant même qu’il n’apparaisse à l’écran de l’utilisateur, via les journaux et infrastructures du fournisseur. Il y voit une incompréhension plus profonde de la nature du LLM et des bonnes pratiques de gestion des secrets, et espère que ce partage contribuera à faire évoluer les pratiques des développeurs. Collaborateurs Nicolas-Loïc Fortin Gaetan Ferry Crédits Montage par Intrasecure inc Locaux réels par SSTIC

À propos

Podcast francophone sur la cybersécurité. Pour professionels.