Parce que… c’est l’épisode 0x670! Shameless plug 25 et 26 février 2026 - SéQCure 2026 CfP 14 au 17 avril 2026 - Botconf 202628 et 29 avril 2026 - Cybereco Cyberconférence 20269 au 17 mai 2026 - NorthSec 20263 au 5 juin 2025 - SSTIC 2026 Description Ce podcast réunit François Proulx, Alexis Maurer-Fortin et Sébastien Graveline, chercheurs chez BoostSecurity, une startup montréalaise spécialisée en sécurité applicative. L’épisode explore les coulisses de leur travail de recherche et développement, particulièrement leurs découvertes récentes sur les vulnérabilités de type “race condition” dans les pipelines CI/CD. Structure et méthodologie de recherche L’équipe de recherche de BoostSecurity fonctionne de manière structurée mais flexible. François Proulx définit les grandes orientations annuelles basées sur les tendances émergentes et les apprentissages de l’année précédente. Alexis apporte son expertise en développement backend et son approche défensive, tandis que Sébastien, joueur avide de CTF, contribue avec une perspective offensive de red team. Garance, absente lors de l’enregistrement, assure la rigueur académique en effectuant des revues approfondies de la littérature scientifique. Infrastructure de recherche massive L’équipe a développé une infrastructure impressionnante pour la détection de vulnérabilités à grande échelle. Au cœur de leur système se trouve Poutine, un outil open source développé en Go pour scanner les pipelines de build, particulièrement les GitHub Actions. Cette infrastructure analyse continuellement l’écosystème open source, accumulant plusieurs téraoctets de données sur des millions de projets. Leur système “Threat Hunter” ingère en quasi-temps réel tous les événements publics sur GitHub avec un délai d’environ cinq minutes, capturant même les dépôts éphémères qui n’existent que brièvement. Cette capacité leur permet de détecter des attaques en cours, comme l’attaque par “confused deputy” de Kong qu’ils ont pu capturer et analyser. Les données sont stockées dans Google Cloud BigQuery, permettant des analyses complexes qui auraient autrefois nécessité des semaines de travail. Découverte d’une nouvelle technique de malware François décrit une découverte récente concernant une technique d’obfuscation utilisant les “Private Use Areas” d’Unicode. Ces plages de caractères, réservées mais jamais attribuées officiellement, permettent d’encoder des données arbitraires dans des chaînes de caractères invisibles. Un malware peut ainsi être caché dans du code source JavaScript, Python ou Go sans être visible dans les éditeurs standards comme Visual Studio Code. En réponse, l’équipe a développé “Puant”, un outil open source capable de scanner efficacement des millions de fichiers en quelques secondes pour détecter l’utilisation de ces caractères suspects. L’outil peut s’intégrer facilement dans les pipelines CI/CD pour bloquer du code contenant ces caractères invisibles lors de la révision de pull requests. Vulnérabilités “Time of Check, Time of Use” dans les pipelines CI/CD La découverte majeure présentée concerne une classe de vulnérabilités de type “race condition” appliquée aux build pipelines. L’équipe a identifié six cas significatifs affectant des entreprises comme Nvidia, GitHub Copilot et Jupyter Notebook. Le premier cas découvert impliquait le “copy-pr-bot” de Nvidia. Ce bot copie le code d’une pull request dans une branche dédiée après qu’un mainteneur ait commenté “ok to test”. L’équipe a découvert une fenêtre d’environ cinq secondes entre la commande du mainteneur et l’exécution du bot, pendant laquelle un attaquant pouvait modifier le code malicieusement puis le rétablir, rendant l’attaque invisible. Pour GitHub Copilot, la vulnérabilité était encore plus exploitable manuellement. Lorsqu’un mainteneur assignait Copilot pour résoudre un bug décrit dans une issue, un attaquant pouvait modifier les instructions pendant la race condition, demandant au bot d’insérer une backdoor tout en affichant une tâche légitime à l’écran. Le cas de Jupyter Notebook était particulièrement ironique : la vulnérabilité résidait dans le code de mitigation d’une race condition précédemment rapportée. La correction initiale présentait une erreur typographique dans la référence temporelle utilisée, rendant la mitigation complètement inefficace. Recommandations et mitigations L’équipe propose plusieurs stratégies de mitigation. La plus importante consiste à utiliser des mécanismes atomiques qui lient l’approbation du mainteneur à un commit SHA spécifique. GitHub offre la fonctionnalité “Pull Request Review” qui garantit cette atomicité, contrairement aux simples commentaires ou labels qui restent vulnérables aux race conditions. Les environnements ...
Voir plus
Voir moins
50 min
54 min