Technologies

Développeurs : nouvelle cible préférée des cybercriminels

Un plateau hébergeant des équipes de développement. La généralisation des assistants de codage à base de GenAI accroit la surface d’attaque pour les assaillants. (Photo : Alex Kotliarskyi/Unsplash)

Avec la généralisation des pratiques DevOps, les cybercriminels considèrent de plus en plus les développeurs comme des cibles privilégiées, créant des risques systémiques pour les RSSI. Les devs aussi prisés des cyberattaquants que les admins système ?

PublicitéLes menaces qui pèsent sur les développeurs en entreprise se multiplient et se diversifient, obligeant les responsables de la sécurité à adapter leurs défenses. Car les attaquants ciblent de plus en plus les outils, les accès et les canaux de communication des développeurs, plutôt que de se contenter d'exploiter des failles de sécurité dans les applications. Ces menaces combinent compromission technique (packages malveillants, détournement du pipeline de développement, etc.) et ingénierie sociale, ainsi que des attaques pilotées par l'IA.

« Les attaquants ne cherchent plus seulement à s'introduire dans le réseau ; ils cherchent à s'infiltrer dans le workflow », explique Chris Wood, expert en sécurité des applications chez Immersive, une entreprise spécialisée en cybersécurité. « En compromettant les outils auxquels les développeurs font confiance, comme les extensions et les registres de packages, ils peuvent saboter le système avant même qu'une seule ligne de code ne soit écrite. » Les jetons, clés d'API, identifiants cloud et secrets CI/CD détenus par les développeurs de logiciels leur confèrent un accès bien plus étendu qu'un compte utilisateur classique, faisant d'eux des cibles privilégiées pour les cybercriminels. « Ils détiennent les clés du royaume, un accès privilégié au code source et à l'infrastructure cloud, ce qui en fait une cible de grande valeur », ajoute Chris Wood.

Selon les experts, la menace qui pèse sur les développeurs de logiciels se divise en plusieurs catégories : extensions, plugins IDE et outils malveillants ; attaques ciblant la supply chain et les dépendances ; vol d'identifiants et compromission de l'environnement ; ingénierie sociale ; et, enfin, risques liés à l'IA dans les workflows de développement logiciel.

Utilitaires malveillants pour empoisonner l'écosystème

Darren Meyer, expert en recherche de sécurité chez Checkmarx, une entreprise spécialisée dans la sécurité des applications, considère la plupart des attaques visant les développeurs comme « peu sophistiquées » et non ciblées. Par exemple, des attaquants déposent des paquets open source infectés sur des domaines en typosquatting pour inciter les développeurs à installer des versions malveillantes d'utilitaires populaires.

Mais ces attaques à l'aveuglette ne représentent qu'une partie du problème. Des attaques plus ciblées sont également à l'oeuvre, comme le ver Shai-Hulud qui a ciblé GitHub et d'autres plateformes de développement logiciel, une récente attaque contre le paquet npm Chalk et des tentatives de compromission de l'écosystème de plugins de Visual Studio Code, prévient Darren Meyer.

Cet avertissement concernant les logiciels libres corrompus est corroboré par une étude récente de la société spécialisée dans le DevSecOps Sonatype, qui a identifié 1,233 million de packages logiciels malveillants. Les composants vulnérables connus représentent également un risque majeur. Quatre ans après la correction de la faille, les versions de Log4j vulnérables à la faille Log4Shell ont été téléchargées 42 millions de fois l'année dernière, selon le dernier rapport de Sonatype sur l'état de la supply chain logicielle.

PublicitéVol d'identifiants et compromission de l'environnement

Les attaquants ne se contentent pas de rechercher des failles dans le code ; ils visent aussi l'accès aux environnements de développement logiciel. Les failles de sécurité courantes, telles que les comptes de service bénéficiant de privilèges non justifiés, les jetons à longue durée de vie et les pipelines mal configurés, offrent une porte d'entrée facile pour s'introduire illicitement dans des environnements de développement sensibles. « Les identifiants d'accès mal stockés constituent une cible facile, même pour les acteurs malveillants les plus novices », explique Crystal Morin, stratège senior en cybersécurité chez Sysdig, fournisseur de solutions de sécurité et d'observabilité cloud-native.

Menaces internes

Les attaquants cherchent également à infiltrer les entreprises ciblées en se faisant passer pour des prestataires de développement logiciel ou des indépendants. Les arnaques aux faux travailleurs, une tactique courante employée par les acteurs malveillants nord-coréens, consistent à utiliser des personnes techniquement compétentes, dotées d'une fausse identité, qui emploient des techniques d'ingénierie sociale pour tromper leurs victimes et les inciter à les embaucher. Une fois infiltrées, ces taupes volent des données et des informations sensibles qui servent de garantie pour des extorsions, entre autres stratagèmes.

« Nous avons également constaté que des acteurs malveillants se font passer pour des mainteneurs et intègrent du code malveillant à des projets open source afin d'infecter les utilisateurs de paquets populaires, comme ce fut le cas avec la porte dérobée XZ Utils (CVE-2024-3094) », explique Crystal Morin de Sysdig.

Une dépendance compromise, telle qu'une bibliothèque logicielle partagée, peut contaminer le code de tout développeur qui l'utilise, engendrant ainsi un risque majeur pour la supply chain logicielle. Gavin Millard, vice-président de l'intelligence sur la menace chez Tenable, une société spécialisée dans la gestion de l'exposition aux risques, affirme que les menaces provenant de la supply chain logicielle ont supplanté les exploits pour devenir le principal risque systémique en matière de cybersécurité.

La supply chain ou le bingo de l'attaquant

Les risques liés à la supply chain signifient que la surface d'attaque s'est étendue au-delà des vulnérabilités traditionnelles et du vol d'identifiants, incluant désormais le détournement des comptes de mainteneurs sur des plateformes telles que npm ou PyPI. « Comme l'ont démontré les récents détournements de S1ngularity et de mainteneurs npm, une simple mise à jour malveillante d'une bibliothèque courante peut avoir des conséquences plus graves en quelques minutes qu'une année d'envoi de messages d'hameçonnage ciblés ou de recherche de systèmes vulnérables sur Internet », souligne Gavin Millard.

Car l'exploitation de la supply chain constitue un véritable atout pour tout attaquant. « Pour un utilisateur lambda, une faille de sécurité se traduit par une fuite de données, mais pour un développeur, c'est un piège qui peut infecter toutes ses applications et tous les utilisateurs de ses produits », dit Gavin Millard.

Les inquiétudes concernant la résilience des supply chain face aux cyberattaques vont croissantes. Le dernier rapport annuel du Forum économique mondial sur les perspectives de la cybersécurité mondiale révèle que 65 % des grandes entreprises considèrent les vulnérabilités liées aux tiers et à la chaîne d'approvisionnement comme leur principal défi, contre 54 % en 2025.

« Les développeurs utilisent couramment du code provenant de registres publics, installent des dépendances à des tiers, accordent des autorisations étendues à l'automatisation et publient des artefacts auxquels les systèmes en aval font implicitement confiance », explique Christopher Jess, responsable R&D chez Black Duck, une entreprise spécialisée dans la sécurité des applications. Des pratiques rapidement mises à profit par les attaquants qui s'infiltrent au plus bas niveau dans la chaîne d'outils de développement. « Ils empoisonnent les packages open source, pratiquent le typosquatting sur les bibliothèques populaires, publient des extensions malveillantes sur les marketplaces des plateformes de développement intégré et ciblent les systèmes de compilation, où une seule faille de sécurité peut affecter l'ensemble de l'environnement », énumère Christopher Jess.

Modèle de menace hybride

Le responsable R&D note que les attaquants combinent désormais la compromission technique et l'ingénierie sociale pour renforcer l'efficacité de leurs attaques. « Un package malveillant peut contenir des portes dérobées subtiles, puis être amplifié par des techniques de communication convaincantes : faux messages de responsables de projet, demandes de fusion urgentes de correctifs de sécurité, ou usurpation d'identité de collaborateurs de confiance pour accélérer l'adoption », explique Christopher Jess.

Et, selon lui, l'IA accroît l'ampleur et la précision de ces attaques : « le phishing et le prétexte associé peuvent être plus contextuels (correspondance des noms de dépôts, de l'historique des commits et des rôles dans les équipes), et les assallants peuvent générer des modifications de code ou une documentation plausible afin de réduire les soupçons lors des revues », ajoute-t-il.

Développement assisté par l'IA : une surface d'attaque accrue

Le développement assisté par l'IA et le 'vibe coding' augmentent l'exposition aux risques, notamment parce que ce code est souvent généré rapidement, sans tests, documentation ni traçabilité appropriée. Jamie Beckland, directeur des produits chez APIContext, société spécialisée en cybersécurité, met en garde contre un nouveau risque lié à l'adoption des agents d'IA et des serveurs MCP (Model Context Protocol) par les équipes de développement logiciel : la prolifération d'outils aux permissions opaques.

« Les serveurs MCP peuvent être modifiés par l'ajout d'outils conçus pour exfiltrer des données depuis les API internes, data stores ou systèmes SaaS, détaille Jamie Beckland. Le risque ne se limite pas au modèle LLM, il concerne également la surface d'attaque de l'outillage et la portée de celui-ci. Il est essentiel de surveiller les serveurs MCP afin de détecter toute modification de l'infrastructure des outils et des droits d'accès aux données, et ainsi vérifier les changements apportés aux outils et aux requêtes. »

Pieter Danhieux, Pdg et cofondateur de Secure Code Warrior, une entreprise de formation en cybersécurité, ajoute que les serveurs MCP et les agents d'IA constituent un terrain fertile pour les attaquants, car il est facile d'y « introduire intentionnellement un prompt non sécurisé ou d'insérer du code malveillant enrichi par l'IA. De plus, nous avons constaté que les acteurs malveillants exploitent l'identité des utilisateurs de nouvelles manières, notamment grâce à la vulnérabilité du "confused deputy" (reposant sur des failles dans la gestion de l'identité dans des systèmes multi-agents, NDLR), où ils trompent les agents d'IA pour qu'ils effectuent des actions non autorisées au nom de l'utilisateur ».

L'analyse de 37 000 recommandations de LLM réalisée par Sonatype montre que GPT-5 a halluciné 27,8% des versions de composants qu'il préconise et a même suggéré de véritables logiciels malveillants dans certains cas, une statistique qui souligne la nécessité d'une revue de code humaine. Selon BaxBench, 62 % des solutions suggérées, même par les meilleurs LLM, sont incorrectes ou présentent une faille de sécurité, montrant que la GenAI ne peut pas encore générer du code prêt à être déployé en production. Les RSSI doivent « cesser de se focaliser sur les vulnérabilités individuelles et commencer à maîtriser leur exposition globale, y compris la provenance des bibliothèques partagées automatiquement importées par les assistants de code IA », résume Gavin Millard de Tenable.

Indispensables contre-mesures

Pour les RSSI, le renforcement des environnements de développement logiciel exige une combinaison de contrôles techniques, de sensibilisation des équipes à la sécurité et de création d'une culture de la sécurité.

Des contrôles d'identité plus stricts, une gestion rigoureuse des identifiants et un accès aux données basé sur le principe de moindre privilège contribuent à une plus grande dans les pratiques de développement logiciel. « Parmi les solutions éprouvées à ces problèmes, citons l'isolation des espaces de travail dans des conteneurs, la centralisation de la gestion des images et des secrets, ainsi que la mise en place d'audits réguliers et la journalisation des procédures. Toutes ces mesures permettent de réduire efficacement les risques », dit Eric Paulsen, directeur technique EMEA chez Coder, fournisseur de plateformes de développement logiciel.

Selon David Sugden, directeur de l'ingénierie chez Axiologik, cabinet de conseil en transformation numérique, la meilleure pratique a toujours consisté à lier les actions dans les workflows à des hachages SHA (Secure Hash Algorithm) immuables stockés sur des modules matériels inviolables. « De même, les listes blanches, l'analyse des secrets et l'analyse de la composition logicielle constituent des fondements du DevSecOps et renforcent la protection, ajoute-t-il. Le contrôle des accès directs aux dépendances externes offre une protection contre les logiciels malveillants, et empêche le téléchargement de packages anciens et non sécurisés. »

Michael Burch, expert en sécurité des applications chez Security Journey, spécialisée dans la formation en cybersécurité, souligne l'importance d'offrir aux développeurs de logiciels une formation pratique et continue. « Les développeurs ont besoin d'exercices réalistes qui illustrent l'impact des actions. Il faut leur permettre de constater les défaillances des systèmes et leur donner les moyens de résoudre les problèmes par eux-mêmes », conseille-t-il.