Cordyceps: La menace de CI / CD qui brise la frontière de la confiance et peut prendre le contrôle des dépôts et voler des titres

Cordyceps, le nom Novee Security donné à un modèle exploitable dans les pipelines CI / CD, est un avertissement urgent pour les projets open source et les grandes organisations: configurations apparemment valides peuvent permettre un attaquant anonyme prendre le contrôle des dépôts, exécuter le code dans les coureurs CI et voler les identifiants, avec des conséquences sur toute la chaîne d'approvisionnement des logiciels.

La racine du problème n'est pas un bogue linéaire, mais une défaillance de composition : les workflows qui, par la façon dont ils sont enchaînés ou par ce qu'ils permettent d'accorder, permettent des données peu fiables de traverser une frontière de confiance. Ainsi, un commentaire, le nom d'une branche malveillante ou une requête de tirage (PR) peut devenir un vecteur pour exécuter des commandes privilégiées dans l'infrastructure d'organisations comme Microsoft, Google, Apache ou Cloudflare, selon le rapport de Novee. Cette fonctionnalité - qu'un compte libre et anonyme peut lancer l'attaque - augmente considérablement le risque.

Le danger est double. D'une part, les effets immédiats sont : le fonctionnement à distance dans les coureurs, les jetons d'exfiltration ou les clés intégrées dans les systèmes d'automatisation et la capacité de fusionner ou de publier du code malveillant. D'autre part, il y a l'effet systémique : compromettre une dépendance ou une librairie populaire peut répandre le code malveillant à d'innombrables projets et clients, générant de multiples dommages qui se souviennent pourquoi la sécurité de la chaîne d'approvisionnement est maintenant une priorité stratégique.

Que ce genre de problème échappe aux outils d'analyse classiques ne devrait pas être surprenant. Les scanners vérifient habituellement que chaque pièce fait "ce qui est supposé", mais pas toujours modéliser la sécurité émergente qui apparaît lorsque différents flux interagissent, l'événement déclenche des permissions croisées et des contextes secrets sont par inadvertance accessibles dans des conditions spécifiques.

Pour l'équipement de maintenance et de sécurité, les recommandations pratiques sont claires et applicables à l'heure actuelle : minimiser les autorisations données par défaut aux jetons et aux workflows ; éviter d'exposer des secrets dans des contextes où les contributions non vérifiées peuvent les activer ; préférer le principe du privilège inférieur dans les workflows et définir explicitement la section autorisations dans les actions GitHub ou les équivalents dans d'autres IC; exiger des examens et des protections des succursales avant d'autoriser les fusions automatiques; et faire pivoter ou supprimer les clés qui ne viennent pas à expiration ou les pipelines.

Il y a aussi des mesures d'atténuation techniques complémentaires qui devraient être adoptées : exécuter des validations dans des coureurs isolés sans accès aux secrets, interdire aux flux de travail des fourches d'utiliser des secrets de dépôt, utiliser des identités éphémères (par exemple OIDC) plutôt que des jetons de longue durée, et auditionner les chaînes de déclenchement pour détecter des points où un événement peu fiable peut induire une exécution avec des privilèges. Il est également pertinent d'incorporer une analyse statique et des règles spécifiques pour détecter les modèles de « franchissement des frontières de confiance » dans CI YAML.

Les grandes organisations doivent supposer que la surface de l'attaque comprend des configurations héritées et des projets populaires maintenus par des communautés ouvertes. En plus d'appliquer le durcissement, il est recommandé d'établir la détection et la réponse : alertes aux changements dans les flux de travail, surveillance des activités chez les coureurs, audit des jetons et approbations automatiques. Pour ceux qui maintiennent des ensembles ou des infrastructures critiques, adhérer à des cadres tels que l'ASLS et les guides de sécurité publique des mesures d'IC contribue à institutionnaliser les bonnes pratiques : https: / / slsa.dev / et le guide officiel de GitHub pour le durcissement des actions sont des points de départ concrets: https: / / docs.github.com / fr / actions / guides de sécurité / actions de sécurité-durcissement-pour-github.

L'affaire Cordyceps rappelle également l'importance d'une divulgation responsable: les constatations rapportées ont conduit à des confirmations et des mesures d'atténuation par les fournisseurs touchés, mais la leçon dure. La sécurité CI / CD n'est pas seulement de bien configurer chaque pièce, mais de comprendre et de vérifier comment ces pièces interagissent. lorsque des contributions externes sont reçues.

Si vous gérez des dépôts ou des plates-formes CI, priorisez maintenant un examen de vos workflows et des permis associés aux jetons, automatisez la détection de modèles dangereux dans votre YAML et examinez toute utilisation de références persistantes dans les systèmes d'automatisation. Pour les équipements de gestion des risques et de gouvernance, il s'agit d'une exigence contractuelle pour les projets critiques : tests de durcissement CI / CD et preuves de rotation d'identification avant d'autoriser les intégrations automatiques.

La menace est réelle, exploitable dans le monde ouvert et capable d'évoluer rapidement; la réponse doit être rapide et structurée: réduire la surface de l'attaque, resserrer les frontières de la confiance et vérifier en permanence la composition de nos pipelines afin que le logiciel que nous livrons n'apporte pas de surprises cachées.