CI/CD & chaîne d'approvisionnement

Votre pipeline de build a accès à la production. Une commande injectée change tout.

Les attaquants ciblent de plus en plus les pipelines de build plutôt que les applications directement, car les pipelines ont accès aux identifiants de production, aux clés de déploiement et à chaque environnement que votre code touche. Cette évaluation trouve chaque chemin depuis une pull request non fiable ou un secret fuité jusqu'à l'accès complet au déploiement.

• →Injection dans le pipeline : un titre de pull request, un nom de branche ou un message de commit peut-il déclencher des commandes non souhaitées lors du build ?
• →Fuite d'identifiants : des secrets sont-ils affichés dans les logs de build ou mis en cache entre les exécutions de pipeline ?
• →Identifiants en dur : des clés API ou mots de passe sont-ils stockés dans le dépôt ou son historique de commits ?
• →Confusion de dépendances : un package malveillant pourrait-il être installé à la place d'un légitime interne ?
• →Permissions du pipeline : les jobs de build ont-ils plus d'accès aux systèmes de production qu'ils n'en ont besoin ?
• →Sécurité des runners auto-hébergés : la machine de build est-elle exposée à internet ou insuffisamment isolée ?
• →Dépendances de build tierces : une action ou un script externe utilisé dans votre pipeline pourrait-il exécuter du code contrôlé par un attaquant ?
• →Intégrité des artefacts : les sorties de build sont-elles vérifiées avant le déploiement ?