Les principales vulnérabilités de la sécurité de la chaîne d’approvisionnement logicielle expliquées
Introduction : À quand remonte la dernière fois que vous avez audité les dépendances et les processus de build de votre logiciel ? La dure vérité est que chaque bibliothèque open-source que vous npm install, chaque image Docker que vous téléchargez, et chaque script de votre pipeline CI est un vecteur d'attaque potentiel. Le développement moderne repose fortement sur des composants externes et l'automatisation, ce qui a ouvert la voie à une nouvelle génération de menaces pour la sécurité de la chaîne d'approvisionnement logicielle. En fait, les attaques de la chaîne d'approvisionnement ont explosé – Sonatype rapporte avoir découvert plus de 700 000 paquets open-source malveillants depuis 2019. Et tout récemment, le compromis d'un seul compte de mainteneur npm a conduit à 18 paquets largement utilisés ayant été piégés par une porte dérobée avec des malwares, mettant en péril des milliards de téléchargements hebdomadaires. Ces incidents soulignent pourquoi les équipes de développement, les ingénieurs DevOps et les praticiens DevSecOps doivent se soucier de la sécurité de la chaîne d'approvisionnement logicielle plus que jamais.
Une « vulnérabilité de la chaîne logistique logicielle » désigne toute faiblesse dans les processus ou les composants qui entrent dans la création et la livraison de votre code, des paquets tiers aux outils de création et aux workflows CI/CD. Les pirates ont compris qu'ils pouvaient compromettre d'innombrables applications en aval en infectant un seul composant en amont. La suite de cet article présente neuf des sécurité de la chaîne d’approvisionnement logicielle les plus critiques et sécurité de la chaîne d’approvisionnement logicielle plus souvent négligées sécurité de la chaîne d’approvisionnement logicielle . Pour chacune d'entre elles, nous expliquerons son fonctionnement, comment elle peut se manifester dans des projets réels, les risques qu'elle présente et comment l'atténuer. Nous inclurons également des remarques Aikido pour illustrer comment les outils de sécurité modernes (tels que le scanner de dépendances, détection de secrets, SBOM et le scan CI/CD Aikido) aident à identifier ou à prévenir ces problèmes.
Les 9 principales vulnérabilités de la chaîne d'approvisionnement logicielle
1. Paquets de typosquatting malveillants
L'une des attaques de la chaîne d’approvisionnement les plus simples est typosquatting – où les attaquants téléchargent des paquets malveillants vers des registres (npm, PyPI, RubyGems, etc.) en utilisant des noms presque identiques aux bibliothèques populaires. L'objectif est de tromper les développeurs (ou leurs outils automatisés) pour qu'ils installent l'imposteur en tapant mal ou en identifiant incorrectement le nom du package. Par exemple, des acteurs malveillants ont usurpé l'identité de packages comme typescript-eslint sur npm avec des noms comme @typescript_eslinter/eslint, qui a cumulé des milliers de téléchargements avant d'être détecté. Ces packages contrefaits contiennent souvent des malwares cachés : ils peuvent exécuter un script post-installation qui dépose un cheval de Troie ou exfiltre des données. Dans un cas, un typosquat d'un formateur de code a silencieusement installé un exécutable malveillant (prettier.bat) qui persistait au démarrage de Windows.
Comment ça marche : Les attaquants observent les bibliothèques populaires et créent un package malveillant avec un nom qui est une faute d'orthographe courante ou une variante. Cela pourrait être aussi subtil qu'un trait d'union manquant (types-node vs la légitime @types/nodeou un namespace différent. Ils publient ces packages sur le dépôt public avec un numéro de version ou une description attrayante. Des développeurs peu méfiants pourraient faire une faute de frappe dans le nom ou choisir le mauvais package à la hâte, intégrant ainsi le code malveillant. Les scripts automatisés et les systèmes CI sont tout aussi vulnérables si le nom du package est incorrect, même d'un seul caractère.
Risques : Une fois installé, le package malveillant s'exécute avec les mêmes privilèges que la build de votre application. Il peut dérober des variables d'environnement (secrets), installer des backdoors ou télécharger des malwares de second stade. Dans les environnements d'entreprise, une seule dépendance compromise peut se propager à de nombreuses applications ou services. Ces attaques sont insidieuses car les développeurs ne réalisent souvent l'erreur qu'après que les dommages ont été causés. La confiance que nous accordons aux gestionnaires de packages peut être détournée pour exécuter du code sur les machines des développeurs ou les runners CI, ce qui peut entraîner le vol d'identifiants, l'exfiltration de données et la compromission de serveurs.
Atténuation : pour se prémunir contre le typosquatting, les développeurs doivent vérifier deux fois les noms des paquets et n'installer que des bibliothèques provenant de sources officielles ou vérifiées. Activez l'authentification à deux facteurs (2FA) sur les comptes de registre de paquets (pour empêcher les attaquants de créer des champs d'application ou des profils similaires). De nombreux écosystèmes proposent désormais la signature ou la vérification des paquets. Utilisez ces fonctionnalités pour garantir leur authenticité. L'intégration d'outils automatisés est également essentielle. Par exemple, un scanner de dépendances peut signaler les paquets suspects ou les noms qui ne correspondent pas aux bibliothèques officielles connues. L'utilisation d'une « liste blanche » de paquets approuvés ou d'identifiants d'URL de paquets (pURL) peut empêcher l'installation de paquets qui semblent corrects. Sensibilisez votre équipe à la nécessité d'être vigilante lors de l'ajout de nouvelles dépendances.
Le scanner de dépendances d'Aikido peut détecter automatiquement les packages malveillants connus et les variantes de typosquatting avant qu'ils n'atteignent votre build. Par exemple, le SafeChain cette fonctionnalité bloque les paquets tout nouveaux ou connus pour être malveillants, empêchant ainsi cette dangereuse npm install de réussir. En scannant le manifeste et les fichiers de verrouillage de votre projet, Aikido aide à garantir que react-router est bien le vrai React Router – et non un imposteur malveillant. Ce type de scan proactif et de politique (par exemple, exiger que les paquets aient un certain âge ou une certaine popularité) peut stopper les attaques de typosquatting dès le début, en gardant votre chaîne d'approvisionnement propre.
2. Confusion de dépendances (Mélanges de paquets internes et publics)
La confusion de dépendances, également connue sous le nom d'attaque par confusion d'espace de noms, est une exploitation astucieuse contre les organisations qui utilisent à la fois des paquets privés (internes) et publics. Elle tire parti de la manière dont les gestionnaires de paquets résolvent les noms : si le nom d'un paquet interne correspond accidentellement à celui d'un paquet du registre public, un attaquant peut publier un paquet public portant le même nom et une version supérieure afin de « semer la confusion » dans le résolveur. Résultat ? Votre système de compilation pourrait extraire le code de l'attaquant du registre public au lieu du paquet interne que vous aviez prévu. Ce vecteur d'attaque a été démontré de manière célèbre par le chercheur en sécurité Alex Birsan en 2021, lorsqu'il a piraté des dizaines de grandes entreprises technologiques (Apple, Microsoft, Tesla, etc.) en téléchargeant des paquets malveillants correspondant aux noms de projets internes de ces entreprises.
Comment cela se manifeste : Supposons que votre entreprise dispose d'un paquet npm interne appelé @acme/widget-core en version 1.3.0, hébergé sur un registre privé. Le package.json de votre projet demande @acme/widget-core. Si un attaquant publie @acme/widget-core version 9.9.9 sur npm (public) et que votre build n'est pas verrouillé à la source privée, le gestionnaire de paquets pourrait récupérer la version 9.9.9 du registre public (pensant qu'il s'agit d'une version plus récente). Le paquet malveillant pourrait contenir un script post-installation qui s'exécute automatiquement à l'installation, permettant l'exécution de code à distance dans votre environnement de build. Dans les pipelines CI/CD, c'est particulièrement dangereux : le code s'exécute sur des agents de build qui pourraient avoir accès à des variables d'environnement sensibles, au code source et aux clés de déploiement.
Risques : La confusion de dépendances peut entraîner une compromission immédiate de l'environnement de build ou de développement. La charge utile malveillante pourrait exfiltrer des secrets (clés API, jetons, identifiants) ou injecter des portes dérobées dans l'application construite sans que le code de votre dépôt ne change. Elle contourne efficacement la code review traditionnelle ou l'analyse des vulnérabilités de votre dépôt, car le code malveillant réside dans une dépendance que vous avez tirée à votre insu. L'impact peut être grave : les attaquants pourraient obtenir un mouvement latéral dans les réseaux de l'entreprise (si les serveurs de build sont compromis) ou insérer une logique malveillante dans les logiciels livrés aux clients. C'est une surface de menace répandue étant donné la fréquence des collisions de noms de paquets internes.
Atténuation : Prévenir la confusion de dépendances implique une combinaison de contrôles techniques et d'hygiène. Toujours définir explicitement la portée de vos packages privés et configurez vos gestionnaires de packages pour qu'ils préfèrent les registres privés pour certains espaces de noms. Les paramètres du gestionnaire de packages comme ceux de npm @acme:registry dans .npmrc ou les paramètres d'index de pip devraient être utilisés pour verrouiller les dépendances à la source prévue. Utilisez épinglage strict des versions et des lockfiles afin que même si une version supérieure apparaît ailleurs, votre build ne la prenne pas automatiquement. Surveillez les registres de packages publics pour toute fuite accidentelle de noms de vos packages internes (les attaquants les devinent souvent via des mentions dans des dépôts publics ou des fichiers de configuration). De nombreuses organisations utilisent désormais des dépôts d'artefacts comme proxy, de sorte que uniquement les packages approuvés sont récupérés. Cela crée une barrière où les packages inconnus (même si le nom correspond) ne seront pas intégrés. Enfin, des audits réguliers des configurations de dépendances et la génération d'un SBOM (Software Bill of Materials) peuvent aider à détecter si un package externe inattendu s'est introduit.
La plateforme Aikidoest équipée pour détecter les scénarios de confusion de dépendances. Par exemple, le scanner de dépendances Aikidocompare votre manifeste de paquets à des sources publiques et privées. S'il détecte un nom de dépendance qui existe sur npm/PyPI mais qui est censé être interne, il déclenche une alerte. Aikido également appliquer des politiques pour n'autoriser que certains registres ou contrôler les espaces de noms, garantissant ainsi que vos builds n'accèdent pas accidentellement à des sources non fiables. Grâce à SBOM , Aikido une visibilité précise sur la version et la source du package utilisé dans une compilation, ce qui facilite la détection et la prévention de l'introduction d'un package public errant dans une application interne. En bref, Aikido vous aider à vous assurer que ce que vous compilez correspond exactement à ce que vous aviez prévu, sans code surprise.
3. Bibliothèques détournées et Protestware (Mainteneurs compromis)
Toutes les attaques de la chaîne d’approvisionnement ne proviennent pas de nouveaux packages contrefaits – parfois des packages de confiance deviennent malveillants en raison de compromissions de comptes de mainteneurs ou de sabotage intentionnel. Lorsqu'un attaquant prend le contrôle d'un package légitime (par hameçonnage du mainteneur, vol d'identifiants ou exploitation de failles de sécurité), il peut publier une mise à jour troyanisée que les consommateurs téléchargent en pensant qu'il s'agit d'une nouvelle version normale. Cela s'est produit dans Septembre 2025, lorsqu'un responsable connu sous le nom de « qix » a été phishing et les pirates ont diffusé des mises à jour malveillantes vers 18 bibliothèques npm populaires, notamment debug, chalk, et ansi-regexCes bibliothèques ont enregistré collectivement des milliards de téléchargements hebdomadaires, ce qui signifie que l'impact de seulement deux heures de disponibilité du code malveillant a été énorme. Un autre scénario est «logiciel de protestation», où un responsable open source modifie intentionnellement sa bibliothèque (par exemple, pour afficher des messages politiques ou, pire encore, pour saboter les systèmes dans certains pays). Dans les deux cas, le paquet auquel vous faites confiance et que vous utilisez depuis des années peut soudainement devenir un arme contre vous.
Fonctionnement : Les attaquants ciblent les packages à fort impact – souvent ceux qui sont profondément imbriqués dans les arbres de dépendances, de sorte que les développeurs pourraient ne pas remarquer une mise à jour. Les tactiques courantes incluent le phishing des identifiants de connexion des mainteneurs (comme lors de l'incident npm ci-dessus) ou l'exploitation de fuites OAuth/jetons. Une fois qu'ils ont accès, ils publient une nouvelle version contenant des charges utiles malveillantes. Ces charges utiles peuvent être assez sophistiquées. Lors de l'attaque npm de 2025, le code injecté était un voleur de portefeuille crypto qui ne s'activait que dans les contextes de navigateur. D'autres backdoors pourraient collecter des données d'environnement, ouvrir des reverse shells ou chiffrer des données (à la manière d'un ransomware). Parce que la version est toujours sémantiquement valide (par exemple, 4.4.2 à 4.4.3), et que souvent le package fonctionne toujours normalement en dehors de l'effet secondaire malveillant caché, il peut se propager largement avant d'être détecté. Les utilisateurs ne découvrent généralement la compromission que lorsque les scanners de sécurité signalent un comportement inhabituel ou lorsque la communauté/les registres publics l'annoncent.
Risques : Le risque évident est d' exécuter du code malveillant sous le couvert d'une dépendance de confiance. Cela peut entraîner le vol d'informations sensibles (le malware de l'incident npm ciblait les transactions crypto, mais il pourrait tout aussi facilement cibler les jetons d'authentification ou les données clients). Cela compromet l'intégrité de votre logiciel – même si votre code est sécurisé, la bibliothèque compromise peut le subvertir entièrement. De plus, ces attaques érodent la confiance dans l'écosystème ; les équipes pourraient geler les mises à jour (manquant ainsi des correctifs légitimes) par crainte. Dans le pire des cas, un package compromis largement utilisé peut servir de porte dérobée pour de nombreuses entreprises simultanément, car il crée essentiellement un botnet de toutes les installations qui contactent l'attaquant.
Atténuation : Se défendre contre les packages détournés est délicat, car il s'agit d'une trahison de confiance. Cependant, il existe des bonnes pratiques pour limiter le rayon d'impact. Traitez les mises à jour de dépendances avec un sain scepticisme : examinez les changelogs et les diffs des nouvelles versions, en particulier pour les utilitaires de base qui ne sont généralement pas mis à jour souvent. Utilisez la recherche de malwares automatisée sur les nouvelles versions de packages – certains outils analysent le comportement des packages (par exemple, en détectant si une nouvelle version commence soudainement à effectuer des appels réseau ou à lire des informations système). Épingler les versions (et ne pas passer automatiquement à la dernière sans examen) peut laisser le temps d'observer les rapports de la communauté. L'utilisation de fichiers de verrouillage (lockfiles) et la vérification des sommes de contrôle (checksums) (tels que pris en charge par npm, le mode de vérification de hachage de pip, etc.) peuvent garantir que vous installez exactement ce que vous attendez – et envisagez d'activer la 2FA et la vérification sur vos propres packages si vous en publiez. Du point de vue du processus, maintenez un inventaire de vos dépendances (un SBOM) afin de pouvoir rapidement identifier si vous utilisez un package compromis et d'y réagir.
La surveillance continue des dépendances d'Aikido excelle ici. Le scanner d'Aikido ne se contente pas de vérifier les CVE connues – il recherche également comportements de package suspects et les signatures de malwares connues dans les dépendances. Par exemple, si une nouvelle version de requests sur PyPI tente soudainement d'ouvrir des connexions réseau lors de l'installation, Aikido signalerait cette anomalie. Aikido intègre le renseignement sur les menaces (y compris les flux de paquets compromis ou détournés connus) afin de vous avertir si une dépendance de votre chaîne d'approvisionnement est signalée comme sabotée. De plus, avec les fonctionnalités d'Aikido, AutoFix et flux de vulnérabilités, si une version malveillante s'infiltre, la plateforme peut recommander et même ouvrir automatiquement une PR de correction pour revenir à une version sûre ou la mettre à niveau. La clé est la rapidité – Aikido aide à détecter ces incidents tôt et à automatiser votre réponse, réduisant la fenêtre d'exposition.
4. Secrets et identifiants exposés dans le code ou la CI
Il est souvent dit que les identifiants et les secrets sont les clés du royaume. Dans le contexte de la sécurité de la chaîne d’approvisionnement, les secrets divulgués (clés API, identifiants cloud, clés de signature, etc.) peuvent être aussi dangereux que n'importe quel malware. Pourquoi ? Parce que si un attaquant trouve une clé AWS ou un jeton CI/CD valide dans votre dépôt GitHub ou vos journaux de build, il peut l'utiliser directement pour infiltrer vos systèmes ou empoisonner votre pipeline. Les identifiants divulgués sont une cause majeure de violations – selon le rapport Verizon Data Breach, 22 % des violations en 2024 ont été causées par des identifiants exposés. En termes de chaîne d'approvisionnement, les secrets dans le code source ou la configuration peuvent permettre aux attaquants de publier du code malveillant (en utilisant vos identifiants), d'accéder à des registres de packages privés ou d'injecter des artefacts malveillants dans vos déploiements.
Comment cela se manifeste : Les secrets peuvent fuir de nombreuses manières. Un développeur pourrait accidentellement commettre un .env fichier contenant des mots de passe de base de données vers un dépôt public. Ou un pipeline CI/CD pourrait imprimer un jeton sensible dans des journaux lisibles par tous. Plus subtilement encore, un attaquant qui obtient un accès initial pourrait rechercher des clés codées en dur dans votre base de code. Une fois obtenus, ces secrets peuvent être utilisés pour usurper l'identité de vos comptes. Par exemple, une clé AWS pourrait permettre à un attaquant de pousser une image conteneur empoisonnée vers votre registre ECR privé, que votre déploiement récupérerait ensuite. Un jeton d'accès personnel GitHub pourrait permettre à un attaquant de commettre du code dans votre dépôt ou de manipuler vos versions. Dans les pipelines CI, si un attaquant met la main sur des identifiants pour CI ou le cloud, il peut contourner efficacement le code review normal et insérer directement des composants ou des infrastructures malveillants.
Risques : Le risque direct est l'accès non autorisé. Des clés cloud exposées pourraient entraîner des violations d'infrastructure ou des vols de données. Des identifiants de registre de packages exposés pourraient permettre à un attaquant de publier une nouvelle version d'une bibliothèque interne avec un malware (une autre voie vers le scénario de package détourné). En CI, des jetons divulgués pourraient permettre aux attaquants de modifier les configurations de build, de récupérer des secrets des coffres-forts ou d'intercepter des artefacts. Essentiellement, les secrets sont comme des passe-partout : une fois que l'attaquant les possède, il peut souvent se déplacer dans vos systèmes sans avoir besoin d'exploiter une vulnérabilité logicielle. Cela peut entraîner n'importe quoi, d'un compromis complet de l'environnement de production à des attaquants modifiant silencieusement des artefacts (par exemple, en remplaçant un binaire dans un pipeline de publication par un binaire piégé). Ces scénarios font partie des attaques de la chaîne d’approvisionnement car l'intégrité du processus de livraison logicielle est compromise par la confiance volée.
Atténuation : La meilleure atténuation est de ne pas divulguer de secrets en premier lieu. Plus facile à dire qu'à faire, mais il existe des pratiques concrètes : Utilisez des outils de balayage de secrets sur vos dépôts pour détecter les clés API ou les mots de passe avant qu'ils ne soient committés. Les fournisseurs Git comme GitHub ont intégré le balayage de secrets – activez-le. Ne jamais coder en dur des identifiants sensibles dans le code ; utilisez plutôt des variables d'environnement ou des services de gestion de secrets (et assurez-vous que vos dépôts ne contiennent pas ces valeurs dans les fichiers de configuration). Dans les pipelines CI/CD, masquez les secrets dans les journaux (la plupart des plateformes offrent des options pour empêcher l'impression des variables d'environnement secrètes). Faites tourner régulièrement les clés afin que si quelque chose fuit, cela ne soit valide que pour une courte période. Appliquez le principe du moindre privilège : un jeton divulgué qui n'a qu'un accès en lecture est bien moins dommageable qu'un jeton administrateur. Pour toute clé à privilèges élevés, appliquez des restrictions multi-facteurs ou IP si possible. Surveillez l'utilisation des secrets – par exemple, si une clé qui ne devrait être utilisée que par votre application commence à être utilisée ailleurs, c'est un signal d'alarme.
La fonctionnalité de détection de secrets d'Aikido est conçue pour identifier rapidement les identifiants exposés. Elle analyse votre code, vos fichiers de configuration et même les définitions de pipelines CI à la recherche de schémas correspondant aux clés API, clés privées, jetons, et plus encore. Par exemple, si un développeur commet accidentellement un jeton d'accès personnel GitHub ou une clé secrète AWS, Aikido le signalera immédiatement, vous permettant de le purger et de le renouveler. Mais la détection n'est qu'une partie de l'histoire – Aikido peut s'intégrer à votre CI pour faire échouer une build si un secret est détecté, empêchant ainsi le déploiement accidentel d'informations sensibles. Elle aide également à maintenir un inventaire des secrets et de leur emplacement, complétant ainsi votre utilisation de coffres-forts ou de gestionnaires de secrets. En intégrant l'analyse des secrets dans le workflow de développement (plugins IDE, hooks de pré-commit, vérifications CI), Aikido aide les développeurs à maintenir les identifiants hors des dépôts et des pipelines, coupant ainsi l'une des voies les plus faciles utilisées par les attaquants lors des violations de la chaîne d'approvisionnement.
5. Configurations de pipeline CI/CD non sécurisées (Pipeline comme surface d'attaque)
Votre pipeline CI/CD est en fait la chaîne d'assemblage de votre usine logicielle – et s'il est mal configuré ou non sécurisé, les attaquants peuvent altérer tout ce qui en sort. Les systèmes CI/CD (comme GitHub Actions, Jenkins, GitLab CI, etc.) ont souvent un accès étendu : ils extraient du code, intègrent des dépendances, exécutent des tests, poussent des artefacts et même déploient en production. Cela en fait une cible de choix. Les problèmes courants de sécurité des pipelines incluent des permissions d'accès trop larges, un manque d'isolation et l'utilisation de paramètres par défaut non sécurisés. Une analyse récente a révélé qu'environ 23,8 % des attaques de la chaîne d’approvisionnement logicielle exploitent les vulnérabilités de build CI/CD, soulignant à quel point la sécurité des pipelines est désormais un front majeur. En pratique, nous avons constaté des incidents où des attaquants ont exploité des erreurs de configuration CI pour se déplacer latéralement. Par exemple, un serveur Jenkins mal configuré et exposé à Internet ou une tâche CI qui exécute par inadvertance du code non fiable (par exemple, la compilation de PR provenant de contributeurs externes sans sandboxing) peut entraîner un compromis.
Comment cela se manifeste : Un scénario est celui des runners de pipeline sur-privilégiés. Imaginez un agent CI qui a un accès administrateur à votre cloud ou est autorisé à déployer directement des artefacts. Si un attaquant peut s'insérer dans la CI (par injection de code, une information d'identification compromise ou l'exploitation de l'outil CI), il détient désormais les “clés du royaume” – il peut injecter des logiciels malveillants dans les builds, ou même utiliser l'agent CI pour exécuter des commandes dans votre infrastructure. Un autre scénario est le non-respect des vérifications sur le code entrant : par exemple, une pull request malveillante contenant une modification de configuration CI visant à exfiltrer des secrets ou à ignorer des tests pourrait passer inaperçue si les code review sont laxistes. De plus, de nombreux pipelines CI montent des secrets (comme des clés de signature ou des informations d'identification de déploiement) en tant que variables d'environnement. Si le pipeline n'est pas configuré pour restreindre qui peut déclencher des builds ou quel code s'exécute, ces secrets peuvent être volés par des attaquants qui manipulent la build. Par exemple, certaines configurations par défaut peuvent permettre aux PR de dépôts forkés d'exécuter la CI principale avec accès aux secrets – un paramètre dangereux connu qui peut divulguer des secrets à des contributeurs malveillants.
Risques : Le pipeline CI/CD, s'il est compromis, offre à un attaquant un chemin direct pour compromettre le logiciel au moment de la build ou du déploiement. Cela pourrait entraîner l'expédition de code non autorisé en production ou aux utilisateurs (imaginez du code malveillant ajouté pendant la build qui n'a jamais existé dans le contrôle de version). Cela peut également entraîner une exposition généralisée des données ; les systèmes CI contiennent souvent des journaux ou des artefacts avec des informations sensibles. Un pipeline non sécurisé peut être exploité pour pivoter ailleurs – par exemple, si votre serveur Jenkins a un accès réseau à des services internes, un attaquant qui compromet Jenkins peut alors exploiter ces services. Essentiellement, une CI vulnérable est un point d'entrée à la fois pour votre produit logiciel et votre infrastructure. C'est aussi un domaine souvent négligé – les équipes de développement se concentrent sur la sécurité du code applicatif mais ne scrutent pas le pipeline avec la même rigueur.
Atténuation : Sécuriser les pipelines CI/CD exige de les traiter comme des actifs de production. Premièrement, verrouillez l'accès : assurez-vous que votre système CI n'est pas accessible publiquement, utilisez des VPN ou des listes d'autorisation IP, et exigez une authentification pour déclencher des tâches sensibles. Appliquez le principe du moindre privilège aux informations d'identification du pipeline – par exemple, si une tâche de build n'a besoin que d'un accès en écriture à un dépôt d'artefacts, ne lui donnez pas également des droits d'administrateur cloud. Utilisez des informations d'identification distinctes pour des tâches/étapes distinctes. Deuxièmement, assainissez les entrées : pour les workflows publics (comme les projets open source où n'importe qui peut ouvrir une PR), utilisez des environnements de runner isolés sans secrets, ou exigez une approbation manuelle pour l'exécution de code non fiable. De nombreuses plateformes CI vous permettent de marquer les secrets comme non disponibles pour les PR forkées. Activez la journalisation d'audit sur votre pipeline : sachez qui a modifié quoi dans les configurations de build. Une autre pratique clé est de épingler vos dépendances CI – si votre pipeline utilise des conteneurs de build ou des actions/plugins tiers, épinglez-les à des versions ou des hachages spécifiques (en évitant les balises “latest”) pour empêcher un attaquant de substituer quelque chose (plus d'informations à ce sujet dans la section suivante). Mettez régulièrement à jour vos logiciels et plugins CI, car des vulnérabilités dans les outils CI eux-mêmes apparaissent. Enfin, envisagez d'utiliser des runners éphémères isolés pour chaque build (lorsque cela est faisable) afin qu'une build compromise ne maintienne pas un point d'ancrage pour l'attaquant.
Aikido propose une analyse de sécurité CI/CD qui permet d'auditer les configurations de vos pipelines pour les bonnes pratiques et les potentielles erreurs de configuration. Par exemple, Aikido peut analyser vos workflows GitHub Actions ou vos fichiers Jenkins pour signaler des problèmes tels que des actions non épinglées, l'utilisation de runners auto-hébergés avec des permissions étendues, ou des secrets exposés aux PRs issues de forks. Il agit comme un linter pour la sécurité CI. La plateforme d'Aikido s'intègre également aux pipelines CI pour appliquer des politiques : si quelqu'un tente d'exécuter une tâche de déploiement à partir d'une branche non autorisée ou si un fichier de workflow critique a été modifié dans une PR, Aikido peut exiger des approbations supplémentaires. En analysant continuellement la configuration du pipeline, Aikido contribue à garantir que votre « usine logicielle » est bien protégée – pas de portes ouvertes, pas de moyens faciles pour un attaquant de détourner le processus. Considérez-le comme un gardien de la configuration CI/CD travaillant aux côtés de votre équipe DevOps.
6. Dépendances de pipeline empoisonnées (outils et actions CI/CD tiers)
Les pipelines modernes intègrent souvent une variété de outils tiers, images Docker, scripts et actions pour effectuer des tâches (comme la couverture de code, les déploiements, etc.). Chacun d'eux est une dépendance implicite dans votre chaîne d'approvisionnement. Si l'un d'eux est malveillant ou compromis, votre pipeline (et le logiciel résultant) peut être compromis. Un exemple frappant de cela a été le attaque sur le/la reviewdog/action-setup GitHub Action et compromission subséquente de tj-actions/changed-files en 2025. Les attaquants ont réussi à injecter du code malveillant dans ces actions CI largement utilisées en exploitant leur processus de mise à jour, ce qui a entraîné la fuite de secrets des runners CI pour tout projet les utilisant. De même, considérez les scripts de pipeline comme l'uploader Bash de Codecov (qui a été compromis en 2021) – des milliers de pipelines faisaient confiance à un outil qui exfiltrait silencieusement leurs données. Ces incidents illustrent comment un attaquant peut empoisonner le puits en ciblant les outils sur lesquels votre pipeline s'appuie.
Comment ça marche : Les attaquants recherchent des utilitaires ou des images CI/CD populaires présentant des faiblesses dans la chaîne d'approvisionnement – peut-être un mainteneur qui ne signe pas les commits ou une dépendance obsolète dans une image Docker. En compromettant le projet en amont (via une prise de contrôle de compte, un exploit ou en s'introduisant en tant que contributeur), ils peuvent insérer du code malveillant. Dans le cas de GitHub Actions, un attaquant a obtenu l'accès au compte ou au jeton des mainteneurs et a modifié le code de l'action, re-taguant même les références Git de sorte que ce qui était étiqueté comme « v1 » pointait désormais vers un commit malveillant. Les projets utilisant uses: reviewdog/action-setup@v1 dans leur workflow a soudainement tiré une action corrompue qui a divulgué des secrets. Parce que les systèmes CI récupèrent généralement le dernier code tagué à chaque exécution, un pipeline peut exécuter à son insu du code altéré provenant d'un tiers. Les images Docker utilisées en CI (pour la construction ou les tests) sont également à risque – si quelqu'un pousse une mise à jour malveillante vers une image comme node:alpine que votre pipeline utilise, vous exécuteriez tout ce qui se trouve dans cette image.
Risques : L'impact ici est similaire à un détournement de bibliothèque, mais potentiellement encore plus direct. Les outils de CI s'exécutent souvent avec des privilèges élevés (certains runners GitHub ont sudo, etc.) et un accès aux identifiants. Une action ou un script empoisonné peut immédiatement exfiltrer tous les secrets de votre environnement, ou injecter des backdoors dans le code en cours de construction/test. Lors d'un incident réel, une action GitHub malveillante déchargeait des secrets de CI dans des logs publics. Un autre risque est qu'un outil de build compromis puisse altérer la sortie compilée (imaginez un compilateur malveillant qui insère toujours une certaine vulnérabilité ou backdoor dans les binaires). La difficulté pour les défenseurs est que ces dépendances de pipeline pourraient ne pas être aussi bien examinées que vos dépendances de code – de nombreuses équipes font aveuglément confiance à une image Docker ou à une action open-source parce qu'elle est largement utilisée. Cela offre aux attaquants un moyen d'accès furtif, et la brèche pourrait ne pas être découverte avant bien plus tard (voire jamais).
Atténuation : Tout comme vous épinglez les dépendances d'application, épinglez vos dépendances de pipeline. Dans GitHub Actions, au lieu d'utiliser @v1 ou @main pour une action, utilisez un SHA de commit spécifique afin qu'il ne puisse pas être modifié silencieusement. Pour les images Docker, utilisez des digests ou des versions spécifiques au lieu de dernière. Cela garantit que vous exécutez une version connue et fiable à chaque fois. Ensuite, vérifiez et faites confiance, mais vérifiez : préférez les actions ou les outils largement fiables et idéalement, disposer d'un mécanisme de vérification (certaines actions sont vérifiées par GitHub ou sont signées). Surveillez les notifications en amont – abonnez-vous aux flux de sécurité des outils tiers que vous utilisez afin de recevoir des alertes en cas de compromission. Lorsque cela est possible, utilisez des outils de pipeline critiques fournis par des fournisseurs ou hébergés par vous-même : par exemple, au lieu de télécharger un script aléatoire depuis Internet au moment de la compilation, intégrez-le à votre base de code (après l'avoir examiné) afin qu'il ne puisse pas être modifié à votre insu. Utilisez le sandboxing pour les étapes risquées – par exemple, exécutez des linters ou des outils de couverture de test dans des conteneurs isolés avec un accès limité. Enfin, envisagez d'adopter des frameworks comme SLSA (Supply Chain Levels for Software Artifacts) de Google pour vos pipelines, qui fournissent des directives pour renforcer les processus de compilation et exigent la provenance pour les étapes de compilation.
🛡 Rappel Aikido Security : L'analyse CI/CD d'Aikido s'étend également aux dépendances de votre pipeline. Il vérifiera si vos workflows référencent des actions avec des tags mutables ou s'ils proviennent de sources potentiellement non fiables. Par exemple, Aikido peut signaler que vous utilisez uses: someaction@latest et suggérer de l'épingler à un commit. Le scanner de dépendances d'Aikido ne se contente pas d'analyser le code de votre application ; il peut également scanner vos conteneurs et outils de build pour les vulnérabilités connues ou les signatures de logiciels malveillants. Si vous utilisez une image Docker de base en CI, Aikido peut scanner la SBOM de cette image pour s'assurer qu'elle ne contient pas de composants malveillants connus. Essentiellement, Aikido aide à garantir que les composants de votre pipeline sont aussi sûrs que ceux de votre application. En intégrant ces vérifications, Aikido s'assure que vos outils et actions de CI ne constituent pas une porte dérobée cachée. Au cas où un outil populaire does est compromis, le renseignement sur les menaces d'Aikido serait mis à jour, et vous recevriez une alerte si vos pipelines sont affectés – vous permettant de réagir rapidement (par exemple, en mettant le pipeline en pause, en le mettant à jour vers une version sûre) avant que des dommages ne soient causés.
7. Versions non épinglées et dépendances mutables (Le problème du « Latest »)
L'utilisation de flottants ou versions de dépendances non épinglées est une vulnérabilité de la chaîne d'approvisionnement qui peut vous affecter de deux manières : vous pourriez involontairement récupérer une mise à jour malveillante ou une mise à jour boguée/vulnérable parce que vous tirez toujours la version « latest ». Qu'il s'agisse d'une image de base Docker taguée :latest ou une plage de versions de paquet comme ^1.0.0 Dans npm, l'utilisation de versions non figées signifie que votre build d'aujourd'hui pourrait récupérer un composant différent de celui d'hier. Cela compromet la reproductibilité du build et ouvre la porte aux attaquants pour qu'ils puissent planifier leurs actions. Par exemple, si un attaquant compromet un package et que vous n'épinglez pas une version spécifique connue comme étant sûre, votre prochain build récupérera la version compromise. Dans l'attaque GitHub Actions abordée précédemment, un facteur contributif était que les projets référençaient un tag mutable (v1) que l'attaquant a redirigé vers un commit malveillant. L'utilisation de « pins » stricts (comme les SHA de commit ou les versions exactes) aurait empêché cette redirection de tag d'affecter les builds.
Comment ça marche : Considérez un projet Python qui utilise requests>=2.0 dans ses dépendances (permettant toute nouvelle version 2.x). Lorsque vous effectuez un `pip install`, il récupérera la version 2.x la plus récente. Si les mainteneurs (ou un attaquant) publient requests 2.999 demain et qu'il présente des problèmes, votre environnement change de manière inattendue. Ou imaginez que votre Dockerfile utilise FROM node:latest; chaque fois que l'équipe Node met à jour cette image (ou si un attaquant parvient à pousser une image similaire), vos builds tirent une nouvelle image avec un contenu potentiellement différent. Les dépendances non épinglées transfèrent essentiellement le contrôle de votre chaîne d'approvisionnement aux calendriers de parties externes. Les attaquants apprécient particulièrement cela s'ils obtiennent l'accès pour pousser une mise à jour – ils savent que de nombreux utilisateurs se mettront à jour automatiquement. Même sans acteur malveillant, il existe un risque qu'une mauvaise mise à jour provoque des échecs ou introduise une faille de sécurité avant que vous ne vous en rendiez compte. Le tristement célèbre l'incident left-pad (où la suppression d'un package a cassé les builds globalement) est un exemple de ce qui peut arriver lorsque de nombreux projets font implicitement confiance à une version externe la plus récente.
Risques : Le risque principal est le manque de contrôle et de visibilité. Vous pensez peut-être construire le même code, mais en réalité, une bibliothèque ou une image sous-jacente a changé. Ce changement pourrait être une vulnérabilité critique (si vous avez mis à jour automatiquement vers une version avec une nouvelle CVE) ou une logique malveillante. Dans les attaques de la chaîne d'approvisionnement, le timing est crucial : si l'adversaire peut brièvement introduire une mauvaise version pendant que vous construisez, il gagne, même si cette version est corrigée plus tard. Les dépendances non épinglées rendent également la réponse aux incidents plus difficile – si vous ne savez pas exactement quelle version a été utilisée dans un build donné, il est difficile de savoir si vous avez été affecté par une version malveillante ou vulnérable. Essentiellement, cela érode la reproductibilité et la traçabilité qui sont fondamentales pour des builds sécurisés. L'intégrité des builds logiciels dépend d'avoir des entrées déterministes ; “latest” est l'opposé de déterministe.
Atténuation : Toujours épingler ou verrouiller vos dépendances à des versions ou des digests connus et fiables. Utilisez des numéros de version exacts dans les manifestes de packages et employez des fichiers de verrouillage (package-lock.json, Pipfile.lock, etc.) afin que chaque personne et chaque environnement utilise les mêmes versions résolues. Pour les images Docker, épinglez à une version spécifique ou mieux encore à un digest SHA (qui est immuable). Pour les dépendances ou actions basées sur Git, épinglez aux hachages de commit. Si vous devez autoriser des plages (pour obtenir des mises à jour mineures), envisagez d'utiliser des bots fiables ou des outils de mise à jour qui vous alertent des nouvelles versions plutôt que de les tirer automatiquement. Mettez en œuvre une politique selon laquelle aucun build ne doit consommer un artefact qui n'est pas explicitement suivi dans le contrôle de source (ou dans un fichier de métadonnées). De plus, maintenez un SBOM pour chaque version – il s'agit d'une liste des versions exactes des composants de votre produit. De cette façon, si un risque apparaît (par exemple, la version X a été compromise à la date Y), vous pouvez rapidement interroger lesquelles de vos versions incluaient cette version. Il est également judicieux de tester votre processus de mise à jour des dépendances séparément – ne mettez pas à jour aveuglément dans les builds de production ; ayez un environnement de staging ou un job de CI qui teste les mises à jour afin de pouvoir détecter les problèmes. En fin de compte, l'épinglage des versions vous donne le contrôle : vous décidez quand mettre à niveau après vérification, plutôt que d'être surpris par des changements en amont.
Les outils d'Aikido encouragent fortement l'épinglage des dépendances et la visibilité des versions. Quand Aikido génère une SBOM pour votre projet, il liste chaque composant et sa version – contribuant à garantir qu'il n'y a pas de dépendances « flottantes ». Aikido peut également s'intégrer à votre CI pour faire échouer les builds qui utilisent des dépendances non épinglées ou des tags mutables, agissant comme un filet de sécurité. Par exemple, si quelqu'un introduit FROM python:latest dans un Dockerfile ou ajoute une GitHub Action sans SHA épinglé, le scanner d'Aikido le signalera. De plus, les fonctionnalités de gestion des dépendances d'Aikido peuvent ouvrir automatiquement des pull requests pour mettre à jour les dépendances de manière contrôlée (avec un contexte de sécurité), afin que vous ne soyez pas bloqué sur d'anciennes versions, mais que vous puissiez effectuer une mise à niveau en toute sécurité. En utilisant Aikido pour surveiller et gérer vos composants open source, vous obtenez un bouclier qui garantit vous savez exactement ce que vous construisez. Il y a du pouvoir (et de la sécurité) dans cette connaissance.
8. Composants obsolètes avec des vulnérabilités connues
À l'autre extrémité du spectre des problèmes « récents » se trouve le risque d'utiliser des dépendances obsolètes comportant des vulnérabilités de sécurité connues (CVE). Il s'agit davantage d'une vulnérabilité traditionnelle, mais c'est absolument une préoccupation pour la chaîne d'approvisionnement : votre logiciel n'est sécurisé qu'autant que le maillon le plus faible de son graphe de dépendances. Les attaquants exploitent souvent des failles bien connues dans des bibliothèques populaires que les organisations ont tardé à patcher. Par exemple, l'utilisation d'une version plus ancienne d'une bibliothèque Struts, Log4j ou OpenSSL avec une CVE critique rendue publique peut entraîner l'exécution de code à distance ou une violation de données dans votre application – constituant effectivement un échec de mise à jour de la chaîne d'approvisionnement. Avec l'explosion de l'open source, maintenir tout à jour est un défi ; cependant, les rapports d'analyse de la composition logicielle (SCA) montrent constamment qu'un pourcentage élevé d'applications contiennent des bibliothèques obsolètes avec des failles connues. Si vous incluez un composant open source vulnérable, un attaquant pourrait ne pas avoir besoin d'écrire un nouvel exploit – il peut simplement exploiter la CVE existante contre vous.
Comment cela se manifeste : Souvent, les équipes de développement incluent une bibliothèque pour certaines fonctionnalités et ensuite oublient de la mettre à jour. Cette bibliothèque pourrait en importer d'autres (dépendances transitives), et quelque part dans cette chaîne, il pourrait y avoir un bug critique. Par exemple, considérez une application Node.js qui importe un package dépendant d'une version obsolète de lodash version avec une vulnérabilité de pollution de prototype. Votre application pourrait être exploitable via cette vulnérabilité même si votre code est correct. Dans les outils CI/CD et de build, des composants obsolètes peuvent également se cacher – peut-être que votre conteneur de build contient un ancien paquet OS avec un bug Shellshock, ou que votre serveur CI lui-même n'est pas patché. La manifestation est généralement qu'un scanner ou un test d'intrusion trouve la CVE connue, ou pire, qu'un incident se produise (par exemple, l'application est piratée via ce composant). Un cas notoire a été le Vulnérabilité Log4j « Log4Shell » (CVE-2021-44228); de nombreuses organisations ont été prises au dépourvu en utilisant d'anciennes versions de Log4j et ont été touchées par des exploits en circulation. Ce type de scénario est exactement ce que la sécurité proactive de la chaîne d'approvisionnement vise à prévenir.
Risques : Le risque lié aux composants connus pour être vulnérables est simple : les attaquants savent déjà comment les exploiter. Une fois qu'une vulnérabilité est publique, elle est souvent accompagnée d'exploits de preuve de concept ou au moins de descriptions détaillées. Les attaquants scanneront Internet à la recherche d'applications ou de services qui semblent utiliser le composant vulnérable (par exemple, en vérifiant les en-têtes d'application ou des comportements spécifiques). Si votre logiciel utilise ce composant et est exposé de manière applicable, vous êtes une cible. Cela peut entraîner une compromission complète du système, un vol de données ou des pannes de service, selon la vulnérabilité. Outre l'exploitation directe, il y a aussi des problèmes de conformité et de confiance des clients – l'exécution de vulnérabilités connues peut violer les réglementations ou les exigences de sécurité contractuelles. C'est un indicateur d'une mauvaise hygiène de sécurité. N'oubliez pas que votre chaîne d'approvisionnement comprend non seulement le code que vous écrivez, mais aussi le code que vous consommez ; négliger les mises à jour, c'est comme laisser des brèches dans vos défenses qui sont bien documentées dans les manuels d'attaquants.
Atténuation : Adoptez une culture de gestion continue des dépendances. Cela signifie scanner régulièrement vos projets (et images de conteneurs) à la recherche de vulnérabilités connues. Utilisez les outils SCA pour signaler lorsqu'une version de dépendance présente une CVE. De nombreux gestionnaires de paquets disposent désormais de commandes d'audit (par exemple, npm audit, pip audit) pour lister les packages vulnérables. Intégrez cela au CI, afin que les builds avertissent ou échouent si de nouvelles vulnérabilités sont introduites. Mettez en place un processus (éventuellement automatisé via des bots comme Dependabot ou l'AutoFix d'Aikido) pour inciter aux mises à niveau vers des versions corrigées. Il est important de prioriser – toutes les CVE ne sont pas égales ; concentrez-vous sur celles de haute gravité ou présentes dans des logiciels accessibles depuis votre application. De plus, assurez-vous de mettre à jour votre environnement de build et de déploiement – par exemple, maintenez vos images Docker de base à jour avec les correctifs de sécurité, mettez à jour les outils ou plugins CI vers des versions corrigées. Un autre élément clé est de maintenir une liste de matériaux (SBOM) comme mentionné, ce qui vous aide à répondre rapidement à la question « utilisons-nous la bibliothèque qui inquiète tout le monde cette semaine ? » Lorsque Log4Shell a frappé, les organisations dotées d'un bon SBOM processus ont pu immédiatement rechercher et trouver où Log4j était utilisé. Enfin, abonnez-vous aux bulletins de sécurité des projets majeurs que vous utilisez, afin d'être alerté lorsque de nouvelles vulnérabilités apparaissent. Le patching rapide est crucial ; les attaquants commencent souvent à exploiter les CVE populaires dans les jours, voire les heures, suivant leur annonce.
Le scanner de dépendances et les capacités SCA d'Aikido sont conçus pour résoudre précisément ce problème. Il analysera vos projets pour identifier tous les composants open source et les vérifiera par rapport à une base de données de vulnérabilités continuellement mise à jour. Le résultat n'est pas seulement une liste de problèmes – Aikido fournit des informations exploitables telles que la gravité, la disponibilité d'un correctif, et même une fonctionnalité AutoFix qui peut générer automatiquement des correctifs de mise à jour sécurisés. Par exemple, si votre projet Maven utilise une ancienne bibliothèque Struts avec une faille critique, Aikido peut suggérer la version sécurisée et mettre à jour votre pom.xml pour vous. De plus, Aikido s'intègre à l'ensemble de votre flux de travail de développement (plugins IDE, vérifications de PR, CI) afin que les vulnérabilités connues soient détectées tôt, et non une fois votre logiciel en production. Il vous aide également à générer facilement des SBOMs, vous offrant une visibilité sur le contenu de votre logiciel. Cela signifie que lorsque la prochaine faille zero-day dans une bibliothèque courante fera la une, vous pourrez rapidement interroger votre tableau de bord Aikido pour voir si vous êtes concerné. Rester à jour avec les mises à jour devient beaucoup plus facile quand Aikido veille constamment sur vous, en s'assurant que les composants obsolètes ne restent pas sans être traités.
9. Manque de vérification d'intégrité (Signature et validation d'origine insuffisantes)
La dernière vulnérabilité à souligner est plus systémique : l'incapacité à vérifier l'intégrité et l'origine des composants. En d'autres termes, ne pas utiliser ou vérifier les signatures, les sommes de contrôle ou la provenance du code et des binaires qui transitent par votre chaîne d'approvisionnement logicielle. Sans vérification d'intégrité, vous faites confiance par défaut. Les attaquants peuvent exploiter cela en altérant des artefacts ou en usurpant l'identité de sources. Par exemple, si vous téléchargez une bibliothèque tierce ou un installateur via HTTP non sécurisé ou depuis un site miroir sans vérifier un hachage/une signature, un attaquant intermédiaire pourrait vous servir une version compromise. De même, si vous ne vérifiez pas qu'une image de conteneur est signée par une partie de confiance, quelqu'un pourrait vous inciter à exécuter une image similaire avec une porte dérobée. Même au sein du CI/CD, le manque de vérification signifie que si un attaquant compromet une étape, les étapes suivantes pourraient faire aveuglément confiance aux sorties. Un cas illustratif dans le monde Docker fut l'attaque de "Ghostwriting" ou d'altération de couche d'image, où le contenu d'une image était modifié sans changer son digest de manifeste, contournant ainsi une validation naïve. Le principe s'applique à la chaîne d'approvisionnement en général : sans contrôles d'intégrité rigoureux, les attaquants peuvent introduire des modifications inaperçues.
Fonctionnement : La signature de code et sa vérification sont les principales défenses ici. De nombreux écosystèmes de paquets prennent désormais en charge la signature de paquets (par exemple, les signatures de paquets npm, la signature à venir de PyPI, etc.), et les registres de conteneurs prennent en charge la signature d'images (comme Docker Content Trust avec Notary, ou Sigstore Cosign pour Kubernetes). Si ceux-ci ne sont pas utilisés ou appliqués, un attaquant capable d'intercepter le trafic réseau ou de compromettre un pipeline de build pourrait insérer des artefacts malveillants qui seraient acceptés comme authentiques. Le manque de vérification d'intégrité inclut également la non-vérification de l'intégrité des dépendances : par exemple, ne pas vérifier la somme de contrôle d'une bibliothèque téléchargée par rapport à ce que le fournisseur a publié. Dans le CI, ne pas vérifier l'identité de la source (comme ne pas vérifier qu'un commit Git est signé ou provient du dépôt attendu) peut entraîner l'intégration d'un code erroné. Le scénario est souvent une attaque avancée – par exemple, un adversaire sophistiqué pourrait compromettre une route DNS ou BGP vers votre serveur d'artefacts et vous servir des malwares pendant une courte période, ou compromettre un serveur de build pour altérer des binaires après compilation. Si vous ne vérifiez pas les signatures/hachages, vous ne vous en rendriez pas compte.
Risques : Le risque évident est un compromis complet de l'intégrité logicielle. Vous pourriez livrer un logiciel qui a été altéré par des attaquants, sapant toutes les autres mesures de sécurité. C'est particulièrement préoccupant pour des éléments comme les fichiers d'installation, les mises à jour ou les images de conteneurs qui sont largement distribués – une attaque ici peut avoir un rayon d'impact massif (semblable à l'incident SolarWinds où un compromis du système de build a conduit à une mise à jour logicielle "trojanisée"). Un autre risque est l'attestation de la chaîne d'approvisionnement – si vous ne pouvez pas prouver l'intégrité de vos composants, il est difficile de leur faire confiance dans des environnements sécurisés. Nous constatons une pression croissante de l'industrie et des régulateurs pour une provenance vérifiée (par exemple, le décret exécutif américain sur les logiciels sécurisés exige la vérification de l'intégrité via les SBOM et les signatures). Le manque de vérification peut également permettre des attaques plus simples comme la substitution de dépendances (un attaquant remplace un fichier ou une bibliothèque sur votre machine de build parce que vous ne le vérifiez jamais). Essentiellement, ne pas vérifier est une invitation pour les attaquants à faire preuve de créativité, car vous ne les détecterez que si quelque chose se brise de manière flagrante – les modifications furtives passent inaperçues.
Atténuation : Adoptez des pratiques de signature et de vérification dans votre cycle de développement. Activez la signature GPG ou Sigstore pour les packages et les conteneurs que vous construisez et distribuez, et de même, vérifiez les signatures des éléments que vous consommez. Par exemple, avant d'utiliser un binaire d'une version, vérifiez sa signature GPG ou au moins comparez son hachage SHA-256 avec celui officiel. Dans les déploiements de conteneurs, utilisez des outils comme Cosign pour vérifier les images de conteneurs par rapport aux clés publiques attendues ou utilisez des contrôleurs d'admission pour bloquer les images non signées. Mettez en œuvre une confiance zéro pour les artefacts : ce n'est pas parce qu'un fichier est sur votre réseau qu'il est sûr – vérifiez-le. Utilisez HTTPS pour tous les téléchargements de packages et d'artefacts (la plupart le font par défaut maintenant, mais assurez-vous que personne ne le dégrade). Pour les processus de build internes, envisagez des techniques comme les builds reproductibles et le stockage des hachages des sorties de build pour détecter les altérations. L'emploi d'un contrôle d'admission dans la CI ou le déploiement qui stipule « n'autoriser que les artefacts qui correspondent à des sommes de contrôle ou des signatures connues » peut être une dernière ligne de défense si quelque chose de sournois s'est produit en amont. La clé est de rendre la vérification automatisée et obligatoire, de sorte que les développeurs ne cliquent pas manuellement sur « OK » pour les avertissements, mais que le pipeline refuse le code non vérifié.
Aikido aide à renforcer l'intégrité de plusieurs manières. Grâce à son analyse SBOM et à son intégration avec des outils de signature, Aikido peut valider que vos dépendances et conteneurs sont bien ce qu'ils prétendent être. Par exemple, Aikido peut s'intégrer à Sigstore/cosign pour s'assurer que toute image de conteneur déployée via votre pipeline possède une signature valide de votre organisation – sinon, elle la signale ou la bloque. La plateforme d'Aikido suit également les sommes de contrôle (checksums) des composants analysés ; si le contenu d'un artefact change de manière inattendue (ne correspond pas au SBOM ou à une analyse précédente), c'est une alerte rouge. De plus, la base de données de vulnérabilités et les politiques d'Aikido incluent des vérifications telles que « ce package provient-il d'une source officielle ? », ce qui couvre indirectement l'intégrité (si quelqu'un insère une fausse source de package, Aikido le détecterait via des incohérences de métadonnées). En intégrant Aikido, les équipes disposent d'un gardien d'intégrité automatisé. Il garantit que, du commit de code à la build et au déploiement de l'artefact, chaque élément peut être tracé et approuvé. Combiné aux autres pratiques (analyse, gestion des secrets , etc.), cela donne aux développeurs la confiance que leur chaîne d'approvisionnement logicielle est sécurisée de bout en bout, Aikido vérifiant chaque maillon de la chaîne.
Conclusion : Sécurisez votre chaîne d’approvisionnement dès le premier jour
Les attaques de la chaîne d'approvisionnement logicielle peuvent sembler complexes, mais comme nous l'avons vu, elles exploitent souvent des lacunes plutôt basiques : dépendances non vérifiées, pipelines non sécurisés, identifiants divulgués et artefacts non vérifiés. La bonne nouvelle est qu'en étant conscientes de ces types de vulnérabilités courants, les équipes de développement peuvent prendre des mesures proactives pour combler les lacunes. La sécurité n'est pas le travail de quelqu'un d'autre plus tard – elle commence dès le premier jour du développement et se poursuit à travers chaque commit, build et déploiement. Adopter une approche de sécurité favorable aux développeurs signifie intégrer des pratiques telles que l'analyse des dépendances, la détection des secrets et l'audit CI/CD dans votre workflow quotidien, plutôt que de les considérer comme des réflexions après coup.
Les menaces sont réelles et croissantes – des packages npm malveillants aux violations de pipelines CI – mais avec la bonne approche et les bons outils, vous pouvez garder une longueur d'avance. Encouragez votre équipe à pratiquer une bonne « hygiène de la chaîne d'approvisionnement » : examinez ce que vous importez, renouvelez et protégez les secrets, sécurisez votre processus de build et vérifiez tout. Automatisez autant que possible en utilisant des outils DevSecOps modernes. En fait, l'utilisation de plateformes comme Aikido Security peut grandement faciliter cela. Aikido agit comme votre assistant de sécurité intelligent, détectant les dépendances et configurations risquées tôt, et vous guidant avec des correctifs (souvent automatisés) avant qu'ils ne deviennent des incidents.
N'attendez pas qu'une attaque retentissante force l'action. Prenez en main la sécurité de votre chaîne d'approvisionnement logicielle dès maintenant. Commencez par intégrer des outils de sécurité dans votre pipeline CI/CD et votre IDE – par exemple, essayez le kit de développement gratuit d'Aikido pour analyser vos dépendances et pipelines à la recherche de vulnérabilités et de secrets. Éduquez vos développeurs sur ces menaces afin qu'ils deviennent des acteurs de la protection, et pas seulement des consommateurs d'open source. Avec de la vigilance et l'aide d'une automatisation intelligente de la sécurité, vous pouvez livrer des logiciels en toute confiance, sachant que votre chaîne d'approvisionnement – du code au cloud – est résiliente face aux attaquants. Le codage et la construction sécurisés ne sont pas un obstacle à la vélocité, c'est un investissement dans la confiance et la fiabilité de votre produit. Habilitez votre équipe à adopter ces pratiques dès aujourd'hui, et vous réduirez considérablement le risque de devenir la prochaine histoire d'avertissement en matière de chaîne d'approvisionnement. Bon codage (et sécurisé) !
Poursuivre la lecture :
Top 9 des vulnérabilités de sécurité des conteneurs Docker
Top 7 des vulnérabilités de sécurité du cloud
Top 10 des vulnérabilités de sécurité des applications web que chaque équipe devrait connaître
Top 9 des vulnérabilités et erreurs de configuration de sécurité Kubernetes
Top des vulnérabilités de sécurité du code trouvées dans les applications modernes
Top 10 des vulnérabilités de sécurité Python que les développeurs devraient éviter
Top des vulnérabilités de sécurité JavaScript dans les applications web modernes
