Le mois dernier, je suis tombé sur cet article. de Lecture sombre. Cela semblait très familier. Il ne m'a pas fallu longtemps pour réaliser que la vulnérabilité d'empoisonnement des artefacts entre flux de travail GitHub évoquée dans l'article présentait une ressemblance frappante avec le flux de travail croisé GitHub. empoisonnement du cache vulnérabilité dont nous avons rendu compte en mars 2022.
Workflows GitHub : un composant clé des pipelines GitHub CI/CD
Les workflows GitHub sont utilisés pour définir les actions spécifiques qui doivent être prises dans le cadre du pipeline CI/CD. Ce sont des processus automatisés qui peuvent être déclenchés par des événements spécifiques dans un référentiel GitHub. De tels événements, par exemple, se produisent lorsque le code est poussé vers le référentiel, lorsqu'une demande d'extraction est ouverte ou fermée, ou lorsqu'une nouvelle version est publiée.
Les workflows sont créés à l'aide d'un fichier YAML, qui spécifie les actions à entreprendre lorsque le workflow est déclenché. De telles actions peuvent être écrites par le développeur ou extraites intégralement du marché GitHub où plus de 10,000 XNUMX actions prédéfinies peuvent être téléchargées et utilisées.
Les flux de travail sont constitués d'une ou plusieurs tâches définies comme une série d'étapes. Les étapes peuvent consister en diverses actions, telles que l'exécution de tests, le déploiement de code ou la publication d'un package.
Les flux de travail GitHub sont un outil puissant qui peut aider les développeurs à automatiser et à rationaliser leurs flux de travail, en économisant du temps et des efforts et en améliorant la fiabilité de leur processus de développement logiciel, mais ils ne sont pas sans défauts inhérents.
Plusieurs problèmes de sécurité potentiels peuvent survenir lors de l'utilisation des workflows GitHub. En voici quelques-uns courants :
- L'accès non autorisé: Les flux de travail qui ne sont pas correctement configurés ou sécurisés pourraient potentiellement être consultés et déclenchés par des utilisateurs non autorisés. Cela pourrait leur permettre d’exécuter du code arbitraire ou d’effectuer d’autres actions non autorisées.
- Fuite de secrets: Les workflows nécessitent souvent l'utilisation de secrets, tels que des clés API ou des mots de passe, pour accéder à des ressources externes ou effectuer certaines actions. Si ces secrets ne sont pas correctement protégés, ils pourraient potentiellement être divulgués, entraînant des failles de sécurité.
- Dépendance précaires : les workflows qui s'appuient sur des bibliothèques ou des dépendances externes pourraient potentiellement être vulnérables aux attaques si ces dépendances ne sont pas sécurisées. Il est important d’examiner et de mettre à jour régulièrement les dépendances pour garantir leur sécurité.
- Manque de validation et de désinfection des entrées: Les workflows qui ne valident pas correctement les entrées pourraient potentiellement être exploités pour exécuter du code arbitraire ou effectuer d'autres actions non autorisées.
Examinons de plus près les deux vulnérabilités inter-workflow évoquées dans les articles mentionnés ci-dessus.
Empoisonnement d'artefacts entre flux de travail
Les artefacts de workflow GitHub sont le produit du travail effectué dans les pipelines CI/CD. Habituellement, chaque flux de travail dispose de son propre compartiment pour stocker ces artefacts, mais les flux de travail doivent parfois accéder aux artefacts créés par d'autres flux de travail. GitHub ne permet pas aux workflows d'accéder directement au stockage/aux artefacts de différents workflows. Pour contourner ce problème, il existe une API approuvée par GitHub qui permet de télécharger des artefacts basés sur un filtrage de base. Le problème est que l'API ne fait pas la différence entre les artefacts téléchargés par les référentiels forkés et ceux téléchargés par les référentiels de base. Cela signifie que le téléchargement d’artefacts potentiellement empoisonnés créés par des référentiels forkés constitue un danger réel et actuel.
Pour résoudre ce problème, GitHub a commencé à fournir des informations supplémentaires, ainsi que des métadonnées d'artefacts lors du téléchargement d'artefacts. Ces informations sont conçues pour aider l'auteur à s'assurer qu'il télécharge le bon artefact. Le problème de base des artefacts inter-workflow n’est pas considéré comme un problème par GitHub pour le moment. Pour en savoir plus sur ce problème, consultez le article mentionné ci-dessus.
Empoisonnement du cache entre workflows
GitHub permet la mise en cache des artefacts et des packages pour accélérer le pipeline CI/CD. Au lieu de télécharger encore et encore les artefacts et les packages nécessaires pour chaque flux de travail dans lequel ils peuvent être nécessaires, ils peuvent être mis en cache et utilisés dans différents flux de travail.
Étant donné que le cache est partagé entre les workflows, il suffit d'une seule violation dans un workflow utilisant le cache avec l'autorisation de le modifier, et ce cache peut être empoisonné pour toutes les utilisations suivantes du workflow. Étant donné que le cache n'est mis à jour que lorsqu'il y a un nouvel artefact ou un nouvel package à télécharger, cela signifie qu'un seul cache empoisonné peut être actif pendant une longue période, influençant d'innombrables itérations de versions logicielles exécutées dans ce pipeline.
GitHub ne considère pas la question d'un cache potentiellement empoisonné comme un problème. Le cache est une fonctionnalité utile et sa capacité à être partagée entre les flux de travail n’est pas considérée comme un bug ou un véritable problème de sécurité pour le moment. Pour en savoir plus sur ce problème, consultez le article mentionné ci-dessus.
Autres vulnérabilités GitHub moins connues et comment s'en défendre
GitHub est l'un des systèmes de gestion du contrôle de source (SCM) les plus populaires au monde. En tant que tel, il est également largement utilisé pour créer et distribuer des logiciels à l’aide de son pipeline CI/CD, de ses actions et de ses flux de travail.
Les gens doivent se rappeler que GitHub a été créé pour faciliter le partage de code et le développement conjoint. Il a été conçu à l'origine pour les développeurs open source et les fonctionnalités de compte d'entreprise et d'organisation ont été ajoutées ultérieurement. À la base, la sécurité n’était pas une préoccupation majeure du système. Le fait que vous deviez faire un mise en place spéciale sur GitHub pour activer les fonctionnalités de sécurité sur votre compte signifie que l'idée selon laquelle en utilisant Git vous êtes intrinsèquement plus sécurisé n'est qu'une illusion.
Plus tard ce mois-ci, Scribe accueillera Tzachi Zornstain, responsable de la chaîne d'approvisionnement logicielle chez Checkmarx, lors d'un webinaire pour parler de quelques-uns de ces pièges potentiels de la chaîne d'approvisionnement logicielle dans GitHub.
Si vous souhaitez en savoir plus sur cette classe de vulnérabilités moins connue et comment vous en défendre, écoutez ceci à la demande. séminaire en ligne.
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
