Les attaques impliquant ces chaînes d’approvisionnement introduisent de nouveaux risques dans les systèmes d’information. Des intrusions peuvent entraîner des fuites de propriété intellectuelle, des altérations de code source, des interruptions de service ainsi que des élévations de privilèges vers des parties plus critiques du SI.  

Quels sont donc ces nouveaux vecteurs d’attaques sur les chaînes CI/CD et comment s’en protéger ? Cet article vise à dresser un panorama de chemins de compromission observés sur le terrain, ainsi que des recommandations pour les contrer. 

Quels risques pour les chaînes CI/CD ? 

L’attaque de SolarWinds en 2020 est un exemple qui ne cesse d’être énoncé, mais qui a mis en lumière l‘ampleur qu’une attaque de ce type peut causer. Après avoir vraisemblablement volé des identifiants FTP laissés en clair dans un ancien dépôt GitHub, l’opération a exploité la chaîne d’approvisionnement de SolarWinds en insérant un beacon C2 (Command & Control) dans leur logiciel de gestion réseau, Orion, en amont du processus de signature. 

Cette backdoor a permis aux attaquants d’accéder aux réseaux internes de plusieurs agences gouvernementales américaines et entreprises privées, et ce, pendant plusieurs mois avant d’être détectée. 

Cet incident, ainsi que des plus récents comme Log4Shell, Codecov et XZ Utils, ont non seulement souligné la nécessité d’une sécurité accrue dans la chaîne CI/CD mais aussi celle d’une réponse à incident beaucoup plus adaptative. L’OWASP présente de façon concrète un panorama des surfaces de risques les plus communes dans leur Top 10 CI/CD Security. 

Fig 1 – Top 10 OWASP CICD-Sec 

Quels retours terrain chez Wavestone ? 

Les audits et tests d’intrusion permettent de détecter des vulnérabilités de façon proactive avant qu’elles ne soient exploitées par des attaquants. En simulant de réelles attaques, ces évaluations offrent une perspective pratique sur la manière dont un système peut être compromis, ce qui permet d’appréhender plus concrètement les potentielles failles dans un système. 

Les différentes interventions menées chez nos clients nous permettent de faire un constat clair : 

• Dans nos audits Cloud et CI/CD, des vulnérabilités sont systématiquement trouvées au niveau des chaînes CI/CD, permettant dans la majorité des cas de prendre le contrôle de la chaîne, des artefacts, voire des infrastructures sous-jacentes.  
• De même, au niveau de nos interventions CERT & RedTeam, nous observons que les chaînes CI/CD sont souvent utilisées comme accélérateur dans les chemins de compromission. 

Regardons ensemble deux exemples d’attaque observés par nos équipes d’audit : 

Ce premier test d’intrusion en boîte grise a permis la compromission totale d’une organisation Cloud AWS (600+ comptes) en partant de comptes standards de DevOps. 

Dans ce scénario d’attaque, 

• Un attaquant pousse du code malveillant vers un repository GitLab, déclenchant une pipeline dans GitLab CI qui déploie ce code dans un pod Kubernetes générique. 
• Ce code ouvre un reverse shell, permettant à l’attaquant de se connecter à distance à l’environnement Kubernetes. 
• Depuis ce pod, l’attaquant exploite le fait que le compte de service associé au nœud dispose de privilèges trop élevés (capacité de patcher des jetons dans le cluster) et patch le jeton du nœud administrateur par un jeton générique. 
• Quand un redéploiement est déclenché, le pod malveillant ne peut qu’être déployer sur l’ancien nœud administrateur bénéficiant toujours des droits admin. 
• Cela permet donc à l’attaquant d’obtenir des privilèges élevés et de se latéraliser dans l’infrastructure AWS, compromettant ainsi le cluster Elastic Kubernetes Service (EKS) et les ressources associées. 

Regardons maintenant un deuxième exemple : 

Fig 3 – Condensé de plusieurs typologies d’attaques observées dans les CI/CD de nos clients 

Ce condensé, présenté à la DefCon & BSides 2022, met en évidence comment différents composants d’une chaîne peuvent être utilisés dans une attaque. Retrouvez cette présentation détaillée sur les nouveaux vecteurs d’attaque liés aux CI/CD en vidéo ! 

Quelles recommandations pour sécuriser sa chaîne CI/CD ? 

La chaîne CI/CD est désormais devenue un composant systémique des systèmes d’information pouvant être utilisée afin de compromettre des ressources critiques d’une entreprise. 

Nos recommandations en matière de sécurité de la chaîne CI/CD peuvent être articulées autour de trois grands axes : la gestion des identités et des accès (IAM), une meilleure conception de la chaîne CI/CD, ainsi que sa surveillance. Ces recommandations suivent notamment le guide DevSecOps de l’ANSSI. 

Fig 4 – Trois grands axes de recommandations pour sécuriser une CI/CD 

Gestion des identités et accès (IAM) 

Fig 5 – Recommandations IAM

Gestion des identités 

Outre les règles traditionnelles de gestion du cycle de vie des identités, il est recommandé d’utiliser systématiquement du Single-Sign On (SSO) avec authentification multifacteur (MFA) afin de réduire significativement le risque d’intrusion en CI/CD. Cela assurerait par exemple que les utilisateurs qui accèdent aux dépôts de code, qui signent un commit ou effectuent tout autre action privilégiée soient légitimés. 

Contrôle des accès 

Il est nécessaire de limiter au maximum les droits des utilisateurs et des comptes de service selon leur fonction dans la chaîne CI/CD, toujours en suivant le principe du moindre privilège. Les comptes sans mot de passe gérés par jetons d’accès doivent également être soumis à une gouvernance claire, avec des règles de cycle de vie, de rotation et de recertification régulière pour réduire les risques liés à leur utilisation. 

Cela peut aussi se faire en passant par du contrôle d’accès basé sur les rôles (RBAC). Par exemple, il ne serait pas utile de manière générale de donner un accès en écriture sur la configuration de la chaîne en elle-même à un développeur travaillant sur un projet spécifique. 

De la même façon, il est pertinent de segmenter ses projets en utilisant différents dépôts de code et de s’assurer que le compte orchestrateur d’un projet n’ait pas des droits excessifs sur le déploiement des projets auxquels il n’est pas rattaché. 

Gestion des secrets 

Les secrets en CI/CD désignent des données sensibles telles que des mots de passe, des clés d’API, des certificats ou des jetons d’accès. Ces secrets permettent notamment d’effectuer des actions privilégiées dans les pipelines et doivent être récupérés de façon automatique. 

Des éditeurs comme HashiCorp proposent des solutions de gestionnaires de secrets pour stocker facilement ses données sensibles et les chiffrer en transit et au repos.  

Conception de la CI/CD 

Fig 6 – Recommandations sur la conception d’une CI/CD 

Segmentation des environnements 

Il est nécessaire de préserver le cloisonnement entre les utilisateurs, les applications et l’infrastructure pour minimiser les impacts en cas de compromission. Reprenant des conseils de l’ANSSI, il faut considérer les actions réalisées par la chaîne CI/CD de production comme des actions d’administration et réduire au maximum le nombre d’utilisateurs pouvant y accéder. De plus, il est nécessaire d’utiliser du chiffrement bout à bout et de s’assurer qu’aucun environnement n’est exposé sur internet. 

Intégration d’outils tiers 

De la même manière que l’attaque SolarWinds, un grand nombre d’attaques de type supply-chain sont à l’origine un composant tiers compromis dans une chaîne CI/CD. Ces outils tiers sont souvent indispensables au bon fonctionnement des chaînes d’approvisionnement, ils peuvent aller d’un simple add-on sur un espace de développement, jusqu’à un outil de contrôle de version ou un orchestrateur. 

Généralement, ces outils se voient accorder des droits leur permettant d’accéder à des ressources sensibles ou d’effectuer des actions spécifiques au sein de la chaîne CI/CD. Si une vulnérabilité sur un outil n’est pas patchée et est exploitée par un attaquant, la capacité d’intervention sera limitée car la résolution de la faille dépendra souvent du fournisseur de l’outil. Il convient donc d’adopter une gouvernance stricte et un processus de Third-Party Cyber Risk Management (TPCRM) pour ces outils tiers. 

Gestion des artefacts 

Pour éviter de stocker des artefacts malveillants, il est recommandé de les signer en amont de la chaîne pour assurer leur intégrité en vérifiant cette signature au moment de leur déploiement. De la même façon, il faut s’assurer de ne pas déployer des librairies malveillantes en réalisant des scans Software Composition Analysis (SCA) régulièrement. 

Surveillance de la chaîne  

Fig 7 – Recommandations de surveillance 

Journalisation et détection 

Garder un haut niveau de visibilité et de contrôle sur tous les composants de la chaîne permet d’assurer une maintenance plus facile et une réponse plus rapide en cas d’attaque.  

Premièrement, il faut mettre en place une stratégie de journalisation adaptée, en maintenant des logs contenant uniquement ce qui est utile à la traçabilité et la responsabilité en cas d’incident. Il faut aussi s’assurer de stocker ces logs de façon sécurisée, ne pas y laisser des secrets en dur, ainsi que les partager efficacement à son Security information and Event management (SIEM). 

Aussi, pour réévaluer sa posture de sécurité et limiter au maximum les possibles chemins de compromission du pipeline CI/CD, des audits et des tests d’intrusion réguliers sont nécessaires.  

Réponse à incident 

Enfin, il faut s’assurer d’inclure sa chaine CI/CD dans ses plans de réponses à incident au même titre que n’importe quel autre périmètre de son système d’information. Il convient par exemple d’avoir des sauvegardes de son code source et ses configurations ainsi que des plans de continuité d’activités en cas de panne d’un outil. 

En conclusion 

Les chaînes CI/CD sont devenues une véritable pierre angulaire dans les systèmes d’information. Ces composants systémiques sont aujourd’hui indispensables pour développer et déployer des applications. Pourtant, leur criticité dans les SI appelle à mettre en place des mesures de sécurité adaptées pour qu’elles ne deviennent pas un vecteur d’attaques.  

Fig 8 – Quelques composants systémiques et critiques en CI/CD 

Outre les recommandations de cet article, d’autres mesures préventives peuvent se traduire plus précisément par des guides de durcissement pour des outils particuliers d’une chaîne. L’adoption d’une stratégie pertinente de formation des utilisateurs ainsi que de conduite du changement est aussi nécessaire pour réussir ces transformations.  

Un grand merci à Jeanne GRENIER pour sa précieuse contribution à la rédaction de cet article.

Cet article CI/CD : la nouvelle pierre angulaire du SI ?  est apparu en premier sur RiskInsight.

C’est ici qu’intervient l’Application Security Posture Management (ASPM). En effet, gérer de nombreuses applications et leurs outils de sécurité associés tout en maintenant une visibilité complète devient de plus en plus complexe. Dans ce contexte, l’ASPM répond logiquement à cette hétérogénéité croissante dans les chaînes CI/CD, en unifiant la gestion de la sécurité des applications sur une seule plateforme. Cela permet alors aux équipes d’évaluer et de visualiser plus clairement la posture de sécurité de tous leurs périmètres applicatifs. 

L’objectif de cet article est de passer brièvement en revue les capacités d’ASPM, et de déterminer s’il s’agit simplement d’une nouvelle approche pour la gestion des vulnérabilités, ou bien si cela représente un changement de paradigme vers un nouvel outil de sécurité unique. Nous examinerons également les facteurs clés que les entreprises prennent en compte pour choisir la solution ASPM la plus adaptée à leurs besoins. 

Qu’est-ce que l’ASPM ? 

ASPM est l’un des derniers « buzzwords » dans le domaine de l’AppSec. Ce terme, qui s’est surtout popularisé depuis que Gartner en a publié un document d’analyse en mai 2023, désigne une technologie permettant aux organisations d’unifier tous leurs outils de sécurité applicative sous une seule interface. Au cours de la dernière année, plusieurs start-ups et acteurs AppSec ont développé leur propre solution afin de s’emparer d’une partie de ce nouveau marché. 

La définition fournie par Gartner est la suivante : « Les solutions d’Application Security Posture Management (ASPM) gèrent en continu les risques liés aux applications via la détection, la corrélation et la priorisation des problèmes de sécurité tout au long du cycle de vie logiciel, du développement au déploiement. Elles agissent comme une couche de gestion et d’orchestration pour les outils de sécurité, permettant le contrôle et l’application des politiques de sécurité« . 

Fig 1 – Récapitulatif des caractéristiques d’ASPM  

La valeur sous-jacente d’ASPM est d’assurer une sécurité évolutive qui peut s’adapter au « Code-to-Cloud ». L’ASPM améliore la visibilité à tous les stades, réduit considérablement les faux positifs et la fatigue des alertes, et fournit surtout une source unique de vérité pour partager la propriété des vulnérabilités. C’est donc un atout clé pour les organisations submergées par des milliers d’alertes et ayant du mal à allouer efficacement des ressources pour y remédier. 

En quoi cette technologie est-elle unique par rapport aux solutions existantes ? 

Les outils traditionnels de gestion des vulnérabilités se concentrent sur l’agrégation et la priorisation des problèmes de sécurité détectés par des scanners. Cependant, ces outils couvrent souvent des périmètres informatiques plus larges sur tout le système d’information, sans se focaliser sur la sécurité des applications. 

L’Application Security Orchestration & Correlation (ASOC) avait initialement marqué un tournant dans ce domaine en se concentrant spécifiquement sur la gestion des problèmes de sécurité des applications. L’ASOC offrait aux équipes DevSecOps une interface pour orchestrer leurs outils et uniformiser les flux de remédiation. 

L’ASPM, de son côté, peut être considéré comme une évolution d’ASOC, élargissant son champ d’action de la sécurité du code à une gestion complète du code-to-cloud. Cela inclut non seulement l’analyse du code des applications, mais aussi de l’infrastructure et des ressources utilisées dans les phases de développement et de déploiement. Par exemple, l’ASPM peut analyser des configurations, des images de conteneurs et des modules Infrastructure-as-Code (IaC) comme des scripts Terraform. 

D’autres différences entre ASPM et ASOC incluent : 

1. Priorisation améliorée : L’ASPM donne une priorité aux risques critiques pour l’entreprise, au-delà des simples scores CVSS. 
2. Support à la conformité : L’ASPM permet de classer les vulnérabilités selon des cadres tels qu’OWASP, ISO et SOC2, aidant les organisations à atteindre leurs objectifs de conformité. 
3. Policy-as-Code : L’ASPM permet de définir des politiques, comme bloquer les déploiements si les scores de risque dépassent un seuil ou si des revues de code sont incomplètes. 

Facteurs décisifs dans le choix d’un fournisseur  

Avec une utilisation adéquate, l’ASPM peut optimiser les flux de travail des équipes et accélérer la résolution des problèmes de sécurité. Cependant, toutes les solutions ASPM ne conviennent pas à toutes les organisations. 

Fig 2 – Panel non exhaustif de fournisseurs d’ASPM 

Chaque contexte apporte des facteurs de décision uniques pour choisir le bon ASPM : 

• Cette solution peut-elle intégrer les outils dont je dispose déjà ? Sera-t-elle proche d’une expérience « plug-and-play » ? 
• Jusqu’à quel point puis-je intégrer cet ASPM dans ma CI/CD ? Jusqu’où peut-il automatiser les workflows de remédiation ? 
• Qui sont les utilisateurs finaux ciblés ? (Équipes de sécurité, Security Champion, Devs & Ops) 
• L’APSM utilise-t-il un algorithme personnalisé pour établir les priorités ou plutôt un CVSS, EPSS ? 
• L’interface est-elle esthétique et facile à utiliser ? Puis-je la personnaliser ? 
• Comment le fournisseur traite-t-il mes données ? 
• La sécurité de la plateforme correspond-elle à mes besoins ? Supporte-t-elle du SSO, MFA, RBAC ? 
• Quel est le niveau de support offert par l’éditeur ? 
• Les formules de souscription proposées sont-elles adaptées aux besoins de mon organisation ? 
• Qu’entend-on concrètement par l’utilisation annoncée de l’intelligence artificielle dans la solution ? 

Quelques points à considérer 

Maturité DevSecOps 

L’ASPM est une solution utile mais quelque peu « de niche » pour la sécurité des applications. Bien qu’il puisse fonctionner comme un outil plug-and-play relativement efficace, l’ASPM nécessite encore un travail d’intégration et un ajustement par les équipes de sécurité pour en maximiser le potentiel. Les organisations dépourvues d’une base solide en matière de sécurité ou qui en sont encore aux premières étapes de la mise en place d’une pipeline DevSecOps pourraient tirer moins de bénéfices d’un ASPM. Pour ces entreprises, il serait plus pratique de se concentrer d’abord sur les outils et processus fondamentaux en amont. 

Gestion des faux positifs et des faux négatifs 

L’un des avantages promis par l’ASPM est la réduction des faux positifs, un bénéfice commun à la gestion des vulnérabilités. En pratique, bien que le nombre d’alertes soit réduit, il n’est jamais totalement éliminé. Les équipes de sécurité doivent encore trier manuellement et traiter les vulnérabilités que le système ne peut pas classer définitivement comme faux positifs. 

Un autre problème est le risque de faux négatifs. Certains fournisseurs affirment que leurs outils « réduisent les vulnérabilités de 99 % ». Toutefois, à moins que les algorithmes d’évaluation des risques ne soient entièrement transparents, il existe un risque que des problèmes de sécurité réels soient ignorés. Lorsque des algorithmes classent certaines vulnérabilités comme insignifiantes sans justification adéquate, cela crée des zones d’ombre qui pourraient exposer l’organisation à des risques non traités. 

Conformité aux besoins des équipes  

Avant de s’engager dans une solution ASPM, il est essentiel de s’assurer qu’elle répond aux exigences spécifiques de l’organisation. Réaliser un Proof of concept (PoC) à petite échelle – en testant la plateforme avec différentes équipes opérant sous des dynamiques variées – peut fournir des informations précieuses sur ses aspects pratiques. 

Enfin, la plupart des solutions ASPM sont proposées sous forme de plateformes SaaS, ce qui simplifie leur déploiement pour un PoC et permet d’évaluer l’outil sans investissement initial important. 

Sécurité 

Étant donné que l’ASPM a souvent accès à des données sensibles, telles que du code source et des configurations, les organisations doivent vérifier soigneusement que la solution respecte leurs normes et leurs standards de sécurité. Ne pas le faire risque de transformer son ASPM en un point de défaillance au sein de la pile de sécurité. 

Une autre définition d’ASPM ? 

Un gestionnaire de vulnérabilités, dans son essence, ne vise pas à scanner des ressources, mais simplement à agréger les résultats que d’autres outils lui fournissent. De même, la valeur fondamentale de l’ASPM, telle qu’elle a été définie par Gartner, est de gérer les risques dans les environnements Code-to-Cloud, sans se mêler de la partie scanners, qui est laissée aux outils AppSec et CSPM. 

Cependant, deux ans après la publication de l’étude de Gartner, les ASPM ont pris une direction qui s’écarte quelque peu de leur vision initiale. Les fournisseurs d’ASPM ont commencé à intégrer des scanners natifs dans leurs solutions afin que leurs clients n’aient pas à en acquérir d’autres. Un excellent article de James Berthoty affirme à juste titre que, puisque la définition de l’ASPM de Gartner peut simplement être considérée comme une évolution de l’ASOC, il n’y a aucune raison de l’appeler autrement qu’ASOC. 

La seule raison légitime d’évoluer d’ASOC à ASPM serait un nouveau type d’outil visant à répondre à un besoin du marché de l’AppSec qui n’a pas encore été satisfait : une plateforme tout-en-un pour la sécurité des applications. En connectant simplement votre code source et vos environnements, cette plateforme analyserait tout, agrégerait les résultats et produirait simplement les problèmes les plus critiques et la manière d’y remédier. Cela pourrait être particulièrement pertinent pour les organisations qui n’ont pas de stack de sécurité préalable et qui recherchent un gestionnaire AppSec complet, tandis que celles qui souhaitent conserver leur chaîne d’outils actuelle pourraient opter pour une version ASPM d’agrégation à la place. 

Fig 3 – Comment définir l’ASPM idéal 

En conclusion 

Gartner avait initialement prévu que d’ici 2026, plus de 40% des organisations développant des applications propriétaires utiliseraient un ASPM pour gérer les risques liés à leurs applications. Bien que cette prédiction soit légèrement ambitieuse, le besoin en plateformes centralisées pour gérer la sécurité augmente lui aussi rapidement.  

Pour réaliser son plein potentiel, l’ASPM doit s’inscrire dans une stratégie DevSecOps plus large. Les organisations doivent établir les bons processus, une gouvernance efficace et des bases solides en CI/CD. 

Cet article  De la gestion de vulnérabilités à l’ASPM : évolution ou révolution ?  est apparu en premier sur RiskInsight.