Les attaques visant la chaîne d'approvisionnement de logiciels sont de plus en plus fréquentes et dévastatrices. Par exemple : Gartner prédit que 45 % de toutes les entreprises subiront une violation d'ici 2025. De plus, Cybersecurity Ventures souligne la gravité de cette menace, projetant des dommages annuels stupéfiants de 138 milliards de dollars d'ici 2031. Dans l'ensemble, ces prévisions soulignent le besoin urgent pour les organisations de donner la priorité software supply chain security et mettre en œuvre des mesures robustes pour protéger les données sensibles, les opérations et la réputation.
Parce que moderne pipelineLa forte dépendance aux composants externes, l'essor des bibliothèques tierces, les cycles de développement logiciel plus rapides, les chaînes d'approvisionnement complexes, le manque de visibilité, les nouvelles techniques d'attaque, l'adoption du SaaS et les ressources limitées sont autant de facteurs qui expliquent cette augmentation. attaques de la chaîne d'approvisionnement logiciellePar conséquent, les organisations doivent adopter une approche globale et active pour relever ces défis et protéger leurs chaînes d’approvisionnement en logiciels.
Qu’est-ce qu’une attaque contre la chaîne d’approvisionnement logicielle ?
L'ENISA définit une Attaque de la chaîne d'approvisionnement de logiciels as « une compromission d'un actif particulier, par exemple l'infrastructure et les logiciels commerciaux d'un fournisseur de logiciels, pour nuire indirectement à une ou plusieurs cibles particulières, par exemple les clients du fournisseur de logiciels. » En d'autres termes, une attaque de la chaîne d'approvisionnement logicielle est une activité malveillante ciblant la chaîne d'approvisionnement logicielle, visant à compromettre et à introduire des vulnérabilités ou des logiciels malveillants dans le processus de développement et de distribution. Ce type d'attaque exploite ainsi le réseau interconnecté et souvent complexe de processus, d'outils et d'entités impliqués dans la création et la distribution de logiciels.
Composants et concepts clés liés à une attaque de la chaîne d'approvisionnement logicielle
Les renseignements sur les cybermenaces et la littérature sur la sécurité informatique sont souvent défaillants attaques de la chaîne d'approvisionnement logicielle en catégories distinctes pour une meilleure analyse et une meilleure défense. En conséquence, cette section présente les cinq concepts clés définis par la Catalogue de modèles d'attaque MITRECe catalogue structure les modèles d'attaque de la chaîne d'approvisionnement pour faciliter l'analyse à l'aide de diverses sources, y compris les menaces adverses recueillies par le NIST.
Loi d'attaque : le quoi
L'attaque est l'action spécifique qui délivre une charge utile ou une intention malveillante à un système. Elle produit ainsi un dommage direct.
- Exemple 1 : logiciel malveillant inséré dans le logiciel système pendant le processus de création.
- Exemple 2 : Les exigences système ou les documents de conception ont été modifiés de manière malveillante.
Vecteur d'attaque : le comment
Le vecteur d'attaque est la méthode utilisée par les adversaires pour exploiter les vulnérabilités ou les faiblesses des processus. Il montre ainsi comment les attaquants accèdent à la surface d'attaque et l'exploitent.
- Exemple 1 : un attaquant modifie le code source dans un référentiel compromis.
- Exemple 2 : un attaquant obtient un accès non autorisé à la documentation technique interne.
Explorez plus loin dans notre Glossaire des vecteurs d'attaque pour des informations supplémentaires.
Origine de l'attaque : The Who
L'origine identifie la source de l'attaque. Elle clarifie ainsi le rôle, le statut ou la relation de l'attaquant avec le système.
- Exemple 1 : un initié disposant d’un accès privilégié aux serveurs de build modifie un script.
- Exemple 2 : un acteur de menace externe télécharge un package trojanisé dans un registre public.
Objectif de l'attaque : le pourquoi
L'objectif explique la raison de l'attaque. Surtout, il met en évidence les objectifs des adversaires.
- Perturbation : arrêt des services ou des constructions.
- Corruption : réduire la confiance en modifiant les artefacts ou le code source.
- Divulgation : divulgation de secrets sensibles ou de propriété intellectuelle.
Impact de l'attaque : les conséquences
Enfin, l’impact décrit les résultats d’une attaque, montrant les conséquences pour les fournisseurs de logiciels et les clients.
- Exemple 1 : Tout projet qui utilise un mauvais programme sera corrompu plus tard.
- Exemple 2 : Les gens installent des logiciels malveillants dans leurs systèmes de travail sans le savoir.
Attaques de chaîne d’approvisionnement logicielle les plus courantes
De nombreux types de attaques de la chaîne d'approvisionnement logicielle existent, et les organisations doivent être conscientes des différents vecteurs de menaces à chaque étape du cycle de vie. le cadre SLSA, l'Institut national américain de Standards et technologie (NIST) et l'Agence de cybersécurité et de sécurité des infrastructures (CISA), ces menaces peuvent être regroupées en quatre catégories : risques liés à la source, à la construction, au package et aux dépendances.
Attaques de la chaîne d'approvisionnement logicielle au stade de la source
- Soumettre un code incorrect → voir comment Utilisation abusive de la demande Flask.get or défauts de désérialisation non sécurisée créer des surfaces d'attaque directe.
- Dépôt de sources de compromis
- Construire à partir d'une source modifiée
- Écrire du code non sécurisé
- Altération de fichiers critiques → comme expliqué dans analyse de la porte dérobée chmod 777.
Attaques de la chaîne d'approvisionnement logicielle en phase de développement
Dans l' Étape de construction, les développeurs compilent et intègrent le code dans une version fonctionnelle. Parce que cette phase est si critique que les risques incluent le fait de sauter les contrôles de sécurité dans le CI/CD pipeline, modifier le code après le contrôle de version ou compromettre le processus de construction. Ainsi,, un code malveillant peut s'infiltrer dans les artefacts sans être remarqué.
- Bypass CI/CD → lié à Logiciel malveillant pré-compilé sur GitHub.
- Modifier le code après le contrôle de source
- Processus de construction compromis → atténué avec Détection d'alerte précoce DevSecOps.
- Dépôt d'artefacts compromis
Attaques de la chaîne d'approvisionnement logicielle au stade du package
L'espace Étape du package C'est lorsque nous assemblons tout le code pour créer un produit final. Cette étape est risquée, car quelqu'un pourrait utiliser des packages malveillants ou modifier les sources en ligne où nous les obtenons. Les attaquants peuvent même télécharger des versions malveillantes de packages populaires sur ces sites web.
- Utiliser le package compromis → couvert dans évaluations des scanners de logiciels malveillants.
- Registre des packages compromis
- Télécharger le package modifié → analysé dans Namso-gen, générateur de faux logiciels malveillants.
Attaques de la chaîne d'approvisionnement logicielle au stade de la dépendance
Dans l' Stade de dépendanceNous ajoutons des bibliothèques et des packages tiers à notre logiciel. Cette étape est risquée, car tout problème rencontré dans ces composants peut facilement et discrètement se propager au reste du projet.
- Utiliser une dépendance compromise → expliqué avec Risques de déni de service dans les dépendances obscurcies.
- Dépendances obsolètes ou vulnérables
- Risques de dépendance transitive
- Registres de paquets malveillants → atténués avec Outils de sécurité DevOps et gestion des risques par des tiers.
Risques courants de la chaîne d'approvisionnement à chaque étape de la SDLC
| Stage | Menaces typiques | Exemple |
|---|---|---|
| Source |
• Soumettre du code malveillant ou non sécurisé • Altération de fichiers critiques • Compromettre le référentiel source |
XcodeGhost (2015) : code malveillant injecté dans le compilateur Xcode d'Apple, se propageant dans les applications iOS. |
| Se construisent |
• Contournement CI/CD les contrôles de sécurité • Modification du code après le contrôle de source • Compromettre les dépôts d'artefacts |
SolarWinds Orion (2020) : des attaquants ont infiltré la construction pipeline, en insérant une porte dérobée dans les mises à jour logicielles signées. |
| Forfait |
• Téléchargement de packages modifiés • Registres des colis d'empoisonnement • Distribution d'artefacts compromis |
EventStream NPM (2018) : un attaquant a inséré une porte dérobée dans un package NPM populaire téléchargé des milliers de fois. |
| Dépendance |
• Utiliser des dépendances obsolètes ou vulnérables • Exploiter les dépendances transitives • Publication de packages malveillants similaires |
Porte dérobée XZ Utils (2024) : une bibliothèque de compression trojanisée presque expédiée en aval dans les distributions Linux. |
Techniques courantes d'attaque de la chaîne d'approvisionnement des logiciels
Selon le CISSelon un rapport du NIST, les attaques contre la chaîne d’approvisionnement de logiciels se répartissent souvent en trois catégories principales.
Cependant, les incidents récents montrent des vecteurs supplémentaires que les développeurs doivent comprendre.
Ci-dessous, nous développons les techniques les plus pertinentes avec des exemples pratiques.
Mises à jour de piratage
Les attaquants compromettent les mécanismes de mise à jour légitimes pour diffuser des logiciels malveillants.
Par exemple, l'attaque NotPetya en 2017 a abusé du serveur de mise à jour du logiciel fiscal ukrainien MEDoc, livrant
Un malware destructeur déguisé en correctif. Pour se protéger contre ce risque, les équipes doivent appliquer détection et réponse aux menaces pour DevOps pratiques qui signalent les comportements anormaux dans les flux de mise à jour.
Saper la signature de code
Cette technique consiste à abuser ou à voler des certificats de signature valides pour faire apparaître un code malveillant comme légitime.
Un cas notable a été la compromission de CCleaner en 2017, où des attaquants ont distribué des logiciels trojanisés signés avec des certificats valides.
Par conséquent, les organisations ont besoin de contrôles d’intégrité unifiés tels que ceux décrits dans stratégies de plateforme de cybersécurité
Compromettre le code open source
Les adversaires insèrent des portes dérobées dans des packages open source populaires, puis les intègrent à des milliers de projets.
L'incident EventStream NPM et la porte dérobée XZ Utils (2024) illustrent à quel point ce vecteur est devenu critique.
Les développeurs devraient examiner des ressources telles que FAQ sur la sécurité NPM et incidents liés aux paquets typosquattés pour apprendre à éviter les dépendances empoisonnées.
Confusion des dépendances
Décrite pour la première fois par Alex Birsan en 2021, cette attaque exploite les collisions de noms entre les registres de packages internes et publics, incitant les systèmes de build à extraire des versions malveillantes au lieu de packages internes de confiance.
Typosquatting et packages malveillants
Les attaquants publient des packages malveillants avec des noms similaires à ceux des bibliothèques populaires (par exemple, « reqeusts » au lieu de « requests »).
Les développeurs les installent accidentellement, introduisant ainsi des logiciels malveillants dans leurs projets.
Un exemple réel est analysé dans Logiciel malveillant Namso-gen et dans notre liste de scanners de logiciels malveillants open source.
Se construisent Pipeline Falsification
Comme le montre le compromis SolarWinds Orion, les attaquants peuvent infiltrer les serveurs de build pour injecter du code malveillant lors de la compilation.
Cela rend toute la chaîne d'artefacts signée non fiable. Les techniques de prévention incluent la surveillance. CI/CD intégrité avec détection d'alerte précoce et analyser
Campagnes de malware pré-construites sur GitHub.
À quoi ressemble une attaque de la chaîne d'approvisionnement logicielle : le cas SolarWinds
L'attaque Orion de SolarWinds est avant tout l'exemple le plus connu de violation de la chaîne d'approvisionnement logicielle. Elle illustre comment les attaquants peuvent progresser étape par étape dans le processus de développement et, par conséquent, diffuser du code malveillant à des milliers d'utilisateurs.
Tout d’abord, les attaquants ont pénétré dans les serveurs de build de SolarWinds.
Après cela, ils ont discrètement ajouté du code malveillant dans les mises à jour d’Orion.
Étant donné que ces mises à jour étaient signées et expédiées en tant que logiciels de confiance, de nombreuses entreprises les ont installées sans connaître les risques.
Au total, plus de 18,000 XNUMX organisations ont été touchées et les attaquants ont eu accès à des systèmes très sensibles.
Du point de vue d'un développeur, cette attaque donne trois leçons simples :
- Les défenses du périmètre ne suffisent pas: les attaquants ont modifié la version pipeline elle-même.
- Les contrôles continus sont essentiels: sécurisé build attestations, les contrôles d’intégrité et la détection des anomalies aident à bloquer la falsification.
- Une seule construction empoisonnée peut devenir mondiale: un seul pipeline Le compromis peut créer une crise de sécurité mondiale.
Xygeni : la plateforme AppSec tout-en-un ultime
Parce que les attaques contre la chaîne d’approvisionnement de logiciels peuvent frapper à chaque étape du processus. SDLC,
la plateforme AppSec tout-en-un, Xygéni, protège les étapes source, build, package et dépendances. Il offre aux développeurs et aux équipes de sécurité un point central pour prévenir, détecter et corriger les risques en toute simplicité. Ainsi, plus besoin de jongler avec plusieurs outils : Xygeni couvre l'intégralité du cycle de vie.
Protection de l'étage source
Au stade de la source, les risques incluent des risques commits, référentiels empoisonnés ou fichiers modifiés. Xygeni scanne le code en temps réel avec profondeur SAST et la détection des secrets.
Il bloque également les éléments nocifs commits à travers CI/CD guardrails.
De cette façon, les problèmes sont arrêtés avant même qu’ils ne quittent le référentiel.
Protection de l'étape de construction
Au cours de la phase de construction, les attaquants peuvent essayer de contourner pipelines ou modifier les artefacts.
Xygeni sécurise le processus de construction avec des contrôles conformes à la norme SLSA, une validation d'intégrité et des signatures sans clé. Il surveille également les comportements inhabituels à l'intérieur. CI/CD emplois. Par conséquent, les builds falsifiées sont immédiatement signalées et bloquées avant leur publication.
Protection de l'étape du paquet
Au stade du package, les registres compromis ou les bibliothèques modifiées introduisent souvent des logiciels malveillants. Détection de logiciels malveillants et analyse des licences de Xygeni examiner chaque artefact, tandis que AutoFix suggère des chemins de mise à niveau sûrs avec son analyse des risques de remédiation. Seuls les colis vérifiés et conformes sont admis au processus. pipeline.
Protection contre la dépendance
Le code tiers constitue la plus grande surface d’attaque. Analyse de la composition du logiciel de Xygeni (SCA) Il ne se contente pas de répertorier les CVE, il vérifie si le code à risque peut être exploité. Il signale également les logiciels malveillants cachés et les dépendances transitives risquées. Surtout, cela garantit aux développeurs de ne livrer que des dépendances sûres.
Secrets et sécurité des infrastructures
Au-delà du code et des packages, les attaques exploitent souvent des secrets divulgués ou des infrastructures faibles. Xygeni recherche les clés, les jetons et les informations d'identification exposés dans le code, les configurations et les couches Docker. Il peut également valider et révoquer automatiquement les secrets divulgués avec Correction AutoFix. En même temps, IaC balayage empêche les erreurs de configuration dont les attaquants pourraient abuser ultérieurement.
Détection et correctifs plus intelligents
La plupart des outils s’arrêtent aux alertes. Xygeni va plus loin. Son moteur AutoFix crée des correctifs sécurisés, pull requests, ou des instructions étape par étape selon le problème. La vue « Risque de remédiation » indique également la version de correctif la plus sûre, permettant aux équipes de résoudre les problèmes sans en ajouter de nouveaux.
Une plateforme unifiée
Parce que Xygeni combine SAST, SCA, détection de logiciels malveillants, gestion des secrets, IaC numérisation, détection d'anomalies et contrôles de construction sécurisés dans une seule plateforme AppSec,
il offre une couverture complète sur toute la SDLCLes développeurs et les équipes de sécurité bénéficient d’une source unique de vérité avec une visibilité claire, des correctifs pratiques et une protection renforcée contre les attaques de la chaîne d’approvisionnement.
Tout bien considéré, Xygeni, la plateforme AppSec tout-en-un ultime, aide les équipes à développer rapidement et en toute sécurité. En protégeant les étapes source, build, package et dépendances, et en ajoutant des correctifs automatisés à chaque étape, il garantit que les attaques contre la chaîne d'approvisionnement logicielle sont stoppées avant qu'elles n'atteignent la production.
