Le DevSecOps intègre les décisions et les preuves de sécurité au processus de livraison logicielle, plutôt que de les cantonner à une simple vérification finale. Dans un pipeline d’intégration et de livraison continues (CI/CD) multicloud, la question centrale n’est pas de savoir quel cloud exécute l’application, mais quel composant est capable de modifier le code source, d’exécuter le code de build, de publier un artefact ou d’appeler une API de déploiement du fournisseur. Ce sont ces capacités qui définissent la limite de sécurité.
Dans le cadre de ce cours, les fournisseurs concernés sont AWS, Microsoft Azure et Google Cloud. Chaque fournisseur gère ses propres limites de ressources et d’identité, tandis qu’un plan de contrôle CI central coordonne les définitions de pipeline, la planification des tâches, les approbations et l’enregistrement des résultats. Cette leçon définit une charge de travail délimitée afin que les contrôles ultérieurs puissent être évalués par rapport à des identités, des artefacts et des cibles de déploiement concrets.
L’examen de sécurité d’un pipeline multicloud ne peut débuter tant que le périmètre n’est pas clairement établi ; en effet, un runner ou un registre situé hors de ce périmètre pourrait modifier une version (release) sans avoir été soumis à examen. La limite du pipeline englobe l’ensemble des dépôts, services du plan de contrôle, runners, identités, espaces de stockage d’artefacts et interfaces de déploiement qui participent à la transformation d’une modification en version livrable. Elle commence dès qu’une modification dans un dépôt peut influencer le comportement du pipeline et s’étend jusqu’aux actions via les API des fournisseurs qui créent ou modifient la charge de travail. Les requêtes d’exécution adressées à l’application déployée se situent en dehors de cette limite, bien que des preuves ultérieures puissent établir un lien entre une version livrable et le comportement en phase d’exécution.
Le plan de contrôle central, nommé ci-control, ne se trouve pas nécessairement au sein d’AWS, d’Azure ou de Google Cloud. Ses runners exécutent les tâches de build et de déploiement, puis s’authentifient séparément auprès du compte AWS dev, de l’abonnement Azure dev et du projet Google Cloud orders-dev. Un runner n’intègre la limite d’un fournisseur que s’il y est auto-hébergé. Son emplacement modifie l’exposition réseau et les mécanismes d’identité disponibles, mais ne dispense pas pour autant de mettre en place des autorisations fournisseur au périmètre restreint.
Nous pouvons désormais identifier les composants qui franchissent la limite de chaque fournisseur.
Un pipeline centralisé ne réduit la duplication que si ses contrôles sont appliqués de manière cohérente. La prolifération des identifiants survient lorsque de nombreux jobs, dépôts ou environnements de fournisseurs conservent des identifiants distincts, à longue durée de vie et aux droits étendus. Un identifiant de déploiement compromis peut rester valide bien après l’exécution du job qui l’utilisait ; par ailleurs, l’utilisation d’un identifiant partagé empêche les journaux d’audit de distinguer une exécution du pipeline d’une autre. L’utilisation d’identifiants éphémères, générés pour chaque exécution, limite à la fois la durée de validité et la portée du déploiement concerné.
Les contrôles d’analyse peuvent également subir des dérives. Une analyse de vulnérabilités appliquant un seuil d’échec différent selon qu’elle s’effectue sur un parcours AWS, Azure ou Google Cloud ne constitue pas une décision de sécurité unique, même si le même outil d’analyse est utilisé dans chaque cas. Le pipeline doit consigner l’artefact évalué, l’ensemble de règles appliqué, le résultat de l’analyse et l’issue de l’étape de validation. Un journal indiquant la réussite d’un job prouve uniquement que ce dernier a signalé un succès durant la période enregistrée ; il ne garantit pas, à lui seul, que toutes les ressources chez le fournisseur correspondent désormais à l’état cible.
La copie d’images entre clouds introduit une frontière supplémentaire. Une image copiée d’un registre à un autre peut être remplacée, copiée partiellement ou promue sous un tag déjà connu. Les tags désignent une référence mutable, tandis que le digest identifie le contenu spécifique de l’image. La règle à suivre consiste à autoriser chaque action auprès du fournisseur de manière indépendante et à transmettre les preuves relatives à l’artefact exact à chaque étape du transfert.
La charge de travail en cours d’exécution est orders-api, un service à l’écoute sur le port 8080. Le code source de l’application se trouve dans le dépôt orders-api-repo, tandis que les définitions de l’infrastructure résident dans orders-infra-repo. Une opération de build génère l’image de conteneur fictive orders-api:1.0, et les modifications d’infrastructure sont évaluées via la stack Terraform orders-infra. La séparation des dépôts de code source et d’infrastructure permet aux contrôles ultérieurs d’attribuer des droits distincts de revue, d’exécution et de déploiement selon le type de modification.
L’image est promue vers aws-ecr/orders-api, azure-acr/ordersapi et gcp-ar/orders-api, puis déployée via des appels API spécifiques à chaque fournisseur dans leurs environnements de développement respectifs. La promotion consiste à copier le digest de l’image vérifiée vers chaque registre, et non à reconstruire l’image à partir du code source pour chaque cloud. Une reconstruction créerait des artefacts distincts dont le contenu et les preuves associées pourraient diverger, malgré le partage du tag orders-api:1.0.
Il est possible d’examiner les parcours des artefacts et de l’infrastructure mis en évidence par cette charge de travail.