Les spécificités de ce qui se passe à l’intérieur des pipelines CI/CD sont tristement opaques. Même si vous avez écrit le fichier de configuration YAML, qui est la liste d'instructions du pipeline, comment pouvez-vous être certain que tout se passe exactement comme il est décrit ? Pire encore, la majorité des pipelines sont entièrement transitoires, de sorte que même en cas de dysfonctionnement, il existe peu de preuves autres que ce qui a été enregistré qui peut ou non inclure les détails du problème.
Un développement rapide est obtenu grâce à l’utilisation de pipelines automatisés d’intégration continue/de livraison continue (CI/CD). Avoir des déclencheurs ou une planification qui compilent, construisent, testent et expédient automatiquement votre code est fantastique. Cependant, la plupart des pipelines ne sont pas construits dans un souci de sécurité, car ils ont été conçus pour la rapidité et la commodité d'utilisation. Étant donné que les pipelines nécessitent généralement un accès à Internet pour télécharger des dépendances et des fichiers, une fois qu'un pipeline est compromis, l'attaquant dispose de diverses options pour perturber vos opérations ou exfiltrer des informations ou des secrets.
Dans cet article, je couvrirai certaines des meilleures pratiques que vous pouvez mettre en place pour protéger votre pipeline CI/CD. 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 le bon outil pour sécuriser cette section de votre pipeline.
Qu'est-ce que le pipeline CI/CD (intégration continue/livraison continue) ?
Un pipeline CI/CD est un processus automatisé permettant de créer, tester et publier votre logiciel, application ou artefact. Ces pipelines deviennent de plus en plus courants et complexes. Les pipelines sont un excellent outil pour augmenter la productivité des équipes et produire des artefacts logiciels de manière plus cohérente et prévisible. L’importance de l’automatisation de ces procédures devient beaucoup plus évidente si l’on prend en compte le fait que les grandes entreprises peuvent disposer de centaines de pipelines interconnectés et chorégraphiés, qui dépendent tous les uns des autres pour bien fonctionner.
La création et le test automatiques et réguliers des modifications de code dans un nouveau produit final sont appelés intégration continue, ou CI. Les modifications de codage sont livrées, testées et intégrées dans le cadre d'un processus en deux étapes appelé livraison et/ou déploiement continu – CD. Le déploiement continu fournit automatiquement les mises à jour dans l'environnement de production, tandis que la livraison continue s'arrête juste avant le déploiement automatique en production. Que votre pipeline utilise l'un ou l'autre dépend entièrement de vous et de la manière dont vos environnements et vos livrables sont configurés.
L'importance de la sécurité CI/CD pour votre chaîne d'approvisionnement logicielle
La plupart des entreprises s'appuient sur Outils CI / CD pour automatiser leurs pipelines. Cela signifie que, comme beaucoup d'autres attaques de la chaîne d'approvisionnement logicielle, tout ce dont les mauvais acteurs ont besoin est de percer une seule cible pour obtenir un vaste rayon d’explosion. L'une des principales faiblesses est la nécessité pour le pipeline de télécharger et d'intégrer les dépendances dans le produit ou l'artefact final. Même une mauvaise dépendance suffit à donner un pied à un élément indésirable dans le pipeline. Étant donné que le pipeline a accès au code source et à divers autres éléments de votre infrastructure (selon les besoins), une élévation de privilèges peut accéder et modifier ou exfiltrer ultérieurement presque n'importe quelle partie du produit créé dans ce pipeline particulier.
Un exemple simple peut être trouvé dans notre explication d'un empoisonnement du cache ou des dépendances.
Au cours des dernières années, plusieurs grandes entreprises ont été victimes d’attaques sur la chaîne d’approvisionnement logicielle ayant pour point d’origine un pipeline CI/CD. Par exemple, vous pouvez regarder Brèche de CircleCI en janvier 2023, Le compromis d'Argo CD en janvier 2022, et le Violation de Codecove en Avril 2021.
Les conséquences potentielles de telles attaques sont graves, il est donc logique de faire tout ce qui est en votre pouvoir pour vous assurer que vos pipelines sont aussi sécurisés que possible.
Meilleures pratiques de sécurité CI/CD
Quelle que soit la plateforme ou les outils CI/CD que vous utilisez, vous pouvez prendre certaines mesures pour renforcer votre sécurité et réduire les dommages potentiels dans le cas peu probable où un acteur hostile parviendrait à accéder à votre pipeline ou à votre réseau.
Surveillance et alerte – Une violation peut se produire même si vous avez formé vos ingénieurs à se méfier du phishing et autres fraudes d’ingénierie sociale. Étant donné que la majorité des environnements de pipeline sont transitoires, une fois le travail terminé, il ne restera pas beaucoup de traces à moins que vous ne les enregistriez activement. Lorsque vous travaillez sur chaque PR, fusionnez, créez et testez, assurez-vous que toutes les modifications apportées à l'environnement ou aux fichiers de configuration sont enregistrées. Les données utilisateur doivent également être enregistrées avec toutes les autres données pour examen si un problème l'exige. L’objectif ici est d’être capable de reconstituer une brèche et de déterminer ce qui n’a pas fonctionné et comment cela s’est produit. Sélectionnez à l’avance les événements qui doivent déclencher une alerte et assurez-vous que les parties concernées sont informées. Veillez à ne pas submerger les individus d’alertes inutiles ou trop sensibles ; cela pourrait conduire à une lassitude face aux alertes, qui les amènerait simplement à ignorer les alertes ou à réagir beaucoup plus tard que ce qui est prudent.
Utiliser le principe RBAC combiné au moindre privilège – Fournir un accès aux ressources système en fonction du rôle ou de la fonction professionnelle désignée d'un utilisateur au sein d'une organisation constitue le fondement du contrôle d'accès basé sur les rôles ou RBAC. Les utilisateurs se voient attribuer des rôles dans RBAC qui spécifient leurs droits d'accès et autorisations à différentes ressources système, telles que les fichiers, les dossiers et les programmes. D'autre part, le concept de moindre privilège fait référence à la pratique consistant à accorder aux utilisateurs le minimum d'accès et de privilèges requis pour effectuer leurs tâches professionnelles. Cela implique que les utilisateurs sont limités à l'utilisation des ressources nécessaires pour accomplir les tâches qui leur sont assignées et rien de plus. Le moindre privilège et le RBAC sont fréquemment appliqués en tandem en tant que concepts de sécurité complémentaires. Le principe du moindre privilège garantit que les utilisateurs n'ont accès qu'à la quantité minimale de ressources nécessaire pour accomplir leurs tâches particulières, et RBAC attribue des rôles qui fournissent aux utilisateurs la quantité appropriée d'accès aux ressources dont ils ont besoin pour exécuter leurs fonctions et rien de plus. . Lorsqu’elles sont combinées, ces lignes directrices aident à maintenir un système bien entretenu et relativement sûr. Vous pouvez le configurer pour exiger plusieurs autorisations d'utilisateur pour les actions essentielles du système en tant que couche de sécurité supplémentaire. Cette stratégie doit être utilisée avec précaution car elle pourrait entraîner un retard notable dans le processus de développement.
Conserver la provenance du pipeline sous forme de journal immuable – Les informations vérifiables sur les artefacts logiciels qui décrivent où, quand et comment quelque chose a été créé sont appelées provenance. Savoir précisément quels fichiers ont été saisis et ce qui leur est arrivé dans un pipeline peut être généré sous forme de fichier de provenance pour former un journal infalsifiable de ce pipeline. Pour être sécurisée, la provenance doit être créée indépendamment de tout utilisateur, car tout ce qu'un utilisateur peut perturber ou modifier n'est pas entièrement fiable. Valint du scribe vous permet de établir la provenance dans votre pipeline pour une large gamme de systèmes SCM. Chaque fichier de provenance (JSON) est accessible ultérieurement, vous pouvez donc l'examiner pour déterminer si quelque chose d'inattendu ou d'indésirable s'est produit. D'ailleurs, la génération et la gestion des fichiers de provenance à partir de l'ensemble de vos pipelines sont au cœur du projet. Cadre SLSA.
Utilisez pleinement votre SBOM – Juste au cas où vous auriez manqué quelques-unes des utilisations potentielles, un SBOM créé à la fin du pipeline pourrait aider à répertorier tous les packages open source utilisés. La comparaison de cette liste avec les CVE connus pourrait vous indiquer quelles vulnérabilités potentielles existent dans votre produit final. Vous pouvez également utiliser la liste pour vérifier si vous utilisez toujours des versions obsolètes de packages open source, et même utiliser quelque chose comme le Tableau de bord OpenSSF pour vérifier la « santé » des packages que vous utilisez. Étant donné que de nouveaux CVE apparaissent constamment, vous devriez disposer d'un service, contrairement à un SAST unique, qui vous permet de savoir si l'un de vos packages existants a découvert un nouveau CVE. Le service Scribe peut vous aider à faire tout cela automatiquement.
Vérifiez la conformité avec vos politiques – Chaque entreprise, et parfois chaque pipeline, a des politiques qui doivent être mises en œuvre pour garantir que tout va bien. Certaines politiques sont génériques (comme s'assurer qu'il existe un processus de vérification par deux personnes), et d'autres sont uniques (comme s'assurer que Mike approuve la dernière modification avant de l'envoyer en production). Grâce au mécanisme de vérification de signature cryptographique et à un fichier de stratégie unique, vous pouvez désormais inclure les stratégies nécessaires dans chaque pipeline et vérifier (pour vous-même et pour les autres) qu'elles ont eu lieu. Il s'agit d'une faiblesse humaine qui, lorsqu'elle est soulignée, peut entraîner le non-respect de certaines exigences et le contournement de certaines règles pour respecter un délai. Avec cette mesure en place, les gens ne peuvent plus contourner les règles, ce qui devrait contribuer à maintenir la sécurité de votre pipeline contre les menaces internes et externes. Scribe a développé une nouvelle façon d'appliquer de telles politiques et vous permet même d'écrire les vôtres. Vérifiez-le missions.
Sécurisez le fichier d'instructions du pipeline – Les acteurs malveillants peuvent « empoisonner » le pipeline CI en utilisant une technique connue sous le nom d’exécution de pipeline empoisonnée (PPE), qui modifie essentiellement les étapes du pipeline ou leur séquence comme spécifié à l’origine dans le fichier d’instructions du pipeline. La méthode manipule le processus de construction en abusant des autorisations dans les référentiels de gestion de code source (SCM). En insérant du code ou des commandes malveillants dans les paramètres du pipeline de build, il est possible d'empoisonner le pipeline et de provoquer l'exécution de code malveillant pendant la fin de la build. Vous ne pourrez pas savoir que vos builds ne fonctionnent pas comme vous le souhaitiez tant que vous n'aurez pas vérifié le fichier d'instructions du pipeline. Pour être sûr que vos pipelines sont exécutés comme prévu, vous devez vérifier le fichier d'instructions avant chaque exécution. D'un point de vue cryptographique, signer le fichier et ajouter la vérification de la signature comme première étape du pipeline est un moyen d'atteindre cette sécurité. Valint du scribe signer et vérifier Les fonctions sont un moyen de vérifier que votre fichier d'instructions est resté inchangé avant de lancer une nouvelle exécution de pipeline.
Sécurisez votre résultat final – Pourquoi un attaquant devrait-il travailler dur pour perturber votre pipeline alors qu’il est beaucoup plus facile de remplacer votre produit final par une version frauduleuse ? Puisque l'entreprise productrice semble être la source de l'image dans ce type d'attaques, il ne suffit pas que cette entreprise dispose d'un certificat valide la protégeant. En termes simples, cela augmenterait la crédibilité du faux. 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. Le Valint du Scribe peut être utilisé pour signer et vérifier une grande variété d'artefacts vous offrant cette sécurité supplémentaire que vos utilisateurs obtiennent exactement ce que vous vouliez qu'ils obtiennent.
Regarder vers l'avenir
Personne n’abandonnera l’utilisation de techniques d’automatisation telles que CI/CD pour accélérer son travail. Bien au contraire, dans le monde dans lequel nous vivons, nous réclamons toujours des itérations de mises à jour logicielles toujours plus rapides. Nous devons, à tout le moins, veiller à aborder la tâche avec prudence, en prenant soin de ne pas mettre en péril notre environnement de production ou notre code source dans le processus.
L’essentiel est de considérer les conséquences potentielles d’un accès illégal à votre pipeline, à votre environnement ou à votre code source. Je suis sûr que vous serez en mesure de prendre les mesures appropriées pour arrêter ou atténuer les fuites potentielles une fois que vous aurez réalisé à quel point cela pourrait être dangereux et où vos pipelines et votre réseau sont les plus vulnérables.
Comme les pipelines interconnectés ne feront que gagner en complexité, il est essentiel de maintenir la sécurité globale de votre environnement (réseau segmenté, RBAC, Zero Trust, etc.) comme première étape pour protéger vos pipelines. Après cela, cherchez à créer des preuves solides et infalsifiables et utilisez la signature cryptographique et la vérification des données pour tenter d'atténuer autant que possible le potentiel d'une attaque de la chaîne d'approvisionnement logicielle qui pourrait empoisonner votre pipeline ou le cache de votre pipeline. Rester vigilant et méfiant pourrait épargner à votre entreprise d’innombrables maux de tête.
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
