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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.).

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.

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.

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.

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.

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.

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.

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.

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.

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.

Dans cet épisode spécial, l’animateur reçoit François Labrèche, scientifique de données, pour discuter de la façon dont son entreprise traite l’immense volume de signaux de sécurité générés par son SOC à grande échelle (managed XDR). Contrairement à un SOC traditionnel, François travaille en back-end et a accès aux données de tous les clients, ce qui lui permet de construire des modèles et des filtres globaux applicables à l’ensemble des alertes. L’objectif de l’épisode est double : expliquer le pipeline de filtrage des données, puis illustrer son fonctionnement à l’aide d’un cas réel.

Le point de départ, ce sont des billions d’événements bruts. La première étape repose sur des règles de détection simples et peu coûteuses en calcul : correspondances avec des IOC (indicateurs de compromission), domaines ou IP malveillants, ainsi que des règles de corrélation basiques détectant des anomalies (par exemple, un utilisateur qui se connecte pour la première fois à une machine de développement). Ces règles ne prouvent rien de malveillant en soi, mais elles servent à isoler tout ce qui sort de l’ordinaire pour l’envoyer plus loin dans le pipeline. Après cette étape, il ne reste que 0,03 % des données initiales — un filtre énorme, mais qui représente encore 2,6 milliards d’événements sur deux semaines, un volume toujours impossible à traiter manuellement.

La deuxième étape combine deux mécanismes. La déduplication regroupe les alertes générées en grand nombre par une même attaque (comme un déni de service ou un scan) visant la même cible, réduisant ainsi des dizaines de milliers d’alertes en une seule. La corrélation, elle, relie des alertes distinctes provenant de détecteurs différents mais concernant la même activité (par exemple, plusieurs signaux liés à un même utilisateur et une même machine). Pour rendre ce travail possible, une équipe dédiée normalise en amont tous les signaux — qu’ils proviennent des senseurs propriétaires ou de fournisseurs tiers — dans un format standardisé, en capturant les éléments clés (nom de l’alerte, entités impliquées, IP, nom d’hôte, etc.). La corrélation s’appuie sur une fenêtre d’analyse fixe (environ un mois) et sur des bases de données de comptage historique, sans recours au machine learning à ce stade.

Cette étape cible des cas précis, propres à un client ou une situation donnée. Certaines alertes sont bénignes uniquement dans un contexte particulier : par exemple, un client qui effectue des scans de vulnérabilité hebdomadaires de façon planifiée, ou du trafic DNS provenant de Cloudflare, connu comme légitime. Ces règles de suppression sont paramétrées en collaboration avec le client ou l’ingénieur qui le supporte, et nécessitent une connaissance fine de son environnement. Des règles similaires sont aussi créées lorsque les équipes de recherche de menaces identifient des indicateurs malveillants publiés par erreur, afin de bloquer ces faux indicateurs pour l’ensemble des clients.

C’est ici qu’intervient le machine learning. Les alertes sont divisées en deux groupes selon leur sévérité : haute et moyenne/basse. Un modèle supervisé, entraîné chaque semaine sur des données historiques (les décisions passées des analystes), est appliqué aux alertes de sévérité élevée pour prédire une probabilité de menace réelle. Ce modèle sert à deux fins : fermer automatiquement les alertes jugées très peu probables (réduisant le bruit pour les analystes), ou ajuster la sévérité des alertes jugées menaçantes. Les alertes de sévérité plus basse ne sont pas ignorées : elles sont réutilisées pour enrichir le contexte autour d’une menace identifiée par le modèle, en allant chercher toutes les alertes liées au même utilisateur et à la même machine durant la même période.

Un point important soulevé dans la discussion concerne la dégradation des modèles : si un modèle supervisé était réentraîné sur ses propres prédictions (sans validation humaine), il se dégraderait progressivement, un peu comme les modèles de langage qui s’effondrent lorsqu’ils apprennent sur leurs propres données. Pour éviter ce piège, l’équipe conserve un échantillon de 5 à 10 % des données sur lequel le modèle n’agit jamais automatiquement — ces alertes sont envoyées aux analystes pour un triage normal, ce qui permet de mesurer en continu la performance réelle du modèle (faux négatifs, dérive) et de générer des données d’entraînement non biaisées pour les futurs modèles.

Pour illustrer concrètement le pipeline, François présente un cas réel portant sur deux semaines de données : à partir de 9,7 billions d’événements, le filtrage complet aboutit à seulement 81 000 alertes, soit environ 50 par client. Pour le client étudié, seulement sept alertes émergent — deux de haute sévérité liées à un vol de mot de passe, et cinq autres jugées bénignes (vol d’identifiants légitime confirmé par le client).

Grâce au modèle de priorisation, les deux alertes à forte probabilité de menace sont sélectionnées, puis l’analyste ramène toutes les alertes liées au même utilisateur et à la même machine, incluant trois alertes de sévérité plus basse. L’ensemble reconstitue une chronologie claire : un exécutable déguisé en éditeur PDF s’exécute, établit une connexion réseau anormale vers un serveur de commande, puis déclenche des détections successives de vol de mots de passe et de données de navigateur — signature typique d’un info stealer. Isolément, chaque alerte de type « info stealer » génère énormément de faux positifs ; c’est la combinaison de plusieurs signaux corrélés dans le temps, pour la même entité, qui permet à l’analyste de conclure avec confiance à une véritable compromission et de recommander la réimagerie de la machine du client.

L’épisode se conclut sur l’idée que ce type de pipeline permet non seulement de filtrer efficacement le bruit à très grande échelle, mais aussi de reconstruire, a posteriori, une histoire cohérente de l’attaque à partir des données brutes.

Dans cet épisode spécial de Polysécure, deux invités partagent leur expérience du programme Force, une formation destinée aux personnes provenant de domaines hors cybersécurité mais souhaitant développer des compétences dans ce champ, particulièrement dans le contexte des PME. Alain Dubois, administrateur système chez Métalus (une usine de transformation de métal) depuis deux ans, et Keven Landry, analyste fonctionnel chez UV Assurance depuis environ six mois, racontent chacun leur parcours et ce que le programme leur a apporté, tant sur le plan professionnel que personnel.

Keven a découvert le programme grâce à un collègue, Dominique Villeneuve, qui donnait un cours à l’UQTR et qui avait remarqué sa curiosité pour la cybersécurité. Bien qu’il ait déjà touché à plusieurs aspects techniques par le passé (développement, gestion d’infrastructure), il n’avait jamais approfondi ces connaissances de façon structurée. Le programme Force lui a permis d’acquérir une façon de penser applicable autant au travail qu’au quotidien, notamment pour reconnaître des situations à risque qui semblent anodines en apparence.

Alain, de son côté, possédait déjà une base en administration système et en cybersécurité. Également mis en contact avec la formation par Dominique, un ancien patron, il est arrivé chez Métalus dans une entreprise dont le réseau avait environ 25 à 30 ans d’existence, hérité d’une mentalité informatique dépassée. Le programme Force lui a permis d’identifier des lacunes importantes dans l’infrastructure de son employeur. En pratiquant des tests d’intrusion (pentests) sur son propre réseau, il a découvert des failles majeures qui l’ont mené à reconfigurer entièrement les routeurs et pare-feu, ainsi qu’à resegmenter les réseaux virtuels (VLAN). Il raconte même avoir démontré à son patron qu’il pouvait intercepter des conversations téléphoniques sur le réseau de l’entreprise, preuve concrète que la sécurité en place était insuffisante.

Interrogés sur les éléments qui les ont le plus marqués, les deux invités convergent sur plusieurs points. Le crochetage de serrures (lock picking) a impressionné les deux participants, qui ont réalisé à quel point il est facile de contourner certaines sécurités physiques d’un bâtiment avec un simple jeu de crochets. Cet aspect leur a rappelé que la cybersécurité ne se limite pas au monde numérique : la sécurité physique des lieux est tout aussi cruciale.

Alain souligne également la découverte de logiciels de sécurité accessibles financièrement pour les PME, souvent gratuits et développés par des communautés, mais tout aussi performants que des solutions payantes coûteuses. Il mentionne aussi la qualité générale du programme et des tests pratiques réalisés en conditions réelles simulées.

Keven, pour sa part, insiste sur son expérience avec Kali Linux, une distribution qu’il a installée sur son propre ordinateur portable pour scanner son réseau Wi-Fi et tester la robustesse de ses mots de passe, allant jusqu’à réussir à craquer son propre mot de passe Windows. Il évoque également les tests liés aux objets connectés (IoT), ayant notamment scanné le réseau domestique de son père pour découvrir un nombre surprenant de caméras vulnérables accessibles publiquement. Il mentionne aussi l’utilisation du Flipper Zero, un petit appareil permettant de réaliser des attaques de type “homme du milieu” (man-in-the-middle), ainsi que des exercices avec l’équipe de cybersécurité pour mettre en place des attaques Evil Twin. Les deux insistent sur l’importance d’utiliser ces outils de façon responsable et éthique, et non pour s’en prendre au réseau du voisin.

Même après la fin officielle du programme, les liens tissés durant la formation continuent de vivre. Alain mentionne un groupe Discord actif regroupant anciens et nouveaux apprenants, où l’entraide se poursuit : un participant y a notamment obtenu de l’aide après avoir été victime d’un rançongiciel, et Alain lui-même y a sollicité des conseils pour choisir un logiciel de surveillance réseau.

Keven, quant à lui, décrit un rôle plus communautaire au sein même de son entreprise, où il agit désormais comme une sorte de porte-parole pour l’équipe de cybersécurité. Alors qu’auparavant la cybersécurité était perçue par certains collègues comme une contrainte imposée sans explication, il est maintenant en mesure d’expliquer le pourquoi des décisions et des orientations prises, un rôle reconnu et apprécié dans son milieu de travail.

En conclusion, les deux invités reviennent sur ce qui distingue, selon eux, le programme Force d’autres formations plus théoriques ou superficielles en cybersécurité. Keven raconte l’exemple d’un stagiaire suivant une autre formation en cybersécurité qui ne connaissait pas des concepts de base comme l’OSINT ou les attaques par pass-the-hash, illustrant selon lui les limites de certains cursus trop généraux. Le programme Force, à l’inverse, offre un contenu détaillé, constamment mis à jour, sans nécessiter des années d’études.

Alain, qui donne lui-même des formations en cybersécurité à ses employés, explique que le programme lui a permis de saisir la différence fondamentale entre sensibiliser les gens à faire attention et former de véritables protecteurs de systèmes. Il affirme avoir modifié sa façon de former ses employés depuis, en insistant davantage sur la réalité concrète des menaces (rançongiciels, acteurs malveillants) pour les rendre plus vigilants.

Keven ajoute que la pédagogie du programme, alternant théorie et exercices pratiques concrets lors de séances synchrones aux trois semaines avec Dominique, lui a permis d’apprendre beaucoup plus efficacement que les approches purement théoriques auxquelles il avait été confronté par le passé, notamment durant son parcours scolaire.

L’animateur conclut l’épisode en saluant la passion manifeste des deux invités et l’importance de voir des personnes issues de domaines connexes rayonner la cybersécurité autour d’elles, contribuant ainsi à améliorer la posture de sécurité des PME québécoises, un secteur souvent moins bien outillé que les grandes entreprises face aux cybermenaces.

Ce podcast fait le point sur la présentation de François Proulx à NorthSec, où il aborde depuis quatre ans la sécurité de la chaîne d’approvisionnement logicielle (supply chain security). Chaque année a marqué une étape : la première présentait une vue d’ensemble du problème; la deuxième introduisait Poutine, un outil d’analyse statique open source destiné aux équipes défensives pour détecter les vulnérabilités dans les pipelines CI/CD; la troisième présentait les règles internes développées par son employeur, Boost Security, pour réduire les faux positifs de Poutine à grande échelle.

Le tournant de cette année vient d’un constat inquiétant. Fin 2024, François a découvert sur Breach Forums (un forum cybercriminel aujourd’hui disparu ou renommé) des mentions du mot « Poutine » associées au nom de son employeur. Un utilisateur anonyme, visiblement non anglophone, discutait ouvertement de l’exploitation de pipelines de build et partageait des vulnérabilités zero-day encore non exploitées au moment de la publication. Quelques heures plus tard, le projet Python très populaire Ultralytics (des millions de téléchargements hebdomadaires) était compromis. Le même compte est revenu peu après pour se plaindre du faible gain obtenu (quelques bitcoins via un mineur rapidement neutralisé), puis n’a plus jamais été réutilisé.

Cet épisode a révélé que certains attaquants surveillaient activement les publications de l’équipe et exploitaient les vulnérabilités presque en temps réel — un comportement inhabituel, car les attaquants sont généralement en retard sur les chercheurs. L’entreprise de François a elle-même été victime d’une attaque similaire (un employé compromis), ce qui a servi de signal d’alarme interne, même si l’incident a été contenu sans dommage.

François explique que l’effet multiplicateur des dépendances transitives (parfois des milliers, même pour une application simple utilisant React et quelques librairies npm) crée une surface d’attaque énorme. Beaucoup de ces micro-projets sont maintenus par des développeurs isolés, parfois inactifs, épuisés, ou disparus, ce qui laisse des vulnérabilités non corrigées, parfois même non divulguées publiquement.

GitHub Actions, utilisé par environ 90 % des projets open source sur GitHub, est identifié comme un vecteur clé. Bien que sa conception initiale limitait l’impact d’un code malveillant exécuté via une pull request (aucun accès aux secrets de publication), l’ajout progressif de fonctionnalités plus puissantes a ouvert la porte à des scénarios où des tiers non-mainteneurs peuvent déclencher l’accès à des secrets sensibles.

Face à ce constat, François a pris la décision — difficile pour lui, davantage orienté « blue team » — de créer un outil offensif : Smoke Meat. Il le compare à Metasploit, créé par HD Moore au début des années 2000, qui a démocratisé l’exploitation de vulnérabilités classiques. Smoke Meat vise à faire de même pour les vulnérabilités des pipelines CI/CD : rendre leur exploitation accessible à tous, pas seulement aux experts, afin de forcer une prise de conscience collective.

L’outil combine l’analyse statique de Poutine avec un moteur qui filtre les vulnérabilités les plus fiables et à fort impact (« blast radius »), génère automatiquement les payloads d’attaque, puis permet une exploitation réelle et un pivot latéral — comme un « meterpreter » adapté au contexte CI/CD. La terminologie choisie file la métaphore du barbecue : le « counter » (interface de l’opérateur), le « kitchen »/C2 (serveur de commande), et le « brisket » (l’implant qui s’exécute chez la victime, le « smoker »). Une fois actif, le brisket collecte rapidement (en une fraction de seconde) les secrets disponibles en mémoire, les trie selon leur potentiel de pivot, puis peut soit se retirer immédiatement, soit maintenir un tunnel pour une exploration plus poussée.

Contrairement à Metasploit qui exploite généralement des vulnérabilités connues, Smoke Meat cible des zero-days présents dans une infrastructure publique que n’importe qui peut découvrir en scannant des dépôts GitHub. François souligne que les dépôts privés, souvent perçus comme moins exposés que les dépôts publics (vitrines soignées des entreprises), contiennent en réalité davantage de négligences : clés temporaires oubliées, projets expérimentaux mal sécurisés, etc.

L’attaque du groupe Team PCP, discutée dans de précédents épisodes du podcast, illustre parfaitement ce mécanisme. Le groupe a exploité une vulnérabilité connue depuis longtemps dans l’outil populaire Trivy (développé par Aqua), infectant les utilisateurs consommant automatiquement les dernières versions. Le malware exfiltrait ensuite les secrets des nouveaux environnements infectés, permettant de répéter l’opération ailleurs — une propagation quasi-autonome, proche d’un ver informatique, bien que semi-manuelle.

François conclut sur un ton presque désabusé : après quatre ans à répéter le même message, seuls les attaquants semblent l’avoir vraiment entendu. Il insiste sur le caractère déterministe de Smoke Meat — aucun recours à des modèles de langage, uniquement des payloads fiables et reproductibles — et sur la simplicité des correctifs, souvent limités à quelques lignes dans un fichier YAML plutôt qu’à des refontes architecturales majeures. L’objectif de l’outil est de rendre le danger tangible et immédiat pour les équipes qui, autrement, resteraient indifférentes, en reproduisant l’esprit des débuts du hacking où la démonstration technique primait sur le simple discours théorique.