sécurité de la chaîne d’approvisionnement logicielle maximale sécurité de la chaîne d’approvisionnement logicielle Explication sécurité de la chaîne d’approvisionnement logicielle

Introduction : À quand remonte la dernière fois où vous avez vérifié les dépendances et les processus de compilation de votre logiciel ? La triste vérité, c'est que chaque bibliothèque open source que vous npm installChaque image Docker que vous récupérez et chaque script de votre pipeline CI constituent un vecteur d'attaque potentiel. Le développement moderne repose largement sur des composants externes et l'automatisation, ce qui a ouvert la voie à une nouvelle génération de menaces visant la chaîne logistique logicielle. En effet, attaques de la chaîne d’approvisionnement explosé : Sonatype rapporte avoir découvert plus de 700 000 paquets open source malveillants depuis 2019. Et tout récemment, le piratage du compte d'un seul responsable de maintenance npm a conduit à 18 paquets largement utilisés ont été piratés avec des logiciels malveillants, mettant en danger des milliards de téléchargements hebdomadaires. Ces incidents soulignent pourquoi les équipes de développement, les ingénieurs DevOps et DevSecOps doivent plus que jamais se préoccuper de sécurité de la chaîne d’approvisionnement logicielle .

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 des chaînes logistiques logicielles

1. Paquets malveillants de typosquatting

L'une des attaques de la chaîne d’approvisionnement les plus simples attaques de la chaîne d’approvisionnement typosquattage – où les pirates téléchargent des paquets malveillants vers des registres (npm, PyPI, RubyGems, etc.) en utilisant des noms presque identique aux bibliothèques populaires. L'objectif est d'inciter les développeurs (ou leurs outils automatisés) à installer l'imposteur en saisissant ou en identifiant incorrectement le nom du paquet. Par exemple, des acteurs malveillants ont usurpé l'identité de paquets tels que typescript-eslint sur npm avec des noms tels que @typescript_eslinter/eslint, qui a été téléchargé des milliers de fois avant d'être détecté. Ces faux paquets contiennent souvent des logiciels malveillants cachés : ils peuvent exécuter un script post-installation qui installe un cheval de Troie ou exfiltre des données. Dans un cas, un typosquatteur d'un formateur de code a installé silencieusement un fichier exécutable malveillant (prettier.bat) qui persistait au démarrage de Windows.

Comment ça marche : Les pirates observent les bibliothèques populaires et créent un paquet malveillant dont le nom est un faute d'orthographe courante ou variante. Cela peut être aussi subtil qu'un trait d'union manquant (types-nœud vs le légitime @types/node) ou un espace de noms différent. Ils publient ces paquets dans le référentiel public avec un numéro de version ou une description attrayants. Des développeurs peu méfiants peuvent faire une faute de frappe dans le nom ou choisir le mauvais paquet dans la précipitation, et ainsi télécharger le code malveillant. Les scripts automatisés et les systèmes d'intégration continue sont tout aussi vulnérables si le nom du paquet comporte ne serait-ce qu'une seule erreur de caractère.

Risques : une fois installé, le paquet malveillant s'exécute avec les mêmes privilèges que votre application. Il peut voler des variables d'environnement (secrets), installer des portes dérobées ou télécharger des logiciels malveillants de deuxième niveau. Dans les environnements d'entreprise, une seule dépendance corrompue peut se propager à de nombreuses applications ou services. Ces attaques sont insidieuses, car les développeurs ne se rendent souvent compte de leur erreur qu'une fois le mal fait. La confiance que nous accordons aux gestionnaires de paquets peut être exploitée pour exécuter du code sur les machines des développeurs ou les exécuteurs 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 Aikidopeut détecter automatiquement les paquets malveillants connus et les variantes de typosquatting avant qu'ils ne soient intégrés à votre build. Par exemple, Aikido SafeChain bloque les paquets qui sont tout nouveaux ou connus pour être malveillants, empêchant ainsi ce danger. npm install de réussir. En analysant le manifeste et les fichiers de verrouillage de votre projet, Aikido garantir que réacteur-routeur est bien le véritable React Router, et non un logiciel malveillant qui se fait passer pour lui. Ce type d'analyse proactive et de politique (par exemple, exiger que les paquets aient un certain âge ou une certaine popularité) peut arrêter rapidement les attaques de typosquatting, en préservant la propreté de votre chaîne logistique.

2. Confusion relative aux dépendances (confusion entre les 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 package npm interne appelé @acme/widget-core à la version 1.3.0, hébergée sur un registre privé. Les requêtes package.json de votre projet @acme/widget-coreSi un attaquant publie @acme/widget-core version 9.9.9 vers npm (public) et que votre build n'est pas verrouillé sur la source privée, le gestionnaire de paquets pourrait récupérer la version 9.9.9 à partir du registre public (en 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 lors de l'installation, permettant ainsi l'exécution de code à distance dans votre environnement de compilation. Dans les pipelines CI/CD, cela est particulièrement dangereux : le code s'exécute sur des agents de compilation qui peuvent avoir accès à des variables d'environnement sensibles, au code source et aux clés de déploiement.

Risques : la confusion des dépendances peut compromettre immédiatement l'environnement de développement ou de compilation. La charge utile malveillante pourrait exfiltrer des secrets (clés API, jetons, identifiants) ou injecter des portes dérobées dans l'application compilée sans modifier le code de votre référentiel. Elle contourne efficacement code review traditionnelle code review ou l'analyse des vulnérabilités de votre référentiel, car le code malveillant réside dans une dépendance que vous avez téléchargée à votre insu. L'impact peut être grave : les attaquants pourraient se déplacer latéralement dans les réseaux de l'entreprise (si les serveurs de compilation sont compromis) ou insérer une logique malveillante dans les logiciels livrés aux clients. Il s'agit d'une menace très répandue, étant donné la fréquence des conflits de noms de paquets internes.

Atténuation : La prévention de la confusion des dépendances implique une combinaison de contrôles techniques et hygiène. Toujours définissez explicitement la portée de vos paquets privés et configurez vos gestionnaires de paquets pour privilégier les registres privés pour certains espaces de noms. Les paramètres des gestionnaires de paquets tels que npm @acme:registre dans .npmrc ou les paramètres d'index de pip doivent être utilisés pour verrouiller les dépendances à la source prévue. Utiliser fixation stricte de la version et les fichiers de verrouillage afin que, même si une version supérieure apparaît ailleurs, votre build ne la prenne pas automatiquement. Surveillez les registres publics de paquets pour détecter toute fuite accidentelle de vos noms de paquets internes (les attaquants les devinent souvent grâce aux mentions dans les dépôts publics ou aux fichiers de configuration). De nombreuses organisations utilisent désormais des référentiels d'artefacts comme proxy, afin que seuls les paquets approuvés sont récupérés. Cela crée une barrière qui empêche les paquets inconnus (même si leur nom correspond) d'être intégrés. Enfin, des audits réguliers des configurations de dépendances et la génération d'une SBOM Software Bill of Materials, nomenclature logicielle) peuvent aider à détecter si un paquet externe inattendu s'est glissé dans le système.

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 piratées et logiciels de protestation (responsables compromis)

Toutes attaques de la chaîne d’approvisionnement ne attaques de la chaîne d’approvisionnement pas de nouveaux emballages contrefaits, parfois les paquets de confiance deviennent malveillants en raison du piratage du compte du responsable de maintenance ou d'un sabotage intentionnel. Lorsqu'un pirate prend le contrôle d'un paquet légitime (en hameçonnant le responsable de maintenance, en volant ses identifiants ou en exploitant une faille de sécurité), il peut publier un mise à jour trojanisé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.

Comment ça marche : les pirates ciblent les paquets à fort impact, souvent ceux qui se trouvent au cœur des arborescences de dépendances, afin que les développeurs ne remarquent pas la mise à jour. Les tactiques courantes consistent à hameçonner les identifiants de connexion des responsables (comme dans l'incident npm ci-dessus) ou à exploiter les fuites OAuth/token. Une fois qu'ils ont accès, ils publient une nouvelle version contenant des charges utiles malveillantes. Ces charges utiles peuvent être très sophistiquées. Lors de l'attaque npm de 2025, le code injecté était un voleur de portefeuille cryptographique qui ne s'activait que dans le contexte du navigateur. D'autres portes dérobées peuvent collecter des données sur l'environnement, ouvrir des shells inversés ou crypter des données (à la manière d'un ransomware). Comme la version reste sémantiquement valide (par exemple, 4.4.2 à 4.4.3) et que le paquet fonctionne souvent normalement, mis à part 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 que vous exécutiez un code malveillant sous le couvert d'une dépendance de confiance. Cela peut conduire au vol d'informations sensibles (le malware de l'incident npm ciblait les transactions cryptographiques, mais il aurait tout aussi bien pu cibler les jetons d'authentification ou les données des clients). Cela compromet l'intégrité de votre logiciel : même si votre code est sécurisé, la bibliothèque compromise peut le subvertir complètement. De plus, ces attaques érodent la confiance dans l'écosystème ; les équipes pourraient geler les mises à jour (et passer à côté de correctifs légitimes) par crainte. Dans le pire des cas, un paquet compromis largement utilisé peut servir de porte dérobée vers de nombreuses entreprises à la fois, car il crée essentiellement un botnet de toutes les installations qui communiquent avec l'attaquant.

Atténuation : Il est difficile de se défendre contre les paquets piratés, car il s'agit d'une trahison de confiance. Cependant, il existe des bonnes pratiques pour limiter l'ampleur des dégâts. Traitez les mises à jour des dépendances avec un scepticisme sain : examinez les journaux de modifications et les différences entre les nouvelles versions, en particulier pour les utilitaires de base qui ne sont généralement pas mis à jour souvent. Utilisez un scan automatisé des logiciels malveillants sur les nouvelles versions des paquets : certains outils analysent le comportement des paquets (par exemple, en détectant si une nouvelle version commence soudainement à effectuer des appels réseau ou à lire des informations système). Le verrouillage des versions (et le fait de ne pas passer automatiquement à la dernière version sans examen préalable) peut vous faire gagner du temps pour observer les rapports de la communauté. L'utilisation de fichiers de verrouillage et la vérification des sommes de contrôle (prise en charge par npm, le mode de vérification des hachages de pip, etc.) peuvent vous garantir que vous installez exactement ce que vous attendez. Envisagez également d'activer la double authentification et la vérification sur vos propres paquets si vous en publiez. Du point de vue des processus, tenez à jour un inventaire de vos dépendances (un SBOM) afin de pouvoir identifier rapidement si vous utilisez un paquet compromis et devez réagir.

La surveillance continue des dépendances Aikidobrille ici. Le scanner Aikidone se contente pas de vérifier les CVE connus, il recherche également comportement suspect lié à un colis et les signatures de logiciels malveillants connus dans les dépendances. Par exemple, si une nouvelle version de demandes sur PyPI tente soudainement d'ouvrir des connexions réseau lors de l'installation, Aikido cette anomalie. Aikido renseignement sur les menaces y compris des flux de paquets connus pour avoir été compromis ou détournés) afin de pouvoir vous avertir si une dépendance dans votre chaîne d'approvisionnement est signalée comme sabotée. De plus, avec Aikido, AutoFix et flux de vulnérabilitésSi une version malveillante venait à passer entre les mailles du filet, la plateforme pourrait recommander, voire ouvrir automatiquement, un PR de correction PR revenir à une version sûre ou PR procéder à une mise à niveau. La rapidité est essentielle : Aikido détecter ces incidents à un stade précoce et automatiser votre réponse, réduisant ainsi la durée d'exposition.

4. Secrets et identifiants exposés dans le code ou l'infrastructure de continuous integration (CI)

On dit souvent 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, cloud , clés de signature, etc.) peuvent être aussi dangereux que n'importe quel logiciel malveillant. Pourquoi ? Parce que si un pirate trouve une clé AWS ou un jeton CI/CD valide dans votre dépôt GitHub ou vos journaux de compilation, il peut l'utiliser directement pour infiltrer vos systèmes ou corrompre votre pipeline. Les fuites d'identifiants sont l'une des principales causes 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 contenus 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 paquets privés ou d'introduire des artefacts malveillants dans vos déploiements.

Comment cela se manifeste : Les secrets peuvent être divulgués de nombreuses façons. Un développeur peut accidentellement commettre un .env fichier contenant les mots de passe de la base de données dans un référentiel public. Ou encore, un pipeline CI/CD peut imprimer un jeton sensible dans des journaux accessibles à tous. Plus subtilement, un pirate qui obtient un accès initial peut rechercher des clés codées en dur dans votre base de code. Une fois obtenues, ces informations confidentielles peuvent être utilisées pour usurper l'identité de vos comptes. Par exemple, une clé AWS pourrait permettre à un pirate d'envoyer une image de conteneur corrompue à votre registre ECR privé, que votre déploiement récupérerait ensuite. Un jeton d'accès personnel GitHub pourrait permettre à un pirate informatique de valider du code dans votre référentiel ou de falsifier vos versions. Dans les pipelines CI, si un pirate informatique met la main sur des identifiants pour CI ou cloud, il peut contourner efficacement code review normale code review insérer directement des composants ou une infrastructure malveillants.

Risques : Le risque direct est l'accès non autorisé. cloud exposées peuvent entraîner des violations de l'infrastructure ou le vol de données. Les identifiants de registre de paquets exposés peuvent permettre à un pirate de publier une nouvelle version d'une bibliothèque interne contenant un logiciel malveillant (autre scénario de détournement de paquets). Dans le cadre de l'intégration continue (CI), les jetons divulgués pourraient permettre aux pirates de modifier les configurations de compilation, de récupérer des secrets dans des coffres-forts ou d'intercepter des artefacts. Les secrets sont en quelque sorte des passe-partout : une fois que le pirate les a en sa possession, il peut souvent se déplacer dans vos systèmes sans avoir besoin d'exploiter une vulnérabilité logicielle. Cela peut entraîner des conséquences diverses, allant de la compromission complète de l'environnement de production à la modification silencieuse d'artefacts par les pirates (par exemple, le remplacement d'un fichier binaire dans un pipeline de publication par un fichier binaire contenant une porte dérobée). Ces scénarios font partie des attaques de la chaîne d’approvisionnement l'intégrité du processus de livraison des logiciels est compromise par la perte de confiance.

Atténuation : La meilleure mesure d'atténuation consiste à ne pas divulguer de secrets. Plus facile à dire qu'à faire, mais il existe des pratiques concrètes : utilisez des outils d'analyse des secrets sur vos dépôts pour détecter les clés API ou les mots de passe avant qu'ils ne soient validés. Les fournisseurs Git tels que GitHub ont intégré l'analyse des secrets : activez-la. Ne codifiez jamais d'informations d'identification sensibles dans le code ; utilisez plutôt des variables d'environnement ou des services de gestion des secrets (et assurez-vous que vos dépôts ne contiennent pas ces valeurs dans les fichiers de configuration). Dans CI/CD, masquez les secrets dans les journaux (la plupart des plateformes proposent des options pour empêcher l'impression des variables d'environnement secrètes). Changez régulièrement les clés afin que, en cas de fuite, elles ne soient valides que pendant une courte période. Appliquez le principe du moindre privilège : un jeton divulgué qui n'a qu'un accès en lecture est beaucoup moins dommageable qu'un jeton d'administrateur. Pour les clés à privilèges élevés, appliquez si possible des restrictions multifactorielles ou IP. 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.

détection de secrets Aikidoest conçue pour détecter rapidement les identifiants exposés. Elle analyse votre code, vos fichiers de configuration et même les définitions de pipeline CI à la recherche de modèles correspondant à des clés API, des clés privées, des jetons, etc. Par exemple, si quelqu'un commet accidentellement un jeton d'accès personnel GitHub ou une clé secrète AWS, Aikido le Aikido immédiatement, vous permettant ainsi de le purger et de le faire tourner. Mais la détection n'est qu'une partie de l'histoire : Aikido s'intégrer à votre CI pour faire échouer une compilation si un secret est trouvé, empêchant ainsi le déploiement accidentel d'informations sensibles. Il 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 analyse des secrets le workflow de développement (plugins IDE, hooks pré-commit, vérifications CI), Aikido les développeurs à garder les identifiants hors des référentiels et des pipelines, coupant ainsi l'une des voies les plus faciles utilisées par les attaquants pour compromettre la chaîne d'approvisionnement.

5. Configurations de pipeline CI/CD non sécurisées (le pipeline comme surface d'attaque)

Votre pipeline CI/CD est en quelque sorte la chaîne de montage de votre usine logicielle. S'il est mal configuré ou non sécurisé, les pirates peuvent altérer tout ce qui sort de cette chaîne. Les systèmes CI/CD (tels que GitHub Actions, Jenkins, GitLab CI, etc.) disposent souvent d'un accès étendu : ils extraient le code, intègrent les dépendances, exécutent des tests, poussent les artefacts et vont même jusqu'à les déployer en production. Cela en fait une cible de choix. sécurité des pipelines courants liés sécurité des pipelines comprennent des autorisations 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 logicielles attaques de la chaîne d’approvisionnement les vulnérabilités de la construction CI/CD, soulignant à quel point sécurité des pipelines désormais un enjeu majeur. Dans la 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é ouvert à Internet ou une tâche CI qui exécute par inadvertance du code non fiable (par exemple, la création de PR à partir de contributeurs externes sans sandboxing) peut conduire à une compromission.

Comment cela se manifeste : un scénario possible est celui des pipelines exécutés avec des privilèges excessifs. Imaginez un agent CI qui dispose d'un accès administrateur à votre cloud qui est autorisé à déployer directement des artefacts. Si un pirate parvient à s'introduire dans le CI (par injection de code, compromission d'identifiants ou exploitation de l'outil CI), il détient alors les « clés du royaume » : il peut injecter des logiciels malveillants dans les builds, voire utiliser l'agent CI pour exécuter des commandes dans votre infrastructure. Un autre scénario consiste à ne pas appliquer de contrôles sur le code entrant : par exemple, une requête de tirage malveillante contenant une modification de la configuration CI visant à exfiltrer des secrets ou à ignorer des tests pourrait passer inaperçue si les revues de code sont laxistes. De plus, de nombreux pipelines CI montent des secrets (tels que des clés de signature ou des identifiants 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 est exécuté, ces secrets peuvent être volés par des attaquants qui manipulent le build. Par exemple, certaines configurations par défaut peuvent permettre aux PR de dépôts fourchus d'exécuter le CI principal avec un accès aux secrets, un paramètre dangereux connu qui peut divulguer des secrets à des contributeurs malveillants.

Risques : si le pipeline CI/CD est compromis, cela donne à un pirate un accès direct pour compromettre le logiciel au moment de la compilation ou du déploiement. Cela pourrait entraîner l'envoi de code non autorisé à la production ou aux utilisateurs (imaginez un code malveillant ajouté pendant la compilation qui n'existait pas dans le contrôle de source). Cela peut également conduire à une exposition généralisée des données ; les systèmes CI contiennent souvent des journaux ou des artefacts contenant des informations sensibles. Un pipeline non sécurisé peut être utilisé à des fins malveillantes pour accéder à d'autres ressources. Par exemple, si votre serveur Jenkins dispose d'un accès réseau aux services internes, un pirate informatique qui parvient à compromettre Jenkins peut alors exploiter ces services. En substance, un CI vulnérable constitue un point d'entrée à la fois vers votre produit logiciel et vers votre infrastructure. Il s'agit également d'un domaine souvent négligé : les équipes de développement se concentrent sur la sécurité du code des applications, mais n'examinent pas toujours le pipeline avec la même rigueur.

Atténuation : pour sécuriser les pipelines CI/CD, il faut les traiter comme des actifs de production. Tout d'abord, verrouillez l'accès: assurez-vous que votre système CI n'est pas accessible à tous, utilisez des VPN ou des listes d'autorisation d'adresses IP, et exigez une authentification pour déclencher les tâches sensibles. Appliquez le principe du moindre privilège aux identifiants des pipelines. Par exemple, si une tâche de compilation nécessite uniquement un accès en écriture à un référentiel d'artefacts, ne lui accordez pas également des droits cloud . Utilisez des identifiants distincts pour chaque tâche/étape. Ensuite, assainissez les entrées: pour les workflows publics (comme les projets open source où tout le monde 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 bifurqués. Activez la journalisation d'audit sur votre pipeline : sachez qui a modifié quoi dans les configurations de build. Une autre pratique clé consiste à é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 ») afin d'empêcher un attaquant de remplacer quelque chose (plus d'informations à ce sujet dans la section suivante). Mettez régulièrement à jour votre logiciel et vos plugins CI, car des vulnérabilités apparaissent dans les outils CI eux-mêmes. Enfin, envisagez d'utiliser des runners isolés éphémères pour chaque build (lorsque cela est possible) afin qu'un build compromis ne permette pas à l'attaquant de conserver un point d'ancrage.

Aikido sécurité CI/CD qui vous aide à auditer vos configurations de pipeline afin d'identifier les meilleures pratiques et les éventuelles erreurs de configuration. Par exemple, Aikido analyser vos workflows GitHub Actions ou vos fichiers Jenkins afin de signaler des problèmes tels que des actions non épinglées, l'utilisation de runners auto-hébergés avec des autorisations étendues ou des secrets exposés à des PR fourchues. Il agit comme un linter pour la sécurité CI. La plateforme Aikidos'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 un PR, Aikido exiger des autorisations supplémentaires. En analysant en permanence la configuration du pipeline, Aikido garantir la sécurité de votre « usine logicielle » : aucune porte ouverte, aucun moyen facile 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 toxiques des pipelines (outils et actions CI/CD tiers)

Les pipelines modernes transportent souvent une grande variété de outils tiers, images Docker, scripts et actions pour effectuer des tâches (comme la couverture de code, les déploiements, etc.). Chacune d'entre elles constitue une dépendance implicite dans votre chaîne d'approvisionnement. Si l'une d'entre elles est malveillante ou compromise, votre pipeline (et le logiciel qui en résulte) peut être compromis. Un exemple frappant de cela a été le attaque contre le reviewdog/configuration-de-l'action Action GitHub et compromission subséquente de tj-actions/changed-files en 2025. Les pirates 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 d'informations confidentielles provenant des exécuteurs CI de tous les projets qui les utilisaient. De même, prenons l'exemple des scripts de pipeline tels que l'uploader Codecov Bash (qui a été piraté en 2021) : des milliers de pipelines faisaient confiance à un outil qui exfiltrait silencieusement leurs données. Ces incidents illustrent comment un pirate peut empoisonner le puits en ciblant les outils sur lesquels repose votre pipeline.

Comment ça marche : Les pirates recherchent des utilitaires ou des images CI/CD populaires qui présentent des faiblesses dans la chaîne d'approvisionnement, par exemple un responsable qui ne signe pas les commits ou une dépendance obsolète dans une image Docker. En compromettant le projet en amont (via le piratage d'un compte, l'exploitation d'une faille ou l'infiltration en tant que contributeur), ils peuvent insérer du code malveillant. Dans le cas de GitHub Actions, un pirate a obtenu l'accès au compte ou au jeton des responsables et modifié le code d'action, allant même jusqu'à renommer les références Git afin que ce qui était tagué « v1 » pointe désormais vers un commit malveillant. Les projets utilisant utilisations : reviewdog/action-setup@v1 dans leur flux de travail a soudainement effectué une action malveillante qui a divulgué des secrets. Étant donné que les systèmes d'intégration continue récupèrent généralement le dernier code balisé à chaque exécution, un pipeline peut, à l'insu de tous, exécuter un code modifié provenant d'un tiers. Les images Docker utilisées dans l'intégration continue (pour la compilation ou les tests) sont également exposées à ce risque : si quelqu'un pousse une mise à jour malveillante vers une image telle que nœud : alpin que votre pipeline utilise, vous exécuteriez tout ce qui se trouve dans cette image.

Risques : l'impact ici est similaire à celui d'un détournement de bibliothèque, mais potentiellement encore plus direct. Les outils CI fonctionnent souvent avec des privilèges élevés (certains runners GitHub ont sudo, etc.) et ont accès aux identifiants. Une action ou un script corrompu peut immédiatement exfiltrer tous les secrets de votre environnement ou injecter des portes dérobées dans le code en cours de compilation/test. Dans un incident réel, une action GitHub malveillante a vidé des secrets CI dans des journaux publics. Un autre risque est qu'un outil de compilation compromis puisse modifier le résultat compilé (imaginez un compilateur malveillant qui insère toujours une certaine vulnérabilité ou une porte dérobée dans les binaires). La difficulté pour les défenseurs réside dans le fait que ces dépendances de pipeline ne sont peut-être pas aussi bien contrôlées que vos dépendances de code : de nombreuses équipes font aveuglément confiance à une image Docker ou à une action open source parce qu'elles sont largement utilisées. Cela donne aux attaquants un moyen discret de s'introduire, et la brèche peut ne pas être découverte avant longtemps (voire jamais).

Atténuation : Tout comme vous épinglez les dépendances d'une application, épingler vos dépendances de pipelineDans 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 vous garantit d'utiliser à chaque fois une version dont la fiabilité est avérée. Ensuite, vérifiez et faites confiance, mais vérifiez : privilégiez les actions ou les outils qui jouissent d'une large confiance. et Disposez idéalement d'un mécanisme de vérification (certaines actions sont vérifiées par GitHub ou font l'objet d'une signature). Surveillez les notifications en amont : abonnez-vous aux flux de sécurité des outils tiers que vous utilisez afin d'être alerté en cas de compromission. Dans la mesure du possible, hébergez vous-même ou faites héberger par un fournisseur les outils critiques de votre pipeline : par exemple, au lieu de récupérer un script aléatoire sur 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 en exécutant des linters ou des outils de couverture de test dans des conteneurs isolés à accès limité. Enfin, envisagez d'adopter des cadres tels que le SLSA (Supply Chain Levels for Software Artifacts) de Google pour vos pipelines, qui fournissent des lignes directrices pour renforcer les processus de construction et exigent la provenance des étapes de construction.

🛡 Appel à Aikido : Le scan CI/CD Aikidos'étend également au dépendances de votre pipeline. Il vérifiera si vos flux de travail font référence à des actions avec des balises modifiables ou s'ils proviennent de sources potentiellement non fiables. Par exemple, Aikido signaler que vous utilisez utilisations : someaction@latest et suggérer de l'épingler à un commit. Le scanner de dépendances Aikidone se contente pas d'examiner le code de votre application ; il peut également analyser votre Construire des conteneurs et des outils pour détecter les vulnérabilités connues ou les signatures de logiciels malveillants. Si vous utilisez une image Docker de base dans CI, Aikido analyser SBOM de cette image SBOM s'assurer qu'elle ne contient pas de composants malveillants connus. En substance, Aikido garantir que les composants de votre pipeline sont aussi sûrs que ceux de votre application. En intégrant ces vérifications, Aikido que vos outils et actions CI ne constituent pas une porte dérobée cachée. Dans le cas où un outil populaire fait Si votre infrastructure était compromise, renseignement sur les menaces Aikido renseignement sur les menaces mis à jour et vous recevriez une alerte si vos pipelines étaient affectés, ce qui vous permettrait de réagir rapidement (par exemple, en suspendant le pipeline, en effectuant une mise à jour vers une version sécurisée) avant que des dommages ne soient causés.

7. Versions non épinglées et dépendances modifiables (le problème des « dernières versions »)

Utilisation de flottant ou versions de dépendances non épinglées est une vulnérabilité de la chaîne d'approvisionnement qui peut vous nuire de deux façons : vous pourriez, sans le savoir, récupérer un mise à jour malveillante ou mise à jour boguée/vulnérable parce que vous récupérez toujours la « dernière version ». Qu'il s'agisse d'une image de base Docker taguée :latest ou une plage de versions de paquets telle que ^1.0.0 Dans npm, l'utilisation de versions non fixes signifie que votre build d'aujourd'hui pourrait récupérer un composant différent de celui d'hier. Cela nuit à la reproductibilité du build et permet aux attaquants de synchroniser leurs actions. Par exemple, si un attaquant compromet un paquet et que vous n'êtes pas lié à une version spécifique connue pour être fiable, votre prochain build récupérera la version compromise. Dans l'attaque GitHub Actions évoquée précédemment, l'un des facteurs contributifs était que les projets faisaient référence à une balise modifiable (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 balise d'affecter les builds.

Comment ça marche : Considérons un projet Python qui utilise requêtes >= 2,0 dans ses exigences (autorisant toute nouvelle version 2.x). Lorsque vous effectuez une installation pip, le programme récupère la dernière version 2.x disponible. Si les responsables de la maintenance (ou un pirate) publient demandes 2 999 demain et qu'il y a des problèmes, votre environnement change de manière inattendue. Ou imaginez que votre Dockerfile utilise À PARTIR DE node:latest; chaque fois que l'équipe Node met à jour cette image (ou si un pirate parvient à pousser une image similaire), vos builds récupèrent une nouvelle image dont le contenu peut être différent. Les dépendances non épinglées confient essentiellement le contrôle de votre chaîne d'approvisionnement aux calendriers de parties externes. Les pirates apprécient particulièrement cette situation s'ils parviennent à pousser une mise à jour, car ils savent que de nombreux utilisateurs effectueront une mise à niveau automatique. Même en l'absence d'acteur malveillant, il existe un risque qu'une mauvaise mise à jour provoque des pannes ou introduise une faille de sécurité avant que vous ne vous en rendiez compte. Le tristement célèbre incident du left-pad (où la suppression d'un paquet a entraîné des échecs de compilation à l'échelle mondiale) est un exemple de ce qui peut arriver lorsque de nombreux projets font implicitement confiance à une dernière version externe.

Risques : Le principal risque réside dans le manque de contrôle et de visibilité. Vous pouvez penser que vous compilez le même code, mais en réalité, une bibliothèque ou une image sous-jacente a changé. Ce changement peut constituer une vulnérabilité critique (si vous avez effectué une mise à niveau automatique vers une version comportant un nouveau CVE) ou une logique malveillante. Dans attaques de la chaîne d’approvisionnement, le timing est essentiel : si l'adversaire parvient à introduire brièvement une mauvaise version pendant que vous compilez, il gagne, même si cette version est corrigée par la suite. 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 une compilation donnée, il est difficile de savoir si vous avez été affecté par une version malveillante ou vulnérable. Essentiellement, cela nuit à la reproductibilité et à la traçabilité qui sont fondamentales pour sécuriser les compilations. L'intégrité des compilations logicielles dépend de la présence d'entrées déterministes ; « dernière version » est le contraire de déterministe.

Atténuation : fixez ou verrouillez toujours vos dépendances à des versions ou des résumés connus pour être fiables. Utilisez des numéros de version exacts dans les manifestes des paquets et employez des fichiers de verrouillage (package-lock.json, Pipfile.lock, etc.) afin que tout le monde et tous les environnements utilisent les mêmes versions résolues. Pour les images Docker, fixez une version spécifique ou, mieux encore, un résumé SHA (qui est immuable). Pour les dépendances ou les actions basées sur Git, fixez des hachages de validation. Si vous devez autoriser des plages (pour obtenir des mises à jour mineures), envisagez d'utiliser des robots fiables ou des outils de mise à jour qui vous alertent des nouvelles versions plutôt que de les télécharger automatiquement. Mettez en place une politique selon laquelle aucune compilation ne doit utiliser un artefact qui n'est pas explicitement suivi dans le contrôle de source (ou dans un fichier de métadonnées). De plus, conservez une 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 rechercher quelles versions de votre produit incluaient cette version. Il est également judicieux de tester séparément votre processus de mise à jour des dépendances. Ne procédez pas à des mises à jour aveuglément dans les builds de production. Disposez d'une tâche de staging ou 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 effectuer la mise à niveau après vérification, plutôt que d'être surpris par les changements en amont.

Les outils Aikidoencouragent fortement fixation des dépendances et visibilité des versionsLorsque Aikido une SBOM votre projet, il répertorie tous les composants et toutes les versions, ce qui permet de s'assurer qu'il n'y a pas de dépendances « flottantes ». Aikido également s'intégrer à votre CI pour Échecs de compilation utilisant des dépendances non épinglées ou des balises modifiables, qui agissent comme un filet de sécurité. Par exemple, si quelqu'un introduit FROM python:latest dans un fichier Dockerfile ou ajoute une action GitHub sans SHA épinglé, le scanner Aikidole signalera. De plus, les fonctionnalités de gestion des dépendances Aikidopeuvent automatiquement ouvrir 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 restiez pas bloqué sur d'anciennes versions, mais que vous puissiez effectuer des mises à niveau en toute sécurité. En utilisant Aikido surveiller et gérer vos composants open source, vous bénéficiez d'un bouclier efficace qui garantit vous savez exactement ce que vous construisezCette connaissance est source de pouvoir (et de sécurité).

8. Composants obsolètes présentant des vulnérabilités connues

À l'opposé des problèmes « récents », il existe le risque d'utiliser des dépendances obsolètes présentant des vulnérabilités de sécurité connues (CVE). Il s'agit davantage d'une vulnérabilité traditionnelle, mais cela concerne tout à fait la chaîne logistique : la sécurité de votre logiciel dépend du maillon le plus faible de son graphe de dépendances. Les pirates exploitent souvent les failles bien connues des bibliothèques populaires que les organisations tardent à corriger. Par exemple, l'utilisation d'une ancienne version d'une bibliothèque Struts, Log4j ou OpenSSL présentant une CVE critique rendue publique peut entraîner l'exécution de code à distance ou une violation de données dans votre application, ce qui revient en fait à un défaut de mise à jour de la chaîne logistique. Avec l'explosion de l'open source, il est difficile de tout maintenir à jour ; cependant, analyse de la composition logicielle (SCA) montrent systématiquement qu'un pourcentage important d'applications contiennent des bibliothèques obsolètes présentant des failles connues. Si vous incluez un composant open source vulnérable, un attaquant n'aura peut-être pas besoin d'écrire un nouvel exploit : il pourra simplement exploiter la CVE existante à votre détriment.

Comment cela se manifeste : Souvent, les équipes de développement incluent une bibliothèque pour certaines fonctionnalités, puis oublier de le mettre à jourCette bibliothèque peut en impliquer d'autres (dépendances transitives), et quelque part dans cette chaîne, il peut y avoir un bug critique. Prenons par exemple une application Node.js qui utilise un paquet dépendant d'une version obsolète de lodash version présentant une vulnérabilité liée à la pollution des prototypes. Votre application pourrait être exploitée via cette vulnérabilité même si votre code est correct. Dans les outils CI/CD et de compilation, des composants obsolètes peuvent également se cacher : votre conteneur de compilation contient peut-être un ancien package OS avec un bug shellshock, ou votre serveur CI lui-même n'est pas mis à jour. Cela se manifeste généralement par la détection d'une vulnérabilité CVE connue par un scanner ou un test de pénétration, ou pire, par la survenue d'un incident (par exemple, l'application est piratée via ce composant). Un cas notoire a été celui de Vulnérabilité « Log4Shell » de Log4j (CVE-2021-44228); de nombreuses organisations ont été prises au dépourvu en utilisant d'anciennes versions de Log4j et ont été victimes d'exploits dans la nature. 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 pirates savent déjà comment les exploiter. Lorsqu'une vulnérabilité est rendue publique, elle s'accompagne souvent d'exploits de preuve de concept ou, à tout le moins, de descriptions détaillées. Les pirates parcourent Internet à la recherche d'applications ou de services qui semblent utiliser le composant vulnérable (par exemple, en vérifiant les en-têtes des applications ou certains comportements spécifiques). Si votre logiciel utilise ce composant et qu'il est exposé de manière appropriée, vous êtes une cible. Cela peut entraîner une compromission totale du système, un vol de données ou des interruptions de service, selon la vulnérabilité. Outre l'exploitation directe, il existe également des problèmes de conformité et de confiance des clients : l'utilisation de vulnérabilités connues peut enfreindre les réglementations ou les exigences contractuelles en matière de sécurité. 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 utilisez ; négliger les mises à jour revient à laisser des failles dans vos défenses qui sont bien documentées dans les manuels des attaquants.

Atténuation : Adoptez une culture de gestion continue des dépendances. Cela signifie qu'il faut régulièrement analyser vos projets (et images de conteneurs) à la recherche de vulnérabilités connues. Utilisez SCA pour signaler lorsqu'une version de dépendance présente une vulnérabilité CVE. De nombreux gestionnaires de paquets disposent désormais de commandes d'audit (par exemple, audit npm, pip audit) pour répertorier les paquets vulnérables. Intégrez cette étape au processus d'intégration continue (CI) afin que les builds émettent un avertissement ou échouent si de nouvelles vulnérabilités sont introduites. Mettez en place un processus (éventuellement automatisé via des bots tels que Dependabot AutoFix Aikido) pour demander la mise à niveau vers les versions corrigées. Il est important d'établir des priorités, car toutes les CVE ne se valent pas. Concentrez-vous sur celles qui présentent un niveau de gravité élevé ou qui concernent des logiciels accessibles depuis votre application. Veillez également à Mettez à jour votre environnement de compilation 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 les versions corrigées. Un autre élément clé est de maintenir un nomenclature (SBOM) Comme mentionné précédemment, cela vous aide à répondre rapidement à la question « utilisons-nous la bibliothèque qui fait tant parler d'elle cette semaine ? ». Lorsque Log4Shell a frappé, les organisations disposant d'un bon SBOM Le processus a permis de rechercher et de trouver immédiatement où Log4j était utilisé. Enfin, abonnez-vous aux bulletins de sécurité des principaux projets que vous utilisez afin d'être averti dès qu'une nouvelle vulnérabilité apparaît. Il est essentiel d'appliquer rapidement les correctifs, car les pirates commencent souvent à exploiter les CVE courants quelques jours, voire quelques heures après leur annonce.

Le scanner de dépendances et SCA Aikidosont conçus pour résoudre précisément ce problème. Il analyse vos projets afin d'identifier tous les composants open source et les compare à une base de données de vulnérabilités mise à jour en permanence. Le résultat n'est pas seulement une liste de problèmes : Aikido des informations exploitables telles que la gravité, l'existence d'un correctif disponible et même un Fonction 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 présentant une faille critique, Aikido vous suggérer la version sécurisée et mettre à jour votre pom.xml pour vous. De plus, Aikido à l'ensemble de votre flux de travail de développement (plugins IDE, PR , CI) afin que les vulnérabilités connues soient détectées rapidement, avant même que votre logiciel ne soit mis en production. Il vous aide également à générer facilement des SBOM, vous offrant ainsi une visibilité sur le contenu de votre logiciel. Ainsi, lorsque la prochaine faille zero-day dans une bibliothèque courante fera la une des journaux, vous pourrez rapidement consulter votre Aikido pour voir si vous êtes concerné. Rester au courant des mises à jour devient beaucoup plus facile lorsque Aikido veille Aikido sur vous, en veillant à ce que les composants obsolètes ne restent pas sans solution.

9. Absence de vérification de l'intégrité (signature et validation de l'origine insuffisantes)

La dernière vulnérabilité à souligner est de nature plus systémique : l'absence de vérification de l'intégrité et de l'origine des composants. En d'autres termes, le fait de 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 logistique logicielle. Sans vérification de l'intégrité, vous faites essentiellement confiance par défaut. Les attaquants peuvent exploiter cette faille en altérant des artefacts ou en usurpant l'identité de sources. Par exemple, si vous téléchargez une bibliothèque ou un programme d'installation tiers via un protocole HTTP simple ou à partir d'un site miroir sans vérifier le hachage/la signature, un attaquant intermédiaire pourrait vous fournir 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 contenant une porte dérobée. Même dans le cadre du CI/CD, l'absence de vérification signifie que si un attaquant compromet une étape, les étapes suivantes pourraient faire aveuglément confiance aux résultats. Un cas illustratif dans le monde Docker a été l'attaque « Ghostwriting » ou falsification de couche d'image, où le contenu d'une image a été modifié sans changer son résumé 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 sans se faire remarquer.

Comment cela fonctionne : la signature et la vérification des codes constituent ici les principales défenses. De nombreux écosystèmes de paquets prennent désormais en charge la signature des 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 ces mesures ne sont pas utilisées ou appliquées, un pirate capable d'intercepter le trafic réseau ou de compromettre un pipeline de compilation pourrait insérer des artefacts malveillants qui seraient acceptés comme authentiques. L'absence de vérification de l'intégrité inclut également le fait de ne pas vérifier 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 à celle publiée par le fournisseur. Dans le cadre de l'intégration continue, le fait de ne pas vérifier l'identité de la source (par exemple, ne pas vérifier qu'un commit Git est signé ou provient du référentiel attendu) peut conduire à l'intégration d'un code erroné. Ce scénario correspond 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 un logiciel malveillant pendant une courte période, ou compromettre un serveur de build pour modifier les binaires après la compilation. Si vous ne vérifiez pas les signatures/hachages, vous ne vous en rendrez pas compte.

Risques : Le risque évident est une compromission totale de l'intégrité du logiciel. Vous pourriez distribuer un logiciel qui a été altéré par des pirates, compromettant ainsi toutes les autres mesures de sécurité. Cela est particulièrement préoccupant pour les fichiers d'installation, les mises à jour ou les images de conteneurs qui sont largement diffusés : une attaque à ce niveau peut avoir un rayon d'action considérable (à l'instar de l'incident SolarWinds, où la compromission d'un système de compilation a conduit à une mise à jour logicielle contenant un cheval de Troie). Un autre risque concerne 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 la part de l'industrie et des régulateurs en faveur d'une provenance vérifiée (par exemple, le décret américain sur la sécurité des logiciels exige la vérification de l'intégrité via SBOM des signatures). L'absence de vérification peut également permettre des attaques plus simples, telles que la substitution de dépendances (un attaquant remplace un fichier ou une bibliothèque sur votre machine de compilation parce que vous ne le vérifiez jamais). En substance, ne pas vérifier revient à inviter les attaquants à faire preuve de créativité, car vous ne les repérerez que si quelque chose se brise de manière flagrante : les modifications discrètes passent inaperçues.

Atténuation : commencez à adopter des pratiques de signature et de vérification dans votre cycle de développement. Activez la signature GPG ou Sigstore pour les paquets et les conteneurs que vous créez et distribuez, et vérifiez de la même manière les signatures des éléments que vous utilisez. Par exemple, avant d'utiliser un binaire provenant d'une version, vérifiez sa signature GPG ou comparez au moins son hachage SHA-256 avec celui officiel. Dans les déploiements de conteneurs, utilisez des outils tels que 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 le principe du « zero trust » pour les artefacts: ce n'est pas parce qu'un fichier se trouve sur votre réseau qu'il est sûr, vérifiez-le. Utilisez le protocole HTTPS pour tous les téléchargements de paquets et d'artefacts (la plupart le font par défaut aujourd'hui, mais assurez-vous que personne ne le désactive). Pour les processus de compilation internes, envisagez des techniques telles que les compilations reproductibles et le stockage des hachages des résultats de compilation afin de détecter toute altération. L'utilisation d'un contrôle d'admission dans l'intégration continue ou le déploiement qui stipule « n'autoriser que les artefacts dont les sommes de contrôle ou les signatures sont connues pour être valides » peut constituer 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, afin que les développeurs n'aient pas à cliquer manuellement sur « OK » pour les avertissements, mais que le pipeline refuse plutôt le code non vérifié.

Aikido renforcer l'intégrité de multiples façons. Grâce à son SBOM et à son intégration avec des outils de signature, Aikido vérifier que vos dépendances et vos conteneurs sont bien ce qu'ils prétendent être. Par exemple, Aikido s'intégrer à Sigstore/cosign pour s'assurer que toute image de conteneur déployée via votre pipeline dispose d'une signature valide de votre organisation. Si ce n'est pas le cas, il la signale ou la bloque. La plateforme Aikidosuit également les sommes de contrôle des composants analysés ; si le contenu d'un artefact change de manière inattendue (ne correspond pas à la SBOM l'analyse précédente), cela déclenche une alerte rouge. De plus, la base de données et les politiques de vulnérabilité Aikidoincluent des vérifications telles que « ce paquet provient-il d'une source officielle ? », ce qui couvre indirectement l'intégrité (si quelqu'un introduit une fausse source de paquet, Aikido le Aikido grâce à des incohérences dans les métadonnées). En intégrant Aikido, les équipes bénéficient d'un contrôleur d'intégrité automatisé. Il garantit que chaque élément, de la validation du code à la construction et au déploiement de l'artefact, peut être tracé et considéré comme fiable. Associé à d'autres pratiques (analyse, gestion des secrets , etc.), cela donne aux développeurs l'assurance que leur chaîne logistique logicielle est sécurisée de bout en bout, Aikido chaque maillon de la chaîne.

Conclusion : sécurisez votre chaîne d'approvisionnement dès le premier jour

attaques de la chaîne d’approvisionnement logicielles attaques de la chaîne d’approvisionnement sembler complexes, mais comme nous l'avons vu, elles exploitent souvent des failles assez basiques : dépendances non vérifiées, pipelines non sécurisés, fuites d'identifiants et artefacts non vérifiés. La bonne nouvelle, c'est qu'en étant conscientes de ces types de vulnérabilités courantes, les équipes de développement peuvent prendre des mesures proactives pour combler les failles. La sécurité n'est pas le travail de quelqu'un d'autre en aval : elle commence dès le premier jour du développement et se poursuit à chaque commit, build et déploiement. Adopter une approche de la sécurité conviviale pour les développeurs signifie intégrer des pratiques telles que analyse des dépendances, détection de secrets et l'audit CI/CD dans votre flux de travail quotidien, plutôt que de les traiter comme des éléments secondaires.

Les menaces sont réelles et croissantes, qu'il s'agisse de paquets npm malveillants ou de violations de pipelines CI, mais avec le bon état d'esprit et les bons outils, vous pouvez garder une longueur d'avance. Encouragez votre équipe à adopter de bonnes pratiques en matière de « chaîne logistique » : vérifiez ce que vous importez, alternez et protégez les secrets, verrouillez votre processus de compilation et vérifiez tout. Automatisez autant que possible à l'aide DevSecOps modernes. En fait, tirez parti de plateformes telles que Aikido peut grandement faciliter cette tâche. Aikido comme votre assistant de sécurité intelligent, détectant rapidement les dépendances et configurations risquées, et vous guidant vers des correctifs (souvent automatisés) avant qu'elles ne se transforment en incidents.

N'attendez pas qu'une attaque faisant la une des journaux vous oblige à agir. Prenez sécurité de la chaîne d’approvisionnement logicielle en main sécurité de la chaîne d’approvisionnement logicielle . Commencez par intégrer des outils de sécurité dans votre pipeline CI/CD et votre IDE. Vous pouvez par exemple essayer la boîte à outils gratuite pour développeurs Aikidoafin d'analyser vos dépendances et vos pipelines à la recherche de vulnérabilités et de secrets. Sensibilisez vos développeurs à ces menaces afin qu'ils deviennent des acteurs de la protection, et non de simples consommateurs d'open source. Grâce à votre vigilance et à l'aide automatisation de la sécurité intelligente automatisation de la sécurité, vous pouvez fournir des logiciels en étant sûr que votre chaîne d'approvisionnement, du code au cloud est résistante aux attaques. Le codage et la construction sécurisés ne sont pas un obstacle à la vitesse, mais un investissement dans la confiance et la fiabilité de votre produit. Donnez à votre équipe les moyens d'adopter ces pratiques dès aujourd'hui et vous réduirez considérablement le risque de devenir le prochain exemple à ne pas suivre en matière de chaîne d'approvisionnement. Bon codage (et en toute sécurité) !

Continuer la lecture :
Top 9 sécurité des conteneurs Docker
Top 7 des vulnérabilités Cloud
Top 10 des vulnérabilités de sécurité des applications web que toutes les équipes devraient connaître
Top 9 sécurité Kubernetes et erreurs sécurité Kubernetes
Principales vulnérabilités de sécurité du code détectées dans les applications modernes
Top 10 des vulnérabilités de sécurité Python que les développeurs devraient éviter
Principales vulnérabilités de sécurité JavaScript dans les applications web modernes    ‍