Le développement moderne repose aujourd’hui sur un immense écosystème open source. Frameworks JavaScript, packages npm, modules Python, images Docker, pipelines CI/CD, outils d’automatisation ou bibliothèques de sécurité : une grande partie des applications actuelles est désormais construite à partir de composants développés par des tiers.
Et dans la majorité des cas, ces composants sont intégrés en quelques secondes seulement.
npm install nomPackageDerrière cette commande pourtant anodine se cache parfois une chaîne entière de dépendances téléchargées automatiquement.
Une application moderne ne contient plus uniquement le code écrit par son équipe de développement. Elle embarque souvent des centaines, voire des milliers de composants logiciels externes.
Certaines estimations considèrent aujourd’hui que 70 à 80% d’une application moderne repose sur du code que l’entreprise n’a pas développé elle-même.
C’est précisément ce qui rend les attaques “supply-chain” dangereuses.
La supply-chain logicielle : l’autoroute idéale des attaques modernes
Pendant longtemps, les entreprises concentraient leurs efforts de sécurité principalement sur leur propre code applicatif. Aujourd’hui, les attaquants ont compris qu’il était souvent bien plus efficace de viser directement la chaîne logicielle utilisée par des milliers de projets.
Plutôt que d’attaquer une entreprise en particulier, ils ciblent désormais les packages open source, les registries, les pipelines CI/CD, les outils de build, les images Docker ou encore les plateformes de publication.
Le problème dépasse largement le simple “package vulnérable”.
La supply-chain logicielle, c’est tout ce qui permet de construire une application : comment le package est créé, publié, récupéré, intégré dans un pipeline puis finalement exécuté dans une infrastructure de production.
Aujourd’hui, cette chaîne complète est devenue une cible majeure.
L’OWASP (Open Worldwide Application Security Project) a d’ailleurs fortement remonté les risques liés à la supply-chain logicielle dans ses principales catégories de menaces de sécurité. Et ce n’est probablement que le début !
Vos dépendances ne viennent jamais seules
Lorsqu’un développeur ajoute une dépendance à un projet Node.js ou Python, il pense généralement récupérer une simple bibliothèque.
En réalité, cette dépendance peut elle-même dépendre d’autres dépendances, qui téléchargent à leur tour d’autres composants. C’est ce que l’on appelle les dépendances transitives.
Dans l’écosystème Node.js, des commandes simples comme
npm lsounpm outdatedpermettent déjà de visualiser les dépendances réellement installées et les versions obsolètes présentes dans un projet.
Dans certains projets modernes, une simple application web peut ainsi embarquer plusieurs milliers de packages réels. Parmi eux, certains ne sont plus maintenus, d’autres sont très peu surveillés, certains sont utilisés par des millions de projets, et d’autres peuvent devenir malveillants du jour au lendemain.
Le plus problématique, c’est que beaucoup de développeurs n’ont plus réellement de visibilité sur l’ensemble des composants qui composent leur propre application.
EventStream : la confiance compromise
L’un des cas les plus connus reste l’affaire EventStream.
Le package était populaire, utilisé dans de nombreux projets et considéré comme fiable. Puis un jour, le mainteneur transfère simplement la propriété du package à une autre personne.
Le transfert de propriété sur certaines plateformes comme GitHub est extrêmement simple. Quelques modifications plus tard, du code malveillant est discrètement ajouté dans une nouvelle version du package.
Résultat : les développeurs mettant à jour leur dépendance téléchargent automatiquement le code malveillant dans leurs applications.
Cette attaque a marqué un tournant important parce qu’elle a montré qu’une dépendance populaire et largement utilisée pouvait devenir une porte d’entrée extrêmement efficace.
Et surtout, le problème ne venait pas d’une faille technique complexe, mais simplement de la confiance accordée à une chaîne logicielle devenue beaucoup trop opaque.
Une simple faute de frappe peut suffire !
Toutes les attaques supply-chain ne reposent pas forcément sur des scénarios sophistiqués. Parfois, une simple erreur humaine suffit.
Un développeur tape rapidement le nom d’un package dans son terminal, oublie une lettre, inverse un caractère ou remplace un zéro par un “O”. Au lieu d’installer le vrai package, il télécharge alors une version malveillante volontairement publiée pour ressembler à la bibliothèque officielle.
Cette technique porte un nom : le typosquatting.
Des cas similaires ont déjà touché des dépendances très populaires de l’écosystème JavaScript et Python. Le problème devient particulièrement dangereux dans des environnements automatisés où les installations de dépendances sont déclenchées directement dans des pipelines CI/CD.
Les pipelines CI/CD sont devenus des cibles
L’objectif d’un package malveillant n’est pas toujours de compromettre directement l’application finale. Dans certains cas, la cible réelle est l’environnement de build lui-même.
Un morceau de code injecté dans une dépendance peut récupérer des variables d’environnement, voler des clés API, exfiltrer des tokens ou accéder à des secrets CI/CD.
Et comme ces dépendances sont souvent exécutées automatiquement pendant les phases de build, les conséquences peuvent devenir extrêmement importantes.
Un simple package compromis peut parfois donner accès à des registres privés, des dépôts Git, des environnements cloud ou même des infrastructures de production entières.
Des outils intégrés comme
npm auditpermettent également d’identifier certaines vulnérabilités connues directement dans les dépendances utilisées par une application.
Les outils de sécurité dans le viseur
Le plus inquiétant, c’est que même les outils de sécurité eux-mêmes ne sont pas épargnés. Des attaques récentes ont notamment touché certains outils largement utilisés pour analyser les vulnérabilités ou sécuriser des infrastructures cloud.
Autrement dit, les logiciels censés protéger les applications dépendent eux aussi d’un très grand nombre de composants externes. Cela montre à quel point la confiance dans la chaîne logicielle moderne devient complexe.
Aujourd’hui, la question n’est plus seulement : “Mon application est-elle sécurisée ?”
Mais aussi : “Puis-je réellement faire confiance à tout ce qui permet de construire mon application ?”
L’IA aussi devient une cible
Avec l’explosion récente des outils liés à l’intelligence artificielle, de nouveaux risques apparaissent également. Certains modèles ou packages liés à l’IA ont déjà été ciblés via des dépendances malveillantes ou des modules empoisonnés.
L’objectif peut être multiple :
- récupération de données
- compromission d’environnements d’apprentissage
- vol d’informations
- exécution de code malveillant.
Là encore, le problème reste le même. Les développeurs et les entreprises dépendent de plus en plus de composants externes qu’ils ne maîtrisent pas complètement.
Les SBOM pour retrouver de la visibilité
Face à ces nouveaux enjeux, de nombreuses entreprises commencent à déployer des SBOM. SBOM signifie Software Bill Of Materials.
Le principe est relativement simple : générer un inventaire détaillé des composants logiciels présents dans une application. Un SBOM permet notamment de savoir quelles dépendances sont utilisées, quelles versions sont installées, quelles applications sont concernées par une faille critique ou encore quelles bibliothèques deviennent obsolètes.
Des standards comme CycloneDX ou SPDX prennent progressivement une place importante dans les environnements DevSecOps modernes.
L’objectif n’est pas uniquement de détecter des vulnérabilités. Le véritable enjeu est surtout de retrouver de la visibilité sur des applications devenues extrêmement complexes.
Aujourd’hui, plusieurs outils permettent de générer facilement ce type d’inventaire, notamment dans des projets Node.js, Python, Java ou Docker. Des solutions open source comme Syft, Trivy ou Dependency–Track sont de plus en plus utilisées pour analyser les dépendances et suivre les vulnérabilités connues dans le temps.
Concrètement, la logique est souvent la suivante :
- générer un SBOM du projet
- identifier les composants utilisés
- analyser les vulnérabilités connues
- puis surveiller les nouvelles failles au fil des mises à jour
Dans certains environnements, cette génération de SBOM est désormais directement intégrée dans les pipelines CI/CD afin de garder une vision continue des composants réellement déployés en production.
Même si ces pratiques étaient autrefois réservées aux grandes infrastructures ou aux environnements sensibles, elles deviennent progressivement accessibles et pertinentes pour la majorité des projets modernes.
La confiance devient un enjeu majeur
Le développement logiciel moderne ne consiste plus uniquement à écrire du code. Il faut désormais aussi sécuriser toute la chaîne qui permet de construire et déployer une application :
- dépendances
- pipelines CI/CD
- registries
- artefacts
- images Docker
- outils de build
- plateformes cloud
- infrastructures d’automatisation
La supply-chain logicielle est progressivement devenue l’un des sujets majeurs de cybersécurité moderne.
Et avec l’explosion de l’open source, du cloud et de l’automatisation, ce sujet devient désormais incontournable pour toutes les équipes techniques.
La sécurité des dépendances et de la chaîne logicielle devient aujourd’hui un véritable enjeu dans les infrastructures modernes, aussi bien pour les applications web que pour les plateformes cloud et les environnements d’hébergement.
Chez Easy-Hébergement, nous faisons évoluer régulièrement nos infrastructures et nos plateformes afin de proposer des environnements d’hébergement fiables, modernes et adaptés aux enjeux actuels du web, du cloud et de la sécurité.
Découvrez nos solutions d’hébergement web, cloud et infrastructures : https://www.easy-hebergement.fr/
Pour celles et ceux qui souhaitent approfondir le sujet, une conférence complète de 40 minutes sur les attaques supply-chain : https://www.youtube.com/watch?v=X5aafFca39c
