Fuites de code source : les attaquants connaissent le fournisseur de sécurité avant le correctif
8 min de lecture
Trellix, Okta, LastPass – trois fournisseurs de sécurité, trois violations du code source, un même schéma. Les attaquants compromettent délibérément des fournisseurs de sécurité afin d’identifier les vulnérabilités de leurs produits avant que ces failles ne soient connues de leurs propres clients. La due diligence classique sur le fournisseur ne suffit plus. Quiconque évalue aujourd’hui un fournisseur de SIEM, d’EDR ou d’IAM sans vérifier sa propre posture de sécurité reporte le risque – il ne l’élimine pas.
Les points clés en bref
- Le code source est une cible stratégique d’attaque. Qui connaît le code d’un fournisseur de sécurité connaît les vulnérabilités non corrigées avant leur divulgation publique. Trellix (2024), Okta (2023), LastPass (2022) – cette série d’attaques n’est pas un hasard.
- La période entre la violation et le correctif constitue la fenêtre de risque. Selon Mandiant M-Trends 2025, il s’écoule en moyenne 10 jours entre la compromission du fournisseur et la première exploitation des informations sur les vulnérabilités ainsi obtenues. Dix jours que le processus de patching ne couvre pas.
- La due diligence sur le fournisseur nécessite de nouveaux critères. Le certificat SOC-2 et l’audit ISO-27001 ne suffisent pas. Cinq questions concrètes que les CISO doivent poser avant la signature du contrat.
- La segmentation protège même si le fournisseur est compromis. L’architecture Zero Trust et les autorisations minimales pour les agents des outils de sécurité constituent la réponse structurelle aux compromissions côté fournisseur.
Qu’est-ce qu’une violation du code source ? Lors d’une violation du code source, les attaquants obtiennent l’accès au code source propriétaire d’un éditeur de logiciels. Dans le contexte des fournisseurs de sécurité, cela revêt une importance particulière : ce code contient des détails d’implémentation relatifs à la logique de détection, aux interfaces API et aux vulnérabilités potentielles, offrant ainsi aux attaquants un avantage temporel par rapport au fournisseur et à ses clients.
Articles connexesAmendes DSGVO 2026 : ce que les PME doivent vérifier dès maintenant / Acte européen sur l’IA août 2026 : date butoir à haut risque et vide réglementaire
Le schéma récurrent derrière Trellix, Okta et LastPass
Trois violations, trois années, trois vecteurs différents – mais un résultat commun : les attaquants ont eu accès au code de sécurité avant que les fournisseurs concernés ne comprennent pleinement ce qui avait été exfiltré. Ce n’est ni une coïncidence ni une malchance opérationnelle.
La violation de LastPass (août 2022) a commencé par la compromission de l’ordinateur portable d’un développeur senior. Les attaquants ont utilisé un serveur Plex Media non patché sur cet appareil personnel comme point d’entrée. De là, ils ont pénétré dans l’environnement de développement de LastPass et ont extrait le code source ainsi que des variables d’environnement contenant des identifiants pour les ressources cloud. Résultat : quatre mois plus tard, le coffre-fort de sauvegarde de production était compromis.
La violation d’Okta (octobre 2023) a touché le code source dans un dépôt GitHub. Les attaquants ont exploité un jeton de compte de service compromis. Ce qui a fuité n’était pas le noyau d’authentification principal, mais du code provenant du système de support client. Néanmoins : celui qui connaît le code connaît les cas limites que les développeurs n’ont jamais corrigés pour des raisons de rétrocompatibilité.
L’incident chez Trellix (2024) suit un schéma similaire. Les détails ne sont pas encore entièrement publics, mais le vecteur d’attaque est passé par une pipeline CI/CD compromise. Le schéma : ce n’est pas le code de production, mais le processus de build qui est la cible.
Chiffres clés pour le contexte
10 jours
Moyenne entre la compromission du fournisseur et la première exploitation (Mandiant M-Trends 2025)
62%
de toutes les violations avaient un lien avec la chaîne d’approvisionnement logicielle selon le Verizon DBIR 2025
18 mois
Moyenne entre la violation de LastPass et la communication complète aux clients sur l’étendue des dégâts
Pourquoi la due diligence classique des fournisseurs échoue
Certificat SOC-2 Type 2, audit ISO-27001, preuves de tests de pénétration – telles sont les exigences standard lors de l’évaluation des fournisseurs. Tous les trois vérifient un état à un instant T. Aucun d’eux ne vérifie si un ordinateur portable de développeur avec un accès actif d’attaquant se trouve aujourd’hui dans la pipeline de code source.
L’ISO-27001 est une certification de système de gestion. Elle vérifie si les processus sont documentés et appliqués – pas si un jeton de compte de service compromis est toujours actif. Le SOC-2 examine les contrôles sur une période définie. Une pipeline CI/CD avec une sécurité faible de la chaîne d’approvisionnement n’y apparaît pas nécessairement. Les rapports de tests de pénétration sont des instantanés – et ils testent typiquement la surface d’attaque externe, pas l’infrastructure de développement interne.
Cinq nouveaux critères pour l’évaluation des fournisseurs de sécurité
Ces cinq questions devraient figurer dans tout RFI (Request for Information) adressé à un fournisseur de sécurité, avant la signature d’un contrat. Les réponses en révèlent plus que n’importe quel certificat.
Comment votre pipeline CI/CD est-il protégé contre les attaques par chaîne d’approvisionnement ?
Attendu : Niveau SLSA 3 ou équivalent, commits signés, Pipeline-as-Code avec journal d’audit, aucun accès direct à la production depuis les environnements de développement.
Comment isolez-vous les accès des développeurs au code source des systèmes de production ?
Attendu : Identités séparées pour le Dev vs l’Ops, MFA partout, politique d’appareil privé pour les développeurs seniors ayant accès au code, accès JIT (Just-In-Time) pour les opérations CI privilégiées.
Combien de temps faut-il entre la détection d’une violation et la première information aux clients ?
Attendu : SLA contractuel pour les incidents de sécurité, idéalement 72 heures. LastPass a mis 4 mois pour divulguer l’intégralité de l’incident. Ce n’est pas un standard acceptable.
Quelles autorisations votre agent/capteur nécessite-t-il dans notre environnement ?
Attendu : Principe du moindre privilège documenté, pas d’« administrateur local » par défaut, segmentation réseau pour le trafic des capteurs, signature pour tous les paquets de mise à jour.
Disposez-vous d’un programme Bug Bounty et quelle est la durée moyenne de correction des correctifs ?
Attendu : Programme Bug Bounty public, durée moyenne de correction inférieure à 30 jours pour les CVE critiques, scores CVSSv3 lors de vos propres divulgations. Un fournisseur sans historique de divulgation publique n’est pas un bon signe.
Avantages et inconvénients : Architecture Zero Trust pour les agents d’outils de sécurité
Arguments en faveur d’une segmentation stricte
- Limitation du rayon d’explosion si l’agent du fournisseur est compromis
- Impose le principe du moindre privilège plutôt que « tout voir »
- Bloque les mouvements latéraux depuis un agent compromis
- Détecte plus tôt les schémas de communication inattendus
Arguments contre
- Certains outils de sécurité nécessitent des permissions étendues pour être efficaces
- La segmentation génère une surcharge de configuration
- Angles morts si le capteur n’a pas une vue complète du réseau
- Les processus de support fournisseur deviennent plus complexes
Foire aux questions
Quelle est la différence entre une fuite de code source et une violation de données classique ?
Lors d’une violation de données classique, ce sont les données clients, les identifiants ou les données financières qui fuient. Lors d’une fuite de code source, c’est le code propriétaire qui fuit. La différence : les données volées nuisent directement aux personnes concernées. Le code source volé donne aux attaquants une connaissance structurelle préalable des vulnérabilités, qu’ils peuvent utiliser contre tous les clients du fournisseur – avec une avance sur le correctif.
Comment réagir en tant que CISO si mon fournisseur de sécurité signale une fuite de code source ?
Premièrement : contacter le fournisseur et clarifier la portée de la fuite (quel code, quelle période, quels systèmes). Deuxièmement : minimiser temporairement les permissions de l’agent du fournisseur dans votre propre environnement. Troisièmement : vérifier les journaux pour détecter toute activité inhabituelle de l’agent du fournisseur au cours des 30 derniers jours. Quatrièmement : évaluer si une désactivation temporaire de l’outil présente moins de risques que son fonctionnement continu.
Qu’est-ce que SLSA et pourquoi est-il pertinent lors des évaluations de fournisseurs ?
SLSA (Supply-chain Levels for Software Artifacts) est un framework de Google pour la sécurité des processus de compilation logicielle. Le niveau 3 signifie : le processus de compilation est reproductible de manière traçable, les artefacts sont signés, l’environnement de compilation est isolé. Les fournisseurs de sécurité atteignant le niveau SLSA 3 disposent d’une pipeline de compilation structurellement plus robuste que ceux sans documentation SLSA.
Suis-je responsable en tant que CISO si mon fournisseur de sécurité est compromis ?
La question de la responsabilité dépend de la rédaction contractuelle et de la classification réglementaire. NIS2 exige des exploitants d’infrastructures critiques une analyse des risques de la chaîne d’approvisionnement – celui qui n’a pas documenté de processus de diligence raisonnable en matière de sécurité pour la sélection des fournisseurs assume une corresponsabilité. Les autorités de régulation vérifieront de plus en plus, en cas d’incidents liés aux infrastructures critiques, si l’acheteur a suffisamment évalué le fournisseur.
Quels secteurs sont particulièrement exposés ?
Tous les secteurs utilisant des fournisseurs de sécurité avec un accès système profond : infrastructures critiques, prestataires de services financiers, secteur de la santé, défense et aérospatiale. Particulièrement critique : les organisations qui exécutent des outils de sécurité directement sur les nœuds du réseau OT sans segmentation entre les agents IT et OT.
Suggestions de lecture de la rédaction
Plus du réseau média MBF
Source image de couverture : Pexels / Polina Zimmerman (px:3779082)
