Les pull requests malveillantes accroissent les risques pour les workflows de développement largement utilisés

Une nouvelle vulnérabilité mise en évidence dans les workflows CI/CD attire l’attention sur la manière dont les projets open source et de développement cloud gèrent les contributions de code. Le problème concerne les pull requests malveillantes, qui peuvent être utilisées pour introduire des modifications nuisibles dans les processus automatisés de compilation et de mise en production lorsque les contrôles de revue et de validation ne sont pas suffisamment robustes.

Selon le rapport, cette faiblesse des workflows affecte plusieurs projets et outils de développement connus, notamment Azure Sentinel de Microsoft, l’AI Agent Development Kit de Google, Apache Doris, le SDK Workers de Cloudflare et le formateur Black de la Python Software Foundation. Bien que ces projets s’adressent à des communautés et répondent à des usages différents, ils reposent tous sur des pipelines de livraison logicielle qui peuvent devenir des cibles attrayantes lorsque la confiance accordée aux contributeurs se conjugue à l’automatisation.

Les chercheurs en sécurité et les responsables de maintenance avertissent de plus en plus que les attaques par pull request peuvent être efficaces, car elles exploitent les pratiques normales de collaboration. Dans de nombreux environnements de développement modernes, le code provenant de contributeurs externes est testé automatiquement avant d’être fusionné. Si ces vérifications ne sont pas soigneusement isolées, un attaquant peut être en mesure d’influencer les étapes de compilation, d’exposer des secrets ou d’introduire des modifications difficiles à repérer lors d’une revue de routine.

Pourquoi ce problème est important

Même lorsqu’une pull request ne modifie pas directement les systèmes de production, elle peut néanmoins créer un risque sérieux pour l’ensemble de la chaîne d’approvisionnement logicielle. Une compromission au stade du développement peut se propager aux versions distribuées, aux packages et aux environnements des utilisateurs.

• L’automatisation peut exécuter du code non fiable pendant la revue ou les tests.
• Des secrets, des jetons ou des clés de signature peuvent être exposés si les contrôles du pipeline sont insuffisants.
• Des projets de confiance peuvent devenir des points d’entrée pour des attaques plus vastes visant la chaîne d’approvisionnement.

Le rapport souligne la nécessité de renforcer les garde-fous autour des workflows de contribution, notamment au moyen d’autorisations plus strictes, d’une gestion plus sûre des secrets et d’une exécution CI/CD plus restrictive pour les contributions externes. Pour les équipes qui assurent la maintenance d’outils et d’infrastructures populaires, la conclusion est simple : la facilité de collaboration ne doit pas se faire au détriment de la sécurité des pipelines.