Les pipelines CI/CD sont notoirement opaques quant à ce qui se passe exactement à l’intérieur. Même si c'est vous qui avez écrit le fichier de configuration YAML (la liste d'instructions du pipeline), comment pouvez-vous être sûr que tout se déroule exactement comme décrit ? Pire encore, la plupart des pipelines sont complètement éphémères, de sorte que même si quelque chose de grave se produit, il ne reste aucune trace par la suite.
En termes simples, un pipeline est un moyen automatisé de tester, créer et publier votre logiciel, application ou artefact. De tels pipelines deviennent de plus en plus courants et de plus en plus compliqués. Les pipelines fonctionnent très bien pour amener les équipes à travailler plus rapidement et à donner des résultats plus cohérents et prévisibles lors de la production de leur artefact logiciel. L'importance de l'automatisation de ces processus devient encore plus claire si l'on considère que les grandes entreprises peuvent disposer de centaines de pipelines orchestrés qui dépendent les uns des autres. Il est donc essentiel que tout se déroule sans problème et sans échec.
En tant que dernier maillon du processus de développement entre les développeurs et l'utilisateur ou client final, j'estime qu'on ne se concentre pas suffisamment sur la manière dont de tels processus automatisés pourraient être utilisés comme vecteurs d'attaque potentiels. L'accès à un pipeline de construction pourrait permettre à des acteurs malveillants non seulement de pénétrer dans le système de la société productrice, mais aussi de modifier potentiellement l'artefact résultant de manière à affecter tous les futurs utilisateurs, créant ainsi un énorme rayon d'explosion souvent décrit comme un attaque de la chaîne d'approvisionnement logicielle.
Dans un article précédent, nous avons évoqué les principes qui devraient vous guider dans sécuriser votre pipeline CI/CD. Dans cet article, je couvrirai certains des points faibles potentiels les plus courants d'un pipeline CI/CD et proposerai quelques options de remédiation. Pour nos besoins, peu importe les outils ou systèmes d'automatisation que vous utilisez : les principes de sécurité sont toujours valables, il vous suffit de trouver l'outil approprié pour sécuriser cette section de votre pipeline.
Maîtriser l'art du CI/CD : les éléments clés que vous ne pouvez pas ignorer
Différents pipelines comportent différents éléments et utilisent différents outils. Les éléments sur lesquels j'ai choisi de me concentrer sont pertinents pour presque tous les pipelines, donc la sécurisation de ces éléments peut être considérée comme une bonne pratique, quels que soient votre SCM, vos outils ou votre configuration de sécurité existante.
Gestion secrète – les secrets sont généralement des chaînes ou des jetons utilisés pour connecter votre logiciel ou pipeline à d'autres ressources. Un exemple courant est celui des clés API utilisées pour connecter votre code aux ressources AWS, comme un compartiment S3. La plupart des gens savent déjà qu’ils doivent garder ces secrets cachés et ne pas les inclure sous forme de texte brut dans un référentiel ouvert. Les choses sont un peu plus compliquées dans un pipeline CI/CD. Habituellement, le pipeline a besoin d'accéder à ces secrets pour accéder aux ressources et aux informations qu'ils représentent. Cela signifie que toute personne ayant accès à ce qui se passe dans votre pipeline peut potentiellement voir et copier vos secrets. Une façon de protéger vos secrets, même à l'intérieur de votre pipeline, consiste à utiliser un outil de gestion des secrets tel que Coffre Hashicorp. De tels outils peuvent non seulement masquer vos secrets, même à l'intérieur de votre pipeline, mais ils facilitent également la rotation de vos secrets afin que vous puissiez les modifier régulièrement, rendant ainsi le vol de secrets dans un pipeline sans valeur. Quel que soit l'outil de gestion des secrets que vous choisissez d'utiliser, la rotation régulière de vos secrets peut être considérée comme une bonne pratique de sécurité.
Exécution de pipeline empoisonné (EPI) - L'exécution de pipeline empoisonné (PPE) est une technique qui permet aux acteurs malveillants d'« empoisonner » le pipeline CI – en fait, de modifier les étapes du pipeline ou leur ordre tel que défini dans le fichier d'instructions du pipeline. La technique abuse des autorisations dans les référentiels de gestion de code source (SCM) pour manipuler le processus de construction. Il permet d'injecter du code ou des commandes malveillants dans la configuration du pipeline de construction, empoisonnant ainsi le pipeline pour exécuter du code malveillant pendant le processus de construction. À moins que vous ne vérifiiez le fichier d'instructions du pipeline avant chaque build, vous ne saurez probablement pas que vos builds ne s'exécutent plus comme vous l'avez spécifié. Même un changement infime, comme appeler une bibliothèque plutôt qu’une autre, peut avoir des effets considérables, comme l’inclusion de portes dérobées ou de mineurs de crypto dans le produit final.
L’un des moyens d’éviter les EPI consiste à vérifier que le fichier d’instructions du pipeline n’est pas modifié. Vous pouvez signer le fichier de manière cryptographique et ajouter la vérification de la signature comme première étape de chaque pipeline. Un outil que vous pouvez utiliser pour signer et vérifier les fichiers est Valent, un outil édité par Scribe Security. Quel que soit l'outil de vérification de signature que vous utilisez, l'idée est de vous assurer que l'intégrité de votre fichier d'instructions reste intacte.
Empoisonnement du cache/dépendances – Les workflows du pipeline CI/CD sont fréquemment utilisés pour spécifier des actions particulières qui doivent être effectuées. Chaque flux de travail est composé d'une série d'une ou plusieurs tâches, caractérisées comme une séquence d'actions. La majorité des workflows ne partagent pas de ressources pour des raisons de sécurité. Il existe cependant des solutions de contournement lorsqu'il devient nécessaire de partager des ressources. Un cache auquel tous les flux de travail peuvent accéder de manière égale constitue une de ces solutions de contournement. Étant donné que le cache est partagé par plusieurs workflows, il suffit d’une seule infraction dans un workflow ayant l’autorité de le modifier pour que le cache devienne un poison pour toutes les utilisations ultérieures du workflow. Un célibataire ou Individual cache empoisonnée peut être actif pendant très longtemps, affectant d'innombrables itérations de versions logicielles exécutées dans ce pipeline, car le cache n'est mis à jour que lorsqu'il y a un nouvel artefact ou un nouvel package à télécharger.
Tout comme lors de la vérification du fichier d'instructions du pipeline, vous pouvez utiliser Valent pour signer et vérifier ultérieurement votre cache ou un dossier contenant toutes les dépendances pré-approuvées dont votre pipeline a besoin. Si vous êtes du genre paranoïaque, permettre à votre pipeline de se connecter indépendamment à Internet et de télécharger toutes les bibliothèques qu'il juge nécessaires est un moyen infaillible d'obtenir plus de vulnérabilités et d'exploits possibles dans votre version finale.
clés SSH – Une clé SSH est un identifiant d'accès au protocole réseau SSH (secure shell). Ce protocole réseau est utilisé pour la communication à distance entre les machines sur un réseau ouvert non sécurisé. SSH est utilisé pour le transfert de fichiers à distance, la gestion du réseau et l'accès à distance au système d'exploitation. Avec les clés SSH, par exemple, vous pouvez vous connecter à GitHub sans fournir votre nom d'utilisateur et votre jeton d'accès personnel à chaque visite. Vous pouvez également utiliser une clé SSH pour signer des commits. Vous pouvez également connecter d'autres applications à votre GitHub à l'aide de clés SSH comme BitBucket ainsi que gitlab ce.
Pour maintenir la sécurité de votre compte, vous devez régulièrement consulter votre liste de clés SSH et révoquer/supprimer toutes les clés invalides ou qui ont été compromises. Pour GitHub, vous pouvez trouver votre liste de clés SSH sur la page suivante :
Accès Paramétres > Clés SSH et GPG
Un outil qui peut vous aider à garder le contrôle de vos clés SSH est un rapport sur l'état de sécurité open source appelé GitGat. Le rapport GitGat vous alertera si l'une de vos clés SSH configurées a expiré ou n'est pas valide. En plus de garder un œil attentif sur vos clés et de les faire pivoter souvent, GitHub vous avertit que si vous voyez une clé SSH que vous ne connaissez pas, supprimez-la immédiatement et contactez-la. Prise en charge de GitHub pour obtenir de l'aide supplémentaire. Une clé publique non identifiée peut indiquer une éventuelle faille de sécurité.
Provenance SLSA en tant que journal de pipeline immuable - SLSA signifie Supply Chain Levels for Software Artifacts, qui est un cadre développé par Google et d'autres partenaires industriels pour aider à améliorer la sécurité et l'intégrité des chaînes d'approvisionnement logicielles.
SLSA définit un ensemble de quatre niveaux, chacun représentant un niveau plus élevé de confiance et d'assurance dans la chaîne d'approvisionnement logicielle. Chaque niveau représente un incrément croissant d’exigences de sécurité. Une exigence importante est la nécessité de la provenance du fichier. Pour le cadre SLSA,
La provenance est l'information vérifiable sur les artefacts logiciels décrivant où, quand et comment quelque chose a été produit. Étant donné que l'objectif principal d'un pipeline CI/CD est de produire quelque chose (généralement une version), alors être capable de suivre exactement quels fichiers sont entrés et ce qui leur est arrivé est une sorte de journal machine infalsifiable du pipeline. À cette fin, il est important que la provenance SLSA soit créée indépendamment de tout utilisateur. L'intégrité de tout ce qu'un utilisateur peut interrompre ou modifier peut être suspecte.
Un outil qui vous permet de créer une provenance SLSA dans votre pipeline pour une grande variété de systèmes SCM est Valent (oui, le même outil de Scribe – c'est un outil très polyvalent). Le lien vous montrera comment connecter Valint à votre pipeline GitHub pour générer une provenance SLSA pour chaque exécution de build sur ce pipeline. Vous pourrez ensuite accéder à chaque fichier de provenance et le vérifier pour voir si quelque chose de fâcheux ou d'inattendu s'est produit. Voici un extrait d'un tel fichier de provenance :
Le fichier de provenance n'est qu'un fichier JSON, mais comme il n'existe pas (encore) d'outils automatisés pour lire les fichiers de provenance, la tâche de les lire et de les interpréter vous incombe.
Sécuriser votre résultat final – L’une des violations les plus connues de la chaîne d’approvisionnement logicielle de mémoire récente est la Incident SolarWinds. Dans ce document, les pirates ont modifié du code dans le serveur de build afin que chaque build publié par l'entreprise contienne une porte dérobée secrète. Un autre cas célèbre de corruption du résultat final peut être observé dans le piratage de l'autorité de certification du gouvernement vietnamien (VGCA) en 2020, baptisé Opération SignSight. Les intrus ont infiltré le site Web de VGCA et redirigé les liens de téléchargement vers leur propre version du logiciel, contenant des logiciels malveillants. Dans les deux cas, les utilisateurs finaux n'avaient aucun moyen de vérifier que le logiciel qu'ils recevaient était bien celui que la société productrice avait l'intention de publier.
Une attaque plus simple pourrait consister à remplacer l’image finale créée à la fin du pipeline par une image malveillante et à télécharger la mauvaise image là où elle doit aller. Puisque dans la plupart de ces attaques, l'image est censée provenir de la société productrice, même si cette société est protégée par un certificat valide, cela ne suffit pas. Cela rendrait simplement le faux encore plus crédible.
Une fois de plus, la solution consiste à signer cryptographiquement quel que soit l'artefact final produit par le pipeline et à permettre à l'utilisateur final de vérifier cette signature.
Puisque j'ai déjà mentionné Valent Je suggérerai l'utilisation de l'open source Cosign de Sigstore. Cosign vise à faciliter la signature en supprimant le besoin d'une infrastructure clé. Il permet à l'utilisateur d'utiliser son identité vérifiée en ligne (telle que Google, GitHub, Microsoft ou AWS) comme clé. Vous pouvez utiliser Cosign pour signer et vérifier des images, ce qui le rend idéal pour la signature et la vérification ultérieure de l'image finale construite d'un pipeline.
Que vous choisissiez d'utiliser Valint ou Cosign, permettre à vos utilisateurs de vérifier une signature cryptographique sur votre artefact final pour vous assurer qu'ils obtiennent exactement ce que vous aviez l'intention de fournir est une idée que la plupart des utilisateurs finaux apprécieraient, j'en suis sûr.
La sécurité des pipelines à l’avenir
Il existe bien entendu d’autres éléments impliqués dans un pipeline de construction qui pourraient bénéficier d’une sécurité accrue. Dans cet article, j’ai choisi d’examiner certains des éléments de pipeline les plus évidents et les plus vulnérables.
Quel que soit l’outillage ou l’infrastructure de pipeline que vous utilisez, assurez-vous de garder les yeux ouverts sur la possibilité d’une violation. Ne faites jamais aveuglément confiance à un système qui vous dit qu'il est totalement sécurisé.
Compte tenu de la menace croissante de vol d’identité, de spear phishing et d’autres formes de falsification d’accès légitime, nous pensons que le mécanisme de vérification de signature est un bon outil polyvalent à avoir dans votre boîte à outils numérique.
Que vous ayez besoin de signer une image, un fichier ou un dossier, je vous invite à examiner de plus près Valint de Scribe Security en tant qu'outil unique pour de tels besoins.
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
