Sécurité CI/CD : Sécurisez votre pipeline CI/CD
Le pipeline CI/CD (intégration et distribution continues ou déploiement) est la base sur laquelle tous les processus DevOps sont construits. Plus précisément, la sécurisation des pipelines CI/CD à chaque étape, et à travers chaque outil et environnement qui composent le pipeline, devrait être une priorité pour toute organisation qui adopte le DevOps.
Dans cet article, vous comprendrez pourquoi la sécurité CI/CD est importante et quelles sont les meilleures pratiques à mettre en place pour renforcer la sécurité dans le pipeline.
Qu’est-ce que la sécurité CI/CD ?
La sécurité CI/CD est un processus en plusieurs étapes qui vise à identifier et à réduire les risques de sécurité à chaque étape du pipeline CI/CD.
Les spécificités de la sécurité CI/CD varient d’une équipe à l’autre, selon les caractéristiques propres aux opérations CI/CD de chaque équipe. Si tous les pipelines CI/CD comprennent au moins quelques étapes de base (gestion du code source, construction, test et déploiement), certains comportent également des branches de fonctionnalités qui ajoutent de la complexité (et des risques de sécurité) au pipeline. De même, les pipelines CI/CD qui ciblent plusieurs environnements de production (comme les serveurs Windows et Linux) sont plus complexes et comportent plus de risques de sécurité que ceux qui transfèrent les applications dans un seul type d’environnement.
La façon dont vous abordez la sécurité CI/CD dépend donc de la nature exacte de vos processus CI/CD et des outils que vous utilisez pour les faire fonctionner. Néanmoins, l’objectif principal de la sécurisation d’un pipeline CI/CD doit être de garantir que, quel que soit le chemin emprunté par le code au cours de son parcours dans le pipeline, vous atténuez tous les risques potentiels à toutes les étapes.
Menaces de sécurité CI/CD
Outre la compréhension du fonctionnement de votre pipeline, vous devez également reconnaître les différents types de menaces de sécurité susceptibles d’avoir un impact sur les opérations de CI/CD et prendre des mesures pour vous défendre contre chacune d’elles.
Bien qu’il soit impossible d’identifier tous les types de risques potentiels de sécurité CI/CD avant qu’ils ne surviennent, les exemples les plus courants sont les suivants :
- Du code non sécurisé qui est importé dans un pipeline CI/CD à partir d’une source tierce, comme un projet open source.
- Un accès non autorisé aux dépôts de code source ou aux outils de construction, ce qui pourrait permettre aux cybercriminels d’injecter du code malveillant dans une application.
- Une violation d’un environnement de développement/test dans lequel un cybercriminel désactive un test de sécurité important, empêchant ainsi l’équipe de détecter une violation de la sécurité au stade du test du pipeline.
- Une gestion non sécurisée des mots de passe/secrets au sein du pipeline en raison de pratiques telles que le codage en dur des mots de passe dans les modèles IaC (Infrastructure-as-a-Code). Les cybercriminels qui ont accès à ces informations peuvent les utiliser pour orchestrer une brèche.
Comment sécuriser un pipeline CI/CD
Étant donné que les menaces liées au processus CI/CD touchent différentes étapes du pipeline et différentes couches de la pile logicielle, la sécurité du pipeline CI/CD nécessite une approche à plusieurs volets. Vous devez déployer des outils et des processus capables de détecter une variété de menaces différentes.
Voici les principales catégories d’outils et de bonnes pratiques qui permettent de détecter et de gérer les risques de sécurité en matière de CI/CD.
Analyse de composition des sources
L’analyse de composition des sources, ou SCA, est l’analyse du code source pour identifier les vulnérabilités provenant de modules ou de bibliothèques tiers, tels que ceux importés d’un projet open source. Les outils SCA peuvent analyser vos dépôts de sources au début du pipeline CI/CD et vous avertir des dépendances qui, si elles ne sont pas traitées, peuvent entraîner des failles de sécurité dans votre application de production.
Test statique de sécurité d’application
Le test statique de sécurité d’application, ou SAST, complète l’analyse SCA en évaluant le code source que vous écrivez vous-même pour détecter les vulnérabilités potentielles. Plus exactement, alors que l’analyse SCA peut identifier des vulnérabilités dans du code tiers en se basant sur des bases de données de vulnérabilités connues, le test SAST effectue une analyse du code personnalisé pour détecter des problèmes de sécurité potentiels, comme une validation incorrecte des entrées.
Ainsi, en effectuant un test SAST au début de votre pipeline CI/CD en plus d’une analyse SCA, vous érigez une deuxième barrière de défense contre les risques dans le code source.
Contrôles d’accès CI/CD
L’utilisation de contrôles d’accès pour gérer qui peut accéder à quels outils et ressources dans le pipeline CI/CD est essentielle pour prévenir les attaques dans lesquelles les cybercriminels injectent du code malveillant dans l’environnement de développement. C’est ce type de vecteur d’attaque qui a été utilisé dans la tristement célèbre violation de SolarWinds dévoilée en 2020.
Pour gérer de tels risques, chaque outil du pipeline CI/CD doit être sécurisé par des mots de passe, des clés d’accès ou d’autres contrôles d’accès, et l’accès doit être accordé de manière granulaire uniquement aux membres de l’équipe qui en ont spécifiquement besoin. Bien qu’il puisse être tentant de donner à tous les développeurs et ingénieurs un accès à toutes les ressources de CI/CD, cette méthode ne constitue pas une bonne pratique. Elle s’écarte du principe du privilège minimum et maximise les risques qu’un compte compromis donne aux cybercriminels les clés de tout l’environnement CI/CD de votre équipe.
Gestion des mots de passe et CI/CD
Les secrets tels que les mots de passe et les clés d’accès sont souvent nécessaires à plusieurs étapes du processus CI/CD pour intégrer ou construire du code, déployer des applications en test ou en production, etc.
En général, le moyen le plus simple de partager ces secrets est de les coder en dur dans les fichiers de configuration CI/CD ou les modèles IaC que votre équipe utilise pour provisionner les environnements d’application. Mais là encore, la voie de la facilité n’est pas celle de la sûreté. Les secrets et mots de passe codés en dur sont facilement accessibles à toute personne capable de visualiser les fichiers de configuration ou les modèles IaC, ce qui crée un risque de sécurité important.
Une meilleure pratique consiste à utiliser un gestionnaire de mots de passe sécurisé pour stocker les données sensibles et les partager au fur et à mesure des besoins pendant les opérations de CI/CD.
Analyse du registre
Si votre pipeline CI/CD déploie des applications à l’aide de conteneurs, vous pouvez ajouter une autre couche de protection en effectuant une analyse automatisée des images de containers lorsqu’elles entrent dans les registres. L’analyse du registre vérifie la présence de vulnérabilités dans les conteneurs, ce qui permet à votre équipe d’intercepter les codes malveillants qui ont pu échapper aux tests de sécurité effectués lors des premières étapes du pipeline CI/CD.
L’analyse du registre est particulièrement importante étant donné que certaines vulnérabilités peuvent être introduites non pas au niveau du code source, mais dans le cadre de dépendances qui sont ensuite incorporées dans un conteneur. Par conséquent, les outils SCA et SAST, qui analysent uniquement le code source, ne détecteront pas ces vulnérabilités. L’analyse du registre s’en occupera, dans la plupart des cas.
Sécurité d’exécution
La sécurité de l’exécution, qui consiste à détecter les menaces actives dans les environnements d’applications en réel, vous aide à gérer les menaces au cours de la dernière grande étape du pipeline CI/CD : le déploiement en production. Vous pouvez également appliquer la sécurité d’exécution aux environnements de développement et de test dans le cadre d’une stratégie de sécurité de type « shift-left ».
La sécurité d’exécution repose sur une diversité d’outils et de sources de données, tels que les journaux d’application, les métriques du réseau et les journaux d’audit. Votre approche de la sécurité d’exécution variera en fonction de votre environnement d’exécution (utilisation ou non de containers, orchestrateur utilisé, etc.), mais l’objectif principal doit être de détecter les menaces avant qu’elles ne s’aggravent.
Un pipeline CI/CD non sécurisé conduira inévitablement à une application non sécurisée. En gérant les risques de sécurité à tous les stades du pipeline par des pratiques telles que le contrôle d’accès, la gestion des mots de passe et l’analyse du registre, vous pouvez réduire le risque que du code non sécurisé circule dans votre pipeline.