François Proulx fait son retour pour présenter l’évolution de ses recherches sur la sécurité des chaînes d’approvisionnement (supply chain) depuis sa présentation de l’année précédente. Ses travaux portent sur la détection de vulnérabilités dans les pipelines de construction (build pipelines) des projets open source, un sujet qui avait suscité beaucoup d’intérêt suite à l’incident XZ Utils.

Depuis l’année dernière, l’équipe de François a considérablement amélioré ses outils et sa stratégie de détection. Plutôt que de scanner massivement tous les dépôts disponibles, ils ont adopté une approche plus ciblée en se concentrant sur des entités majeures comme Google, Red Hat, Nvidia et Microsoft. Ces organisations sont des contributeurs importants de projets open source critiques et bien maintenus.

Cette nouvelle approche leur permet de découvrir des centaines d’organisations GitHub par entité, chacune contenant parfois des milliers de dépôts. L’objectif reste le même : détecter des vulnérabilités zero-day dans les build pipelines qui permettent de compiler, tester et distribuer les projets open source, notamment via GitHub Actions.

François présente une analogie frappante pour expliquer la dangerosité des systèmes d’intégration continue : “un CI/CD, c’est juste du RCE as a service” (Remote Code Execution as a Service). Ces systèmes sont des applications web qui attendent de recevoir des déclencheurs sur une interface publique accessible via Internet. Dans le cas de GitHub Actions, il suffit d’ouvrir une pull request pour déclencher automatiquement l’exécution de tests.

Cette situation rappelle les vulnérabilités des années 1990-2000 avec les débordements de pointeurs. François utilise une formule percutante : “les build pipelines ressemblent à une application PHP moyenne de 2005 en termes de codage sécurisé”. Cette comparaison souligne que malgré les décennies d’évolution en sécurité informatique, les mêmes erreurs fondamentales se répètent dans de nouveaux contextes.

Les vulnérabilités exploitent principalement les entrées non fiables (untrusted input) provenant des pull requests. Même les brouillons de contributions peuvent déclencher automatiquement l’exécution de tests avant qu’un mainteneur soit notifié. Le problème s’aggrave quand les pipelines nécessitent des secrets pour communiquer avec des systèmes externes (notifications Slack, télémétrie, etc.).

Par défaut, GitHub Actions hérite parfois d’anciennes permissions en lecture-écriture, ce qui permet aux tests d’avoir accès à un token avec des droits d’écriture sur le dépôt. Cette configuration peut permettre à un attaquant d’écrire dans le dépôt de manière non visible.

L’équipe a considérablement affiné ses outils de détection. À partir de 200 000 résultats initiaux, ils appliquent des règles plus précises pour identifier environ 10 000 cas intéressants. Ces règles valident non seulement la présence de vulnérabilités, mais aussi les critères d’exploitation et la présence de secrets exploitables.

Après validation manuelle, environ 25% de ces 10 000 cas s’avèrent facilement exploitables. Ces chiffres démontrent l’ampleur du problème dans l’écosystème open source, même en reconnaissant l’existence probable de nombreux faux négatifs.

François rapporte avoir découvert des vulnérabilités dans 22 dépôts appartenant à Google, notamment dans un projet lié à Google Cloud (probablement Data Flow). Après avoir signalé et reçu une récompense pour la correction, une régression est survenue une semaine plus tard dans le même workflow, leur valant une seconde récompense.

Cette situation illustre un problème récurrent : même les grandes organisations comme Google peuvent reproduire les mêmes erreurs après correction, souvent par méconnaissance des mécanismes sous-jacents de ces nouvelles techniques d’exploitation.

L’incident le plus marquant concerne la bibliothèque Python Ultralytics, très populaire pour la détection d’images par apprentissage automatique. En août, l’équipe avait détecté une vulnérabilité dans ce projet mais s’était concentrée sur les découvertes chez Google, négligeant de signaler cette faille.

En décembre, Ultralytics a été compromis par l’injection d’un crypto-mineur, exploitant précisément la vulnérabilité identifiée quatre mois plus tôt. Cette attaque était particulièrement ingénieuse car elle ciblait des environnements avec des GPU puissants (utilisés pour le machine learning), parfaits pour le minage de cryptomonnaies, tout en restant discrète dans un contexte où une forte consommation GPU est normale.

Cet incident a motivé un changement stratégique majeur : passer de la simple détection de vulnérabilités à la détection proactive d’exploitations en cours. L’équipe ingère désormais le “firehose” des événements publics GitHub, soit environ 5,5 millions d’événements quotidiens.

Après filtrage sur les projets critiques avec des build pipelines, ils analysent environ 500 000 événements intéressants par jour. En appliquant leurs analyses sophistiquées et en croisant avec leurs connaissances des vulnérabilités, ils obtiennent environ 45 événements suspects à investiguer quotidiennement.

Cette nouvelle approche s’est rapidement avérée efficace. Pendant les vacances de Noël, leur système a continué d’ingérer les données automatiquement. Au retour, l’incident Kong (un contrôleur Ingress pour Kubernetes) leur a permis de créer une timeline forensique détaillée grâce aux données accumulées pendant leur absence.

La collaboration avec Flare, spécialisée dans l’analyse du dark web, a révélé des informations troublantes. En recherchant “Ultralytics” sur Breach Forum avec un filtrage temporel précis, François a découvert qu’un utilisateur avait créé un compte 24 heures avant l’attaque, publié exactement la vulnérabilité du pipeline Ultralytics en mentionnant l’utilisation de “Poutine” (leur outil), puis confirmé 24 heures après l’exploitation avoir gagné des Monero grâce à cette attaque.

Cette découverte confirme que les cybercriminels utilisent activement les outils de recherche en sécurité pour identifier et exploiter des vulnérabilités, transformant ces outils défensifs en armes offensives.

Cette situation soulève des questions importantes sur la responsabilité des chercheurs en sécurité. François insiste sur le fait que Poutine, leur outil de détection, devrait devenir le minimum absolu pour tout projet open source. Il compare cette nécessité à l’interdiction d’avoir des dépôts Git pour ceux qui n’implementent pas ces vérifications de base.

L’analogie avec PHP 2005 reste pertinente : il a fallu des années pour que la communauté PHP matûrisse ses pratiques de sécurité. Les build pipelines traversent actuellement la même phase d’évolution, avec des erreurs fondamentales répétées massivement dans l’écosystème.

François reconnaît honnêtement les limitations de leur approche. Leur système ne détecte que les attaques les moins sophistiquées - des “low hanging fruits”. Des attaques complexes comme celle de XZ Utils ne seraient probablement pas détectées par leurs outils actuels, car elles sont trop bien camouflées.

Le défi principal reste de filtrer efficacement le bruit dans les millions d’événements quotidiens pour obtenir un nombre d’alertes gérable par une petite équipe d’analystes. Ils reconnaissent que la majorité des incidents leur échappe probablement encore.

François exprime l’espoir que la maturation de l’écosystème des build pipelines sera plus rapide que les 20 ans qu’il a fallu pour sécuriser PHP. Leur travail de pionnier contribue à cette évolution en sensibilisant la communauté et en fournissant des outils concrets.

L’angle d’analyse des build pipelines est particulièrement pertinent car il se situe à la croisée des chemins entre le code source et sa distribution, avec des possibilités d’exécution de code qui en font un point critique de la chaîne d’approvisionnement logicielle.

Cette présentation illustre parfaitement l’évolution rapide des menaces dans l’écosystème open source moderne et la nécessité d’une vigilance constante pour sécuriser les infrastructures critiques dont dépend l’ensemble de l’industrie logicielle.