Zero-Days RMM et IDE 2026 : ScreenConnect, JetBrains et GitHub

En février 2024, la vulnérabilité CVE-2024-1709 dans ConnectWise ScreenConnect (un outil de Remote Monitoring and Management - RMM utilisé par des milliers de MSPs dans le monde dont plusieurs centaines en France) a été exploitée massivement en quelques heures par des groupes ransomware comme LockBit, BlackCat/ALPHV, et Akira pour compromettre les clients des MSPs via leurs infrastructures de télégestion partagées — un seul ScreenConnect vulnérable pouvant exposer des centaines de clients simultanément. En mars 2024, la vulnérabilité CVE-2024-27198 dans JetBrains TeamCity (un serveur CI/CD populaire) permettait l'authentification bypass complète, exposant les pipelines de build et les secrets de déploiement de milliers d'organisations. Ces deux incidents illustrent une tendance inquiétante de 2025-2026 : les outils de développement (IDE, serveurs CI/CD) et d'administration à distance (RMM) sont devenus des cibles prioritaires pour les attaquants car ils offrent un accès privilégié à de nombreux systèmes simultanément, contiennent des secrets de déploiement et des credentials, et bénéficient souvent de règles de pare-feu permissives. Mon analyse est sans concession : les éditeurs de RMM et d'IDE ont largement sous-investi dans la sécurité de leurs produits pendant des années, et leurs clients en payent maintenant le prix avec des compromissions massives. Ce guide technique approfondi analyse les vulnérabilités zero-day et N-day les plus critiques affectant les outils RMM (ScreenConnect, Kaseya VSA, NinjaRMM, TeamViewer), les IDE et serveurs CI/CD (JetBrains IntelliJ/TeamCity, Cursor, Windsurf, GitHub Actions), et les serveurs de code (GitHub Enterprise, GitLab), avec les techniques d'exploitation et les contre-mesures pour les organisations françaises soumises à NIS 2.

CVE-2024-1709 ScreenConnect : authentification bypass critique

La vulnérabilité CVE-2024-1709 dans ConnectWise ScreenConnect (versions antérieures à 23.9.8) est un authentication bypass permettant à un attaquant non authentifié de créer un administrateur sur le serveur ScreenConnect via une simple requête HTTP modifiée, puis d'installer des agents RMM sur tous les systèmes gérés par ce serveur. La vulnérabilité exploite une faille dans le mécanisme de configuration initiale du serveur (/SetupWizard.aspx) qui reste accessible même après la configuration initiale, permettant de reconfigurer l'instance et de créer un nouveau compte administrateur. Le score CVSS de 10.0 (maximum) reflète l'impact catastrophique de cette faille : l'exploitation ne nécessite aucune authentification, aucune interaction utilisateur, et offre un contrôle total sur l'ensemble des systèmes gérés via ScreenConnect. La preuve de concept (PoC) a été publiée dans les 24 heures suivant la divulgation par ConnectWise, et des scanners automatisés la recherchant sur Internet ont été détectés dans les 2 heures.

L'exploitation de CVE-2024-1709 a suivi le scénario suivant dans les incidents documentés : identification des serveurs ScreenConnect vulnérables via des scans Shodan ou Censys ciblant le port 8040/8041 (ports par défaut ScreenConnect), création d'un compte administrateur via la requête HTTP malformée sur le endpoint SetupWizard, installation d'agents ScreenConnect ou d'autres outils RMM (Atera, ConnectWise Automate) sur les systèmes clients via les scripts d'automatisation ScreenConnect, déploiement de ransomware ou d'outils de reconnaissance sur les systèmes clients compromis. La mitigation immédiate recommandée par ConnectWise et le CERT-FR était la mise à jour en urgence vers la version 23.9.8 ou supérieure, ou en cas d'impossibilité de patcher immédiatement, l'isolation complète du serveur ScreenConnect du réseau Internet par des règles de pare-feu bloquant tous les accès entrants jusqu'au patch. Les indicateurs de compromission (IOCs) publiés par Huntress et d'autres fournisseurs de sécurité incluaient des adresses IP spécifiques des attaquants et des noms d'agents ScreenConnect malveillants créés lors des exploitations.

CVE-2024-27198 JetBrains TeamCity : pipeline CI/CD compromis

CVE-2024-27198 (et son jumeau CVE-2024-27199) dans JetBrains TeamCity (versions antérieures à 2023.11.4) sont des vulnérabilités d'authentification bypass permettant à un attaquant non authentifié d'accéder à des endpoints administratifs de TeamCity via une manipulation de l'URL qui contourne la vérification d'authentification. Les endpoints affectés incluent des APIs REST permettant la création d'utilisateurs administrateurs, la lecture des tokens d'authentification existants, et l'exécution de commandes sur le serveur. L'impact de la compromission d'un serveur TeamCity est particulièrement grave car TeamCity stocke les credentials de tous les services auxquels les pipelines de build se connectent : credentials Docker Hub, clés AWS/Azure/GCP, tokens GitHub/GitLab, clés de signature de code, et mots de passe de bases de données de production. L'exfiltration de ces secrets depuis un TeamCity compromis offre un accès potentiel à l'ensemble de l'infrastructure cloud d'une organisation.

L'exploitation de CVE-2024-27198 a été documentée par le groupe APT Midnight Blizzard (Cozy Bear, APT29) et d'autres acteurs étatiques russes dans des campagnes ciblant des organisations occidentales de défense, de technologie, et d'administration publique. La technique d'exploitation utilise une requête HTTP avec une URL modifiée (/app/rest/users avec un suffixe spécial) qui bypasse la vérification d'authentification de TeamCity, permettant la création d'un utilisateur administrateur en une seule requête POST sans authentification préalable. Les organisations utilisant des services JetBrains hébergés (TeamCity Cloud) n'étaient pas affectées car JetBrains avait patché ses instances cloud avant la divulgation publique. Les indicateurs de compromission post-exploitation incluaient la création de nouveaux comptes administrateurs avec des noms génériques dans TeamCity, l'installation d'agents TeamCity sur des serveurs de build inhabituels, et des activités d'exfiltration de données depuis les projets TeamCity vers des destinations externes inconnues.

Kaseya VSA et l'attaque MSP supply chain de 2021

L'attaque Kaseya VSA de juillet 2021 reste la référence des attaques supply chain via RMM avec le plus grand impact de l'histoire : le groupe ransomware REvil a exploité une série de vulnérabilités zero-day dans Kaseya VSA (CVE-2021-30116, CVE-2021-30119, CVE-2021-30120) pour compromettre environ 60 MSPs utilisant le RMM Kaseya VSA on-premise, entraînant le chiffrement d'environ 1 500 à 2 000 entreprises clientes de ces MSPs dans le monde, dont plusieurs entreprises françaises. L'exploit utilisait un bypass d'authentification dans le portail web de Kaseya VSA, suivi d'une injection de code SQL permettant l'exécution de code sur le serveur VSA, puis l'exploitation des agents VSA pour déployer le ransomware REvil sur tous les endpoints gérés en une seule opération automatisée. La demande de rançon initiale était de 70 millions de dollars USD pour une clé de déchiffrement universelle applicable à toutes les victimes simultanément.

Les leçons de l'attaque Kaseya pour les MSPs français utilisant des outils RMM similaires sont claires : les serveurs RMM on-premise ne doivent jamais être exposés directement sur Internet mais uniquement accessibles via VPN avec MFA fort, la politique de mise à jour des RMM doit permettre des patches en urgence dans les 4 heures suivant une alerte critique (pas lors de la fenêtre de maintenance mensuelle), et les équipes SOC doivent surveiller les accès au RMM avec des alertes sur toute activité en dehors des plages d'administration normale (nuit, week-end, depuis des IPs inconnues). Les clients des MSPs doivent également auditer régulièrement quels accès distants leurs MSPs maintiennent dans leurs systèmes — la confiance aveugle accordée aux MSPs sans contrôle de sécurité de leurs propres pratiques est un risque systémique dans les chaînes d'approvisionnement IT françaises. Notre service de RSSI externalisé inclut l'audit de la sécurité des accès MSP pour les organisations clientes de ces services.

Extensions VS Code et IDE malveillantes : typosquatting et supply chain

Le marketplace d'extensions VS Code (Visual Studio Code Marketplace) contient plus de 50 000 extensions développées par des tiers, dont certaines ont été utilisées comme vecteurs d'attaque supply chain en 2024-2026. Des extensions malveillantes publiées sous des noms similaires à des extensions populaires (typosquatting) installaient des backdoors, exfiltraient des variables d'environnement contenant des tokens API et des credentials cloud, ou persistaient dans l'environnement de développement pour intercepter les credentials saisis dans le terminal. En mai 2024, une extension VS Code malveillante imitant une extension légitime de débogage Python avait été installée par plus de 100 000 développeurs avant sa détection et suppression du marketplace. L'impact pour une entreprise dont les développeurs installent des extensions malveillantes inclut l'exfiltration de tout le code source affiché dans l'IDE, des tokens d'API GitHub ou cloud copiés dans le terminal, et des mots de passe de bases de données de développement.

La mitigation des risques d'extensions IDE malveillantes dans les organisations nécessite plusieurs contrôles complémentaires : une allowlist d'extensions approuvées imposée via les politiques VS Code Remote Development ou les profils VS Code managés par l'entreprise, une revue de sécurité des extensions avant leur approbation organisationnelle (vérification des permissions demandées, du code source public disponible, de la réputation de l'éditeur), la configuration des proxies d'entreprise pour bloquer les connexions des extensions vers des domaines non approuvés, et la surveillance des processus enfants lancés par VS Code pour détecter les extensions qui exécutent des commandes shell inhabituelles. Les nouvelles IDE IA comme Cursor et Windsurf (basés sur VS Code) partagent le même risque d'extensions malveillantes et y ajoutent des risques spécifiques liés à leurs fonctionnalités IA : exfiltration du code source vers des serveurs IA tiers, ou exploitation des capacités d'exécution de code des agents IA pour des attaques de type "prompt injection via le code source".

Sécurité des IDE IA : Cursor, Windsurf et risques des agents IA

Cursor et Windsurf (aussi connu sous le nom Codeium) sont des IDE basés sur VS Code qui intègrent des modèles de langage large (LLM) pour la complétion de code, la génération de code, et les agents IA capables d'exécuter des actions dans l'environnement de développement (créer des fichiers, exécuter des commandes, modifier le code). Ces nouvelles capacités d'agents IA dans l'IDE introduisent des vecteurs d'attaque inédits : les attaques de prompt injection via le code source (un attaquant insère des instructions IA malveillantes dans un fichier de code ou un commentaire qui, lorsqu'analysé par l'agent IA de l'IDE, déclenche des actions non désirées comme l'exfiltration du contenu du clipboard, l'exécution de commandes shell, ou la modification du code pour introduire des vulnérabilités délibérées) constituent une menace émergente documentée par des chercheurs en sécurité IA.

Les risques de confidentialité des IDE IA sont également significatifs : le code source envoyé aux APIs des serveurs IA (OpenAI pour GitHub Copilot, Anthropic pour Claude-based IDEs, Mistral/autres pour les IDE EU-compliant) quitte l'environnement de développement et est traité sur des serveurs cloud tiers. Pour les organisations manipulant du code source classifié, des algorithmes propriétaires, ou des données personnelles (traitement dans le code), l'utilisation d'IDE IA avec des APIs cloud tiers peut violer les politiques de sécurité ou des réglementations sectorielles (secrets industriels, propriété intellectuelle). La mitigation recommandée est l'utilisation de modèles LLM on-premise (Ollama, LM Studio) pour les IDE IA sur les postes de développeurs manipulant du code sensible, ou des offres entreprise d'IDE IA avec des garanties contractuelles de non-utilisation du code pour l'entraînement des modèles (GitHub Copilot Enterprise avec des engagements de confidentialité étendus). Notre service de diagnostic NIS 2 inclut une évaluation des usages IA dans les équipes de développement.

GitHub Actions et CI/CD poisoning : secrets exfiltration

GitHub Actions est devenu un vecteur d'attaque supply chain majeur en 2025 via plusieurs techniques : le CI/CD poisoning via les pull requests (un attaquant fork un dépôt public, modifie le fichier de workflow GitHub Actions pour exfiltrer les secrets du dépôt, puis soumet une pull request qui déclenche automatiquement le workflow malveillant sur le dépôt cible si la configuration pull_request_target est mal configurée), la compromise d'actions tierces (des actions GitHub populaires référencées dans des workflows avec uses: actions/checkout@v3 peuvent être compromises si leur dépôt est piraté ou si elles sont référencées par tag mutable plutôt que par hash SHA immutable), et les Actions malveillantes typosquattées (des actions publiées avec des noms similaires aux actions officielles GitHub pour tromper les développeurs qui copient des exemples de workflow).

La protection des secrets GitHub dans les workflows CI/CD nécessite une configuration rigoureuse : les secrets sensibles (clés de production, tokens de déploiement cloud) doivent être configurés comme GitHub Environment Secrets avec des règles de protection d'environnement (approbation manuelle requise pour les déploiements en production, restriction aux branches protégées), plutôt que comme secrets de dépôt accessibles depuis tous les workflows. L'utilisation de pin de hash SHA pour toutes les actions tierces (uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 plutôt que @v4) garantit que le code de l'action ne change pas silencieusement si le tag est mis à jour. Les outils StepSecurity (disponible sur app.stepsecurity.io) et zizmor analysent automatiquement les workflows GitHub Actions pour identifier les configurations dangereuses et recommander les corrections, et peuvent être intégrés dans les pipelines pour bloquer les workflows non sécurisés avant merge.

TeamViewer et AnyDesk : vulnérabilités des outils de prise en main

TeamViewer et AnyDesk sont les outils de prise en main à distance les plus déployés dans les entreprises françaises, utilisés par les équipes de support IT, les DSI externalisées, et les MSPs pour la maintenance des postes utilisateurs. En 2024, TeamViewer a subi une compromission de son réseau d'entreprise interne par le groupe APT29 (Midnight Blizzard) en juin 2024, soulevant des questions sur la sécurité de l'infrastructure de TeamViewer elle-même (bien que l'enquête forensique ait conclu que seul l'environnement IT interne avait été affecté, pas les données clients ni l'infrastructure de connexion). AnyDesk a subi une compromise similaire de ses systèmes de production en début 2024, forçant la révocation et le renouvellement de tous les certificats de code et de l'infrastructure de clés AnyDesk.

Les risques de sécurité spécifiques aux déploiements TeamViewer et AnyDesk en entreprise incluent : les comptes non protégés par MFA exposés à des attaques par brute-force (TeamViewer et AnyDesk permettent la connexion par ID/mot de passe sans 2FA si non configuré), les versions obsolètes avec des vulnérabilités CVE non patchées (TeamViewer et AnyDesk publient régulièrement des mises à jour de sécurité critiques), et les policies d'accès trop permissives (accès permanent 24/7 à des postes sensibles plutôt que sessions à la demande avec expiration). La recommandation de l'ANSSI pour les outils de prise en main à distance est leur restriction aux connexions depuis des sources connues uniquement (VPN d'entreprise ou plages IP des prestataires autorisés), l'activation obligatoire du MFA, et la journalisation de toutes les sessions de connexion avec enregistrement vidéo optionnel pour les systèmes les plus sensibles.

GitLab CE/EE : vulnérabilités critiques 2025-2026

GitLab (Community Edition et Enterprise Edition) est régulièrement affecté par des vulnérabilités de sécurité critiques dans ses fonctionnalités web complexes. En 2025, plusieurs CVEs critiques dans GitLab ont été exploités dans la nature : des vulnérabilités de SSRF (Server-Side Request Forgery) dans les fonctionnalités d'import de projets permettant l'accès à l'infrastructure interne depuis l'extérieur, des vulnérabilités de RCE (Remote Code Execution) via le rendu de fichiers Markdown ou les pipelines CI/CD GitLab, et des path traversal dans les API de téléchargement de fichiers permettant la lecture de fichiers arbitraires sur le serveur GitLab. Les instances GitLab auto-hébergées exposées directement sur Internet sans restriction d'accès sont particulièrement vulnérables car elles ciblent une base d'utilisateurs technique avec des dépôts contenant du code source, des secrets de configuration, et des clés d'accès aux environnements cloud.

La gestion de la sécurité d'une instance GitLab auto-hébergée requiert : une veille active des bulletins de sécurité GitLab publiés chaque mois le deuxième mercredi (GitLab Security Release), un processus de patch d'urgence permettant la mise à jour dans les 24-48 heures suivant la publication d'un CVE critique, la configuration de l'authentification OAuth2 ou SAML avec un provider SSO d'entreprise pour éviter la gestion de comptes locaux GitLab, l'activation de l'audit logging GitLab (GitLab EE) pour journaliser les actions administratives et les accès aux dépôts sensibles, et la restriction des pipelines CI/CD aux runners autorisés avec des images Docker validées. Pour les organisations françaises hébergeant du code source sensible sur GitLab, l'alternative GitLab.com (SaaS) avec des garanties de conformité RGPD et une gestion de la sécurité par GitLab Inc. peut réduire la charge opérationnelle de sécurité par rapport à l'auto-hébergement.

Défense en profondeur contre les attaques RMM

La défense contre les attaques ciblant les outils RMM repose sur une stratégie en couches couvrant l'accès réseau, l'authentification, la surveillance, et la réponse aux incidents. Au niveau accès réseau : aucun outil RMM ne doit être exposé directement sur Internet — l'accès doit passer par un VPN avec MFA fort (TOTP ou FIDO2), avec des rules de pare-feu bloquant tous les ports RMM depuis Internet et autorisant uniquement les connexions depuis les plages IP du réseau d'entreprise ou du VPN. Pour les MSPs devant accéder à distance aux infrastructures clients, des solutions d'accès zéro-trust (comme Cloudflare Access ou Zscaler Private Access) permettent un accès granulaire par client et par technicien sans exposer les serveurs RMM sur Internet.

Au niveau surveillance et détection : les connexions RMM entrantes doivent générer des alertes en dehors des plages horaires normales d'administration, les agents RMM installés sur les endpoints doivent être inventoriés et comparés régulièrement à la liste des agents autorisés (tout agent RMM non répertorié est suspect), et les actions effectuées via le RMM (installation de logiciels, exécution de scripts, accès aux fichiers) doivent être journalisées et auditables. Les EDR modernes comme Microsoft Defender for Endpoint ou CrowdStrike Falcon détectent l'installation d'agents RMM non autorisés via leurs bases de Threat Intelligence qui classifient les agents RMM populaires et alertent sur l'installation d'agents RMM inattendus sur des systèmes de production. Notre service de pentest Active Directory inclut des tests de résistance aux attaques via les outils RMM déployés dans l'infrastructure cliente.

Gestion des vulnérabilités critiques : processus NIS 2

La gestion des vulnérabilités zero-day et N-day dans les outils critiques (RMM, CI/CD, IDE) doit suivre un processus documenté et traçable pour la conformité NIS 2. L'article 21 de la directive NIS 2 requiert la mise en place de politiques d'analyse des risques et de mesures de gestion des vulnérabilités, incluant des délais de correction définis selon la criticité. Un processus de patch management NIS 2 pour les vulnérabilités critiques (CVSS >= 9.0) dans les outils exposés sur Internet comprend : réception des alertes CERT-FR/ANSSI dans les 30 minutes (via les flux RSS/email des bulletins de sécurité), évaluation de l'exposition dans les 2 heures (l'outil vulnérable est-il exposé, dans quelle version, avec quels contournements possibles), patch ou isolation dans les 24 heures (soit patch direct, soit isolation réseau du système vulnérable jusqu'au patch), et documentation de l'action prise avec les preuves de patch pour les audits de conformité.

Les outils d'inventaire et de scan de vulnérabilités comme Tenable Nessus, Qualys VMDR, ou Rapid7 InsightVM permettent d'identifier automatiquement les versions vulnérables des logiciels inventoriés dans le parc (y compris les agents RMM et les serveurs CI/CD) dès la publication d'une nouvelle CVE, en corrélant la base de données CVE avec l'inventaire des logiciels détectés. Cette automatisation est indispensable pour les organisations avec de nombreux systèmes gérés car l'identification manuelle des systèmes vulnérables prend trop de temps face à la vitesse d'exploitation des CVEs critiques en 2026. La notion de mean time to remediate (MTTR) les vulnérabilités critiques est devenue un KPI de conformité NIS 2 : un MTTR supérieur à 72 heures pour les vulnérabilités CVSS 10.0 dans des systèmes exposés sur Internet constitue une lacune de conformité documentable lors d'un audit.

Threat hunting RMM et IDE : détection des compromissions

Le threat hunting proactif pour les compromissions via RMM et IDE se concentre sur des patterns comportementaux qui distinguent l'utilisation légitime des accès à distance de l'exploitation malveillante. Les requêtes de hunting à chercher dans les EDR et les SIEM pour les compromissions RMM incluent : exécution de commandes PowerShell depuis des processus parents RMM (TeamViewer, ConnectWise, Kaseya) pendant des plages horaires inhabituelles, création de nouveaux utilisateurs Windows ou de modifications de droits locaux depuis des processus RMM, téléchargement d'archives depuis des domaines inconnus via des processus RMM (indicateur de téléchargement d'outils d'attaque), et connexions réseau vers des IPs external depuis des processus RMM vers des ports non standard (C2 dissimulé dans les canaux RMM). Ces patterns de hunting peuvent être formalisés en règles YARA ou Sigma et déployés dans les plateformes de détection.

Pour la détection des compromissions CI/CD, le threat hunting se concentre sur : des modifications de fichiers de workflow CI/CD (Jenkinsfile, GitHub Actions YAML, .gitlab-ci.yml) non associées à des pull requests légitimes dans les dépôts de code, des accès aux secrets CI/CD en dehors des exécutions de pipeline planifiées, des connexions réseau depuis les agents de build vers des destinations non habituelles (exfiltration de secrets), et des créations de nouveaux tokens d'accès ou de nouveaux webhooks dans les plateformes GitLab/GitHub par des utilisateurs non-développeurs. Les logs d'audit de GitLab Enterprise, GitHub Enterprise, et Jenkins permettent de détecter ces anomalies si la journalisation est correctement configurée et ingérée dans le SIEM. Notre service de audit de sécurité inclut la revue des configurations CI/CD et RMM et la définition des règles de détection adaptées.

Audit de sécurité MSP : évaluer la maturité des prestataires

Les Managed Service Providers (MSPs) français qui fournissent des services d'infogérance à des entités NIS 2 sont eux-mêmes soumis à des exigences de sécurité renforcées sous NIS 2 (article 21 pour les fournisseurs critiques). L'évaluation de la maturité de sécurité d'un MSP par ses clients doit couvrir spécifiquement les outils RMM utilisés : quels RMM sont déployés, quelle est la politique de mise à jour et de patch, comment les accès sont protégés (VPN, MFA), quels logs d'audit sont disponibles pour les clients, et quelle est la procédure de réponse aux incidents en cas de compromission du RMM. Un questionnaire de sécurité fournisseur adapté aux risques RMM doit être soumis annuellement aux MSPs critiques, avec une revue des réponses par l'équipe sécurité du client. Les certifications ISO 27001 des MSPs, bien qu'utiles comme indicateurs de maturité processus, ne garantissent pas l'absence de vulnérabilités techniques dans les outils RMM déployés.

L'audit technique des accès MSP consiste à inventorier tous les agents RMM présents sur les endpoints de l'organisation cliente, à vérifier que chaque agent correspond à un MSP contractuellement autorisé et à un service défini, et à confirmer que les communications des agents RMM vers l'infrastructure MSP transitent par des canaux chiffrés et journalisés. Les EDR modernes permettent de détecter automatiquement la présence d'agents RMM et de les classer selon des listes d'agents autorisés et non autorisés. Un agent RMM inconnu découvert sur un endpoint d'un OIV français constitue un incident de sécurité potentiel à investiguer immédiatement, car l'installation d'agents RMM non autorisés est une technique courante des attaquants pour établir une persistance discrète (living-off-the-land avec les outils RMM légitimes).

HashiCorp Vault et gestion des secrets CI/CD

HashiCorp Vault est la solution de référence pour la gestion centralisée des secrets dans les environnements CI/CD modernes. Contrairement au stockage de secrets dans les variables d'environnement des plateformes CI/CD (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials) qui sont des secrets statiques à longue durée de vie, Vault génère des credentials dynamiques à courte durée de vie pour les services supportés (AWS IAM roles temporaires, certificats TLS, credentials base de données Postgres/MySQL générés à la demande et révoqués automatiquement après usage). Cette rotation automatique des credentials élimine les risques associés aux credentials statiques volés : un credential de base de données généré par Vault et valide 1 heure ne peut pas être réutilisé par un attaquant qui l'a exfiltré après son expiration.

L'intégration de HashiCorp Vault dans les pipelines CI/CD s'effectue via le Vault Agent (sidecar qui récupère les secrets de Vault et les écrit dans des fichiers ou variables d'environnement temporaires) ou via les APIs REST Vault directement depuis les scripts de pipeline avec authentification via des tokens d'authentification spécifiques au pipeline (AppRole authentication pour les systèmes non-cloud, ou JWT/OIDC authentication pour les runners GitHub Actions ou GitLab CI qui obtiennent un token OIDC de leur plateforme). La configuration de Vault avec des politiques d'accès granulaires par pipeline et par environnement (le pipeline de déploiement staging ne peut accéder qu'aux secrets staging, pas aux secrets production) crée une séparation des accès aux secrets qui limite l'impact d'un pipeline CI/CD compromis au seul environnement ciblé par ce pipeline.

Sécurité des postes développeurs en télétravail

La généralisation du télétravail a transformé les postes des développeurs en points d'entrée critiques dans les réseaux d'entreprise. Un développeur travaillant depuis son domicile avec un poste non sécurisé peut connecter son client VPN d'entreprise depuis un réseau WiFi domestique potentiellement compromis, laisser ses fenêtres de terminal et d'IDE visibles à distance via des outils de partage d'écran, ou utiliser son poste personnel pour des activités risquées (jeux, téléchargements, sites non sécurisés) avant de basculer vers des activités professionnelles sensibles. Les politiques de sécurité des postes développeurs doivent couvrir : le chiffrement intégral du disque (BitLocker Windows ou FileVault macOS), le verrouillage automatique après 5 minutes d'inactivité, l'interdiction de transférer du code source sur des services cloud personnels (Google Drive, Dropbox personnels), et l'installation d'un EDR sur tous les postes de développeurs.

Les solutions de DLP (Data Loss Prevention) adaptées aux environnements de développement permettent de détecter et bloquer les tentatives d'exfiltration de code source vers des destinations non autorisées (clés USB personnelles, uploads vers des services cloud non approuvés, envoi par email personnel). Microsoft Purview Information Protection avec la classification automatique du code source (détection des fichiers .py, .js, .java, .go, .rs contenant des patterns de credentials ou d'algorithmes propriétaires) permet d'appliquer des protections automatiques sur le code source sensible identifié. Notre service de audit de sécurité Microsoft 365 inclut l'évaluation des politiques DLP pour les environnements de développement et la configuration des protections adaptées aux postes développeurs travaillant en télétravail.

Jenkins CVE-2024-23897 : lecture de fichiers arbitraires

La vulnérabilité CVE-2024-23897 dans Jenkins (versions LTS 2.441 et antérieures, versions 2.426.2 et antérieures) est une Local File Inclusion (LFI) dans le parser de la CLI Jenkins qui permet à des utilisateurs non authentifiés de lire des fichiers arbitraires sur le serveur Jenkins, incluant les fichiers de configuration contenant des credentials, les clés secrètes Jenkins, et les fichiers de configuration des pipelines avec les secrets de déploiement. La vulnérabilité exploite le traitement des arguments de la CLI Jenkins qui peut être trompé pour lire le contenu d'un fichier plutôt qu'une chaîne de caractères, via une syntaxe spéciale avec le caractère arobase. Dans certaines configurations Jenkins, cette LFI peut être escaladée en RCE via la désérialisation de fichiers de configuration malveillants lus depuis le filesystem. Le CERT-FR a émis un bulletin d'alerte dans les heures suivant la publication du CVE, recommandant la mise à jour immédiate ou la désactivation de l'accès CLI Jenkins depuis Internet.

La correction de CVE-2024-23897 nécessitait la mise à jour vers Jenkins LTS 2.442 ou Jenkins 2.426.3, ou la désactivation de la CLI Jenkins via la configuration de sécurité (Manage Jenkins > Security > CLI over Remoting : Disable). Les signes d'exploitation active de cette vulnérabilité à rechercher dans les logs Jenkins incluent des requêtes CLI avec des arguments commençant par @/ (indicateur de l'exploitation de la LFI), des connexions CLI depuis des adresses IP non reconnues, et des accès répétés au fichier secrets/master.key ou credentials.xml de Jenkins. La compromission de Jenkins est particulièrement grave dans les environnements où Jenkins dispose de credentials de déploiement vers des environnements de production car l'attaquant peut s'en servir pour déployer du code malveillant directement en production via les pipelines existants.

Packages npm et PyPI malveillants : supply chain CI/CD

Les attaques de supply chain via les registres de packages (npm, PyPI, Maven Central) sont en forte augmentation depuis 2023 et constituent une menace directe pour les pipelines CI/CD qui installent automatiquement des packages lors des builds. Les techniques utilisées incluent le typosquatting (packages dont les noms ressemblent à des packages populaires : cross-env vs crossenv), le dependency confusion (packages publics avec le même nom que des packages privés d'entreprise mais avec un numéro de version supérieur), et la compromission de comptes mainteneurs (accès au compte npm d'un mainteneur légitime pour injecter du code malveillant dans une release du package). En 2024, plusieurs packages npm populaires avec des millions de téléchargements hebdomadaires ont été compromis via la prise de contrôle de comptes de mainteneurs dont les tokens npm avaient été volés.

La mitigation des risques de supply chain npm/PyPI dans les pipelines CI/CD passe par : l'utilisation de fichiers de lock (package-lock.json avec hash SHA512 pour npm, requirements.txt avec hashes pour pip) qui fixent les versions exactes et vérifient l'intégrité de chaque package téléchargé, la configuration d'un registre de packages privé (Artifactory, Nexus, AWS CodeArtifact) qui proxifie les registres publics tout en permettant la revue et l'approbation des packages avant leur utilisation, et l'utilisation de Socket Security ou Snyk Open Source qui analysent les comportements suspects des packages installés (accès réseau au démarrage, accès aux variables d'environnement, scripts postinstall suspects). Ces contrôles sont particulièrement importants pour les pipelines CI/CD qui s'exécutent avec des permissions élevées et ont accès aux secrets de déploiement cloud.

Zero Trust pour les environnements de développement

L'application des principes Zero Trust aux environnements de développement est une évolution récente mais nécessaire face à la multiplication des attaques ciblant les postes des développeurs et les pipelines CI/CD. Les postes de développeurs sont des cibles particulièrement précieuses : ils contiennent du code source propriétaire, des credentials cloud (profil AWS CLI, fichiers kubeconfig), des tokens d'accès GitHub/GitLab, des clés SSH de connexion aux serveurs, et des fichiers de configuration d'applications contenant des connexions de bases de données de développement. Une compromission d'un poste développeur peut offrir à l'attaquant un accès direct aux dépôts de code source, aux clusters Kubernetes de développement, et potentiellement à des environnements de staging ou de production via des scripts de déploiement stockés localement.

Les contrôles Zero Trust spécifiques aux environnements de développement incluent : la séparation des credentials de développement et de production (credentials cloud de développement avec permissions limitées, credentials de production uniquement accessibles via des systèmes d'accès just-in-time comme AWS IAM Identity Center avec durée limitée), la segmentation réseau des postes développeurs (les postes développeurs ne doivent pas avoir accès direct aux réseaux de production mais uniquement via des bastions ou des VPN avec journalisation), et l'utilisation d'environnements de développement cloud (GitHub Codespaces, AWS Cloud9, JetBrains Space) qui isolent l'environnement de développement du poste physique du développeur, limitant l'impact d'une compromission du poste local. Notre diagnostic NIS 2 évalue la sécurité des environnements de développement dans le cadre de l'analyse des risques de supply chain.

Veille CERT-FR et ANSSI : flux d'alertes CVE en temps réel

La veille des bulletins de sécurité CERT-FR et ANSSI est le mécanisme de premier niveau pour être informé des nouvelles vulnérabilités critiques affectant les logiciels utilisés par votre organisation. Le CERT-FR publie des avis de sécurité (CERT-FR/AVI) pour les vulnérabilités importantes et des alertes (CERT-FR/ALE) pour les vulnérabilités critiques activement exploitées dans la nature, disponibles sur le site du CERT-FR et via des flux RSS. En 2024-2025, le CERT-FR a émis des alertes d'urgence spécifiques pour CVE-2024-1709 (ScreenConnect), CVE-2024-27198 (TeamCity), et plusieurs vulnérabilités GitLab critiques, recommandant des actions immédiates dans les 24 à 48 heures. L'abonnement aux alertes email CERT-FR et ANSSI est gratuit et devrait être un prérequis pour tout RSSI d'organisation soumise à NIS 2.

Au-delà du CERT-FR, les sources de veille CVE complémentaires pour les équipes de sécurité françaises incluent : le National Vulnerability Database (NVD) du NIST (nvd.nist.gov) qui publie les CVEs avec leurs scores CVSS en quelques heures après leur assignment, les bulletins de sécurité des éditeurs (ConnectWise, JetBrains, GitLab, GitHub, HashiCorp) via leurs pages de sécurité dédiées et leurs flux RSS, les fils Twitter/X des chercheurs en sécurité et des équipes de Threat Intelligence (Rapid7, Huntress, GreyNoise) qui publient souvent les POCs et les IoCs avant les bulletins officiels, et les plateformes de Threat Intelligence payantes (Crowdstrike, Mandiant, Recorded Future) qui fournissent du contexte attribué sur l'exploitation active des CVEs par des groupes APT. L'automatisation de cette veille via un outil de Threat Intelligence Management (TIM) ou un SIEM avec des connecteurs de flux CTI permet de corréler automatiquement les nouvelles CVEs avec l'inventaire des logiciels détectés dans l'organisation.

Questions fréquentes sur les zero-days RMM et IDE

Comment savoir si mon ScreenConnect ou TeamViewer a été compromis via CVE-2024-1709 ?

Les indicateurs de compromission post-CVE-2024-1709 incluent : la présence de nouveaux comptes administrateurs ScreenConnect créés récemment que vous ne reconnaissez pas, des sessions ScreenConnect actives ou des historiques de session vers des systèmes clients pendant des plages horaires inhabituelles (nuit, week-end), des installations de nouveaux agents ou logiciels sur les endpoints clients via ScreenConnect que vous n'avez pas initiées, et la présence d'outils d'attaque (Cobalt Strike, Mimikatz, outils de compression) dans les répertoires temporaires des endpoints. L'audit des logs ScreenConnect et des journaux EDR des endpoints clients est la méthode recommandée pour confirmer ou infirmer une compromission.

Faut-il interdire les outils RMM dans les environnements sensibles ?

Non — les outils RMM sont indispensables pour la maintenance opérationnelle des parcs informatiques, particulièrement avec la généralisation du télétravail. La bonne pratique est de contrôler strictement leur accès (VPN + MFA), de maintenir un inventaire des agents RMM autorisés, de surveiller leurs usages, et de patcher en urgence lors de CVEs critiques. L'interdiction totale des RMM forcerait des alternatives moins sécurisées et moins auditables. L'ANSSI recommande de "maîtriser et contrôler les accès de télémaintenance" plutôt que de les interdire, dans ses guides de sécurisation des systèmes d'information.

Les IDE IA comme Cursor envoient-ils mon code à des serveurs tiers ?

Oui, par défaut, les fonctionnalités de complétion et d'agent IA de Cursor, Windsurf, et GitHub Copilot envoient des extraits du code ouvert dans l'IDE à des APIs cloud (Anthropic, OpenAI, GitHub) pour générer les suggestions. La quantité de contexte envoyé dépend de la fonctionnalité utilisée — la complétion en ligne envoie quelques lignes de contexte, tandis que les agents IA peuvent envoyer des fichiers entiers ou même des dépôts entiers. Pour les organisations avec des exigences de confidentialité du code source, les offres entreprise avec des engagements de non-utilisation pour l'entraînement et des options on-premise sont disponibles chez la plupart des éditeurs.

Comment auditer rapidement la sécurité de mes GitHub Actions ?

L'outil zizmor (disponible sur GitHub) analyse automatiquement tous les workflows GitHub Actions d'un dépôt ou d'une organisation pour détecter les configurations dangereuses : utilisation d'actions sans pin SHA, workflows déclenchés sur pull_request_target avec checkout du code de la PR, secrets exposés dans les logs via echo ou des commandes de debug. L'outil StepSecurity Harden-Runner peut être ajouté comme première étape de chaque workflow pour auditer les appels réseau effectués pendant l'exécution et bloquer les connexions vers des destinations non autorisées, détectant ainsi les exfiltrations de secrets depuis les pipelines.

Quel est le délai réglementaire NIS 2 pour patcher une CVE critique dans un outil RMM ?

La directive NIS 2 ne fixe pas de délai de patch explicite pour les CVEs, mais exige des politiques de gestion des risques et des vulnérabilités définies et respectées par les entités essentielles et importantes. La pratique recommandée par l'ANSSI et le CERT-FR est de patcher les vulnérabilités critiques (CVSS >= 9.0) dans les systèmes exposés sur Internet dans les 24 à 72 heures suivant la disponibilité du patch. En cas d'impossibilité de patcher immédiatement, des mesures compensatoires documentées (isolation réseau, restrictions d'accès supplémentaires) doivent être mises en place et documentées pour démontrer la diligence raisonnable lors d'un éventuel audit de conformité NIS 2.

Comment un MSP peut-il démontrer à ses clients que ses outils RMM sont sécurisés ?

Un MSP peut démontrer sa maturité de sécurité RMM via : la certification ISO 27001 qui couvre les processus de gestion des accès à distance, les rapports de tests d'intrusion réguliers incluant les systèmes RMM, la documentation des procédures de patch management d'urgence avec SLAs définis, la fourniture de journaux d'audit détaillés de toutes les connexions RMM vers les systèmes clients (qui s'est connecté, quand, depuis quelle IP, quelles actions ont été effectuées), et la signature de clauses contractuelles spécifiques sur la sécurité des accès à distance. Ces éléments sont de plus en plus demandés par les clients sous NIS 2 dans leurs audits de sécurité des fournisseurs critiques.

Accompagnement : veille CVE et réponse aux incidents RMM/IDE

La gestion proactive des vulnérabilités zero-day et N-day dans les outils RMM et CI/CD requiert une veille de sécurité permanente, un processus de patch d'urgence documenté, et une capacité de réponse rapide aux incidents. Notre service de RSSI externalisé inclut la veille des bulletins CERT-FR et ANSSI, l'évaluation de l'exposition de votre infrastructure aux nouvelles CVEs critiques, et la coordination des patchs d'urgence avec vos équipes techniques dans les délais requis par NIS 2.

Pour évaluer votre exposition actuelle aux risques RMM et CI/CD, démarrez par notre diagnostic NIS 2 qui cartographie vos outils d'accès à distance et vos pipelines CI/CD dans le cadre de l'analyse de vos surfaces d'attaque. Notre service de pentest peut simuler des attaques via vos outils RMM et tester la résistance de vos pipelines CI/CD aux attaques d'injection et de supply chain, fournissant un rapport d'exploitation documenté avec des recommandations de remédiation priorisées.