Pour développer et déployer des applications à grande échelle et à un rythme soutenu, les équipes DevOps s’appuient sur des plateformes dédiées. Dans les grandes organisations, ces environnements peuvent héberger des centaines, voire des milliers d’applications, devenant ainsi des points de défaillance critiques pour l’ensemble du système d’information. Du point de vue d’une équipe Blue Team, cet article explore les moyens de détecter et d’investiguer une compromission au sein d’une instance GitHub Enterprise. Nous détaillerons les services, les journaux d’audit disponibles, ainsi que les bonnes pratiques pour mener une investigation efficace dans ce type d’environnement.
1. Introduction
GitHub Enterprise est devenu un pilier des chaînes DevOps modernes, centralisant le code applicatif, les configurations d’infrastructure et les déploiements CI/CD. Cette centralisation, bien qu’essentielle à l’agilité des équipes, en fait une cible de choix pour les attaquants. Une compromission peut entraîner des conséquences critiques, allant de la fuite de secrets à la prise de contrôle de l’infrastructure.
Dans cet article, nous adoptons la perspective d’un analyste SOC/CERT souhaitant comprendre comment détecter et investiguer une compromission sur une instance GitHub Enterprise Cloud, qu’elle soit utilisée pour quelques dépôts ou pour piloter l’ensemble de l’infrastructure as code de l’organisation. Nous explorerons les menaces clés, telles que l’accès illégitime aux dépôts, la compromission de la plateforme via la gestion des identités, ainsi que les mécanismes de latéralisation hors de GitHub.
Commençons par le nerf de toute investigation…
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
