Créer un pipeline CI/CD axé sur la sécurité

L’intégration continue (CI) et la livraison continue (CD) sont devenues des pratiques incontournables pour les équipes DevOps. Le processus CI/CD vise à créer et à déployer de nouvelles applications, ou à publier des mises à jour pour des charges de travail déjà déployées. C’est pourquoi la plupart des initiatives CI/CD cherchent à accélérer le développement. 

Pourtant, les pratiques CI/CD peuvent faire bien plus que faciliter le déploiement des charges de travail. Elles peuvent notamment servir à créer un pipeline axé sur la sécurité, qui soumet le code à des tests de sécurité, recherche les vulnérabilités dans le code source et effectue d’autres vérifications essentielles avant le déploiement des composants de l’application.

À quoi ressemble un pipeline CI/CD axé sur la sécurité ?

Commençons par représenter le pipeline CI/CD comme un parcours linéaire, du développement à l’exploitation.

Les développeurs commencent par le processus de compilation, puis enregistrent leur code dans un système de gestion de versions tel que Git. Le code est validé et empaqueté, puis le fichier du package — par exemple un Webdeploy.zip pour .NET ou une image de conteneur Docker — est publié dans l’environnement d’exécution cible (un hôte Docker ou un environnement Kubernetes, par exemple). Les équipes d’exploitation prennent ensuite le relais et gèrent l’environnement.

Voyons maintenant comment le principe de sécurité CI/CD consistant à décaler la sécurité vers la gauche pourrait modifier ce processus, en intégrant des pratiques de sécurité à chaque étape. Dans le domaine de la sécurité, « décaler vers la gauche » consiste à intégrer la sensibilisation à la sécurité le plus tôt possible dans le cycle DevOps, puis à la maintenir à chaque étape du processus. 

Il est important de noter que la plupart des recommandations relatives au décalage vers la gauche reposent sur un principe général : rapprocher de la personne chargée de l’implémentation toutes les préoccupations DevOps (les tests, l’automatisation opérationnelle et la sécurité). L’objectif est de raccourcir la boucle de rétroaction et de mieux informer les équipes des résultats des changements dans ces domaines. 

La plupart des organisations décalent déjà d’autres cycles de processus DevOps vers la gauche, mais peinent à faire de même pour la sécurité, voire n’y parviennent pas. C’est pourquoi le terme DevSecOps a émergé pour souligner l’importance d’intégrer la sécurité aux pratiques DevOps.

Examinons quelques fonctionnalités de sécurité courantes que nous pouvons intégrer à chaque structure de pipeline CI/CD.

Comme le montre ce schéma, il est possible de mettre en place un flux CI/CD axé sur la sécurité sans modifier le processus CI/CD lui-même. Cette approche permet aux équipes DevOps d’intégrer des fonctionnalités de sécurité à chaque cycle CI/CD. 

Examinons de plus près certains des principaux aspects de sécurité présentés dans le schéma, les composants que nous pouvons intégrer à un pipeline CI/CD et les avantages qu’ils offrent. 

Modélisation automatisée des menaces

Les outils de modélisation des menaces analysent les applications à la recherche de failles de sécurité connues, de vulnérabilités et d’autres risques. Ils aident les organisations à repérer, reconnaître et anticiper les menaces, tout en favorisant une prise de décision proactive pour les éviter ou les atténuer. 

Dans notre schéma de pipeline CI/CD, la modélisation des menaces apparaît comme première étape, mais elle intervient souvent avant le début du développement. Dans l’idéal, il faudrait la répéter à différentes étapes du cycle CI/CD : c’est là que la modélisation automatisée des menaces prend tout son intérêt. 

Nomenclature logicielle

De plus en plus de développeurs utilisent du code provenant d’autres sources. Il peut alors être difficile de suivre les ressources — comme les extraits de code open source, les packages logiciels ou les conteneurs Docker — tout au long du cycle de développement d’une application. Une nomenclature logicielle (SBOM) est particulièrement utile dans ce cas.

La SBOM permet aux équipes de développement de répertorier différents aspects des composants logiciels, tels que l’emplacement des packages et leurs dépendances, et d’avoir une meilleure visibilité sur les composants d’une application. Elle permet également de comparer les packages de l’application aux vulnérabilités connues, afin de déterminer où et comment des utilisateurs malveillants pourraient exploiter le code. Pour toutes ces raisons, les SBOM sont devenues indispensables aux pipelines CI/CD axés sur la sécurité. 

Signature des artefacts

Les développeurs réutilisent souvent des artefacts d’une application à l’autre pour accélérer le processus. En développement logiciel, un artefact désigne un logiciel ou un élément le concernant — comme les SBOM décrites précédemment — qui fournit des fonctionnalités et des capacités au cycle de vie global d’une application logicielle. 

Le résultat de la création ou de la compilation du code (la CI) peut être considéré comme un artefact. Parmi les autres artefacts courants figurent les packages NuGet pour .NET, npm pour le développement Node.js et Maven pour Java. Les scripts PowerShell ou Bash peuvent également être considérés comme des artefacts. 

Pour protéger les ressources et en garantir l’authenticité, les ingénieurs DevOps peuvent envisager de signer numériquement le code source qu’ils produisent. Cette signature numérique est requise pour les développeurs d’applications qui utilisent des plateformes de distribution comme l’App Store d’Apple et Google Play Store. Associée à un certificat, elle permet aux utilisateurs du code source d’identifier l’organisation à l’origine de l’artefact. Elle garantit également qu’aucun tiers non autorisé n’a modifié le code. 

Cependant, le processus de signature numérique est complexe et nécessite de gérer des certificats d’infrastructure à clé privée. Heureusement, il est possible d’intégrer un outil d’automatisation au pipeline CI/CD pour mettre en œuvre les signatures numériques. 

Tests unitaires de validation de la sécurité

Les tests unitaires permettent aux développeurs de vérifier la qualité et le résultat d’une petite unité de logiciel fonctionnel. Ils garantissent que chaque partie du code fonctionne comme prévu. Principalement utilisés pour tester l’intégrité et les fonctionnalités du code, les tests unitaires peuvent aussi servir spécifiquement à valider la sécurité. 

Les tests unitaires peuvent vérifier la présence, dans chaque extrait de code, des vulnérabilités connues détectées par l’analyse de modélisation des menaces. Ils sont donc utiles dans le cadre de ce processus. 

Analyser l’infrastructure en tant que code (IaC)

L’infrastructure en tant que code (IaC) permet aux équipes DevOps de définir l’état final de l’infrastructure requise et de la déployer à partir de modèles. Chaque plateforme cloud publique propose ses propres outils IaC, comme Azure (ARM Templates et Bicep), AWS (CloudFormation) et GCP (Deployment Manager). 

Pour les environnements multicloud, les organisations peuvent opter pour une solution multiplateforme comme Terraform de HashiCorp, qui évite d’avoir à apprendre la syntaxe de plusieurs langages de modèles. Si la plupart des membres de votre équipe DevOps ont une formation en développement, une solution comme Pulumi peut être une excellente alternative. Au lieu de proposer des modèles, Pulumi s’appuie sur des bibliothèques et du code, et prend en charge plusieurs langages courants comme JavaScript, Python et DotNet. La solution est également compatible avec plusieurs plateformes cloud.  

Les fichiers de modèles IaC ressemblent au code source d’une application : ils contiennent des définitions, des variables et des liens vers d’autres artefacts. Il convient donc d’appliquer à l’IaC les mêmes optimisations axées sur la sécurité. L’automatisation de ces processus de sécurité est également efficace. Par exemple, Snyk automatise l’analyse des vulnérabilités de sécurité dans l’IaC pour aider les équipes DevOps à les détecter rapidement et efficacement. 

Analyse automatisée des vulnérabilités

L’analyse des vulnérabilités permet aux ingénieurs DevOps d’intégrer cette pratique au processus de pipeline CI/CD. Elle prend généralement la forme de tests de sécurité statiques des applications (SAST) ou de tests de sécurité dynamiques des applications (DAST). 

Le SAST analyse d’abord le code source au repos et le valide en détail directement dans le système de gestion de versions. Une autre analyse des vulnérabilités peut ensuite être exécutée lorsque le code est compilé et intégré aux packages logiciels. Elle recherche les menaces de sécurité dans le code source du développeur et analyse en profondeur les packages supplémentaires, comme les conteneurs Docker ou les bibliothèques logicielles. Enfin, le DAST intervient après la publication de l’application. Il teste la sécurité de l’application en cours d’exécution, sans analyser le code source, en simulant les actions d’un pirate ou d’un utilisateur malveillant pour tester ses défenses. 

Différents outils permettent d’analyser le code ou d’automatiser cette analyse. Par exemple, Snyk offre de puissantes fonctionnalités de sécurité et d’analyse du code pour les outils et plateformes DevOps courants disponibles aujourd’hui. 

Sécurité continue 

Voici quelques éléments clés pour intégrer des contrôles de sécurité à chaque cycle DevOps. Ils s’inscrivent dans le principe du « décalage vers la gauche », qui encourage à intégrer les contrôles de sécurité le plus tôt possible dans le processus DevOps. 

On obtient ainsi une approche de sécurité continue, qui protège chaque étape du cycle de développement. De telles stratégies aident les équipes DevOps à aller plus loin dans leurs pratiques de sécurité et à faire évoluer le développement et l’exploitation (DevOps) vers le développement, la sécurité et l’exploitation (DevSecOps). 

DevSecOps souligne l’importance d’intégrer les mécanismes de validation de la sécurité dès le début du développement et à chaque étape du processus DevOps. On peut, par exemple, commencer par modéliser les menaces lors de la phase d’architecture, intégrer l’analyse de sécurité au système de gestion de versions et à la compilation du code, puis valider la sécurité lors de la mise en production et à l’exécution de la charge de travail.

La sécurité continue peut — et doit — faire partie intégrante de la gestion du cycle de vie du développement logiciel. 

Optimiser les pratiques CI/CD et la sécurité

Historiquement, les processus CI/CD servent à accélérer les mises en production logicielles. Ils peuvent toutefois aussi être très utiles lorsqu’ils s’intègrent aux pratiques de sécurité et évoluent vers un pipeline CI/CD entièrement axé sur la sécurité. Face à l’évolution constante des cybermenaces et des cyberattaques, la protection du cycle de vie logiciel exige une approche de sécurité plus proactive que jamais. 

Parmi les bonnes pratiques de sécurité pour les équipes d’ingénierie DevSecOps figurent la modélisation automatisée des menaces, les SBOM, la signature des artefacts et l’analyse automatisée des vulnérabilités. Adopter ces stratégies permet de tendre vers une surveillance continue de la sécurité. Votre organisation peut ainsi publier ses logiciels plus rapidement, tout en intégrant les meilleures pratiques de sécurité à chaque livraison.