Il y a dix ans, des plateformes comme GitHub étaient principalement perçues comme de simples outils pour développeurs, offrant un espace pratique pour stocker du code source. Aujourd’hui, elles sont devenues le véritable centre de gravité des systèmes d’information. Elles hébergent les mécanismes d’automatisation, les pipelines CI/CD ainsi que l’Infrastructure as Code (IaC). En d’autres termes, ces plateformes se sont imposées comme le moteur d’innovation de l’entreprise moderne.
En conséquence, la manière dont nous développons et déployons des logiciels a radicalement changé. Or, cette concentration sans précédent d’actifs critiques s’accompagne également d’un élargissement rapide de la surface d’attaque. Les environnements DevOps constituent désormais une porte d’entrée directe vers l’environnement de production, ce qui en fait une cible de choix pour les cybercriminels.
Alors que le secteur se focalise souvent sur les risques d’exfiltration de données, une menace bien plus paralysante est en train d’émerger. Les attaquants ne se contentent plus de voler des informations : ils perturbent les opérations en détruisant, en écrasant ou en supprimant définitivement des données critiques pour les équipes de développement. Les conséquences d’un manque de protection de ces actifs peuvent être considérables. Lorsqu’un attaquant efface des dépôts de code ou supprime l’historique des versions logicielles, c’est l’ensemble de la chaîne d’ingénierie qui peut se retrouver à l’arrêt. Chaque minute d’interruption se traduit alors par une perte de productivité significative et par des coûts opérationnels qui s’accumulent rapidement. Pour les organisations opérant à l’échelle de l’EMEA, l’enjeu est encore plus large : une attaque destructrice visant les pipelines CI/CD peut simultanément déclencher des obligations de déclaration d’incident au titre de NIS2, mettre à l’épreuve les mécanismes de responsabilité et de gouvernance exigés par le RGPD et, pour les acteurs des services financiers, révéler des failles de continuité des systèmes d’information et de communication (ICT) que DORA a précisément vocation à prévenir.
Voici les principaux schémas d’attaque destructifs actuellement observés sur le terrain, et les raisons pour lesquelles une stratégie de restauration proactive constitue désormais le seul moyen d’y résister efficacement.
Schéma d’attaque n°1 : suppression malveillante d’artefacts et de versions logicielles
Lors de la récente attaque de la supply chain de Trivy, le groupe cyber TeamPCP ne s’est pas limité au vol de données : il a également cherché à perturber directement le cycle de livraison logicielle. En exploitant des balises (tags) GitHub Actions modifiables, les attaquants sont parvenus à s’introduire discrètement au sein de pipelines CI/CD et à faire main basse sur des jetons d’accès personnels (PAT) à longue durée de validité.
Munis de ces identifiants hautement privilégiés, les cybercriminels ont ensuite supprimé 178 versions logicielles légitimes. Ce type d’attaque vise avant tout à maximiser les perturbations opérationnelles. En l’absence d’un mécanisme permettant de restaurer instantanément les artefacts supprimés, les organisations peuvent être contraintes de reconstruire une partie significative de leur supply chain logicielle. Une telle situation ralentit, voire interrompt, la publication de nouvelles fonctionnalités et la correction des vulnérabilités critiques. Les conséquences opérationnelles de ce type d’attaque s’accompagnent également d’une dimension réglementaire majeure. Dans le cadre de NIS2, les incidents de grande ampleur doivent être signalés aux autorités compétentes dans un délai de 24 heures suivant leur détection. Or, lorsque les artefacts eux-mêmes ont été supprimés, il devient quasiment impossible d’établir précisément le périmètre et l’impact de l’incident, une étape pourtant indispensable à la production de ce signalement.
Schéma d’attaque n°2 : l’écrasement de l’historique par « force-push »
L’historique des versions est souvent considéré, à tort, comme une forme de sauvegarde. L’attaque « ForceMemo » menée contre l’écosystème Python, dans le sillage de l’incident GlassWorm, a démontré les limites de cette hypothèse.
Dans cette campagne, les attaquants ont exploité des identifiants compromis lors d’une précédente intrusion liée à VS Code afin d’accéder à des centaines de comptes GitHub de développeurs. Ils ne se sont pas contentés d’injecter des malwares dans des applications Django et des packages PyPI : ils ont également réécrit l’historique de développement en rebasant des commits légitimes sur les branches principales avant de renvoyer ces modifications vers les dépôts au moyen d’un force-push. Un force-push permet d’écraser l’état historique d’un dépôt et de remplacer une partie de sa chronologie par une nouvelle version. Lorsqu’un attaquant parvient à compromettre une organisation GitHub, cette technique peut être utilisée pour altérer, voire supprimer, l’historique des versions sur lequel les équipes s’appuient pour retracer les changements et revenir à un état antérieur du code. Au-delà de l’impact opérationnel, ce type d’attaque remet directement en cause le principe d’intégrité et de confidentialité consacré par le RGPD. Lorsque l’historique d’un dépôt est altéré ou supprimé, les organisations peuvent se retrouver dans l’incapacité de démontrer avec précision l’état de leur environnement à un instant donné, la nature des modifications apportées ou encore l’origine de ces changements. Or, cette traçabilité constitue un élément essentiel des obligations de responsabilité (accountability) prévues par l’article 5 du RGPD.
Schéma d’attaque n°3 : suppression furtive et effacement des traces
Dans certains cas, la suppression de données ne vise pas à perturber les opérations, mais à dissimuler l’attaque elle-même. Lors de la grande attaque contre l’écosystème NPM rapportée par Axios, des acteurs en lien présumé avec la Corée du Nord auraient compromis le compte du principal mainteneur d’une bibliothèque JavaScript largement utilisée afin de publier une version malveillante du composant.
Pour conserver leur accès et échapper à la détection, les attaquants ont déployé un RAT (Remote Access Trojan) multiplateforme conçu pour supprimer activement ses propres traces d’activité et se remplacer par des fichiers légitimes après son installation. Lorsque les attaquants effacent méthodiquement les éléments de preuve associés à une dépendance compromise, les équipes de sécurité perdent rapidement la visibilité nécessaire pour reconstituer la chronologie de l’incident. Dans ce contexte, des sauvegardes historiques immuables constituent un moyen fiable de réexaminer les arbres de dépendances dans leur état d’origine et d’identifier avec précision le moment où l’environnement a été compromis. Dans le cadre du RGPD, cet enjeu dépasse largement la gestion immédiate de l’incident. Lorsque des données personnelles transitent par les pipelines CI/CD, les organisations doivent être en mesure de démontrer, à tout moment, qu’elles appliquaient des mesures de sécurité adaptées pour protéger leurs environnements. Or, lorsque les traces forensiques ont été effacées ou altérées, cette démonstration devient tout bonnement impossible.
Schéma d’attaque n°4 : prise de contrôle totale de l’environnement
Lorsque des attaquants obtiennent des privilèges administrateur de plus haut niveau, le risque de destruction totale de l’environnement devient bien réel.
Les premières manifestations de ce scénario ont été observées lors de la compromission du code source de Cisco, où le groupe TeamPCP a exploité des identifiants de pipelines CI/CD dérobés pour accéder à des environnements de développement internes. Cette menace ne se limite toutefois pas aux plateformes de développement. Récemment, une vulnérabilité critique de type Stored XSS affectant Jira Work Management permettait à des utilisateurs disposant de privilèges limités de compromettre des comptes Super Admin et, potentiellement, de prendre le contrôle d’une organisation entière. Dans un tel scénario, un attaquant peut obtenir la capacité de supprimer définitivement des projets, des configurations de workflows et des données de suivi du développement logiciel à l’échelle de toute la plateforme. Pour les établissements financiers, ce scénario illustre précisément le type de risque que les exigences de continuité des systèmes ICT de DORA visent à couvrir. Une organisation incapable de restaurer son infrastructure DevOps à partir d’un point de restauration connu, validé et régulièrement testé, s’expose non seulement à une interruption majeure de ses opérations, mais également à un risque de sanction réglementaire.
« Votre pipeline DevOps est le moteur de votre entreprise. Le protéger contre les tentatives de destruction, mais aussi contre les risques de non-conformité réglementaire, est devenu un impératif opérationnel. »
Schéma d’attaque n°4 : prise de contrôle totale de l’environnement
Lorsque des attaquants obtiennent des privilèges administrateur de plus haut niveau, le risque de destruction totale de l’environnement devient bien réel.
Les premières manifestations de ce scénario ont été observées lors de la compromission du code source de Cisco, où le groupe TeamPCP a exploité des identifiants de pipelines CI/CD dérobés pour accéder à des environnements de développement internes. Cette menace ne se limite toutefois pas aux plateformes de développement. Récemment, une vulnérabilité critique de type Stored XSS affectant Jira Work Management permettait à des utilisateurs disposant de privilèges limités de compromettre des comptes Super Admin et, potentiellement, de prendre le contrôle d’une organisation entière. Dans un tel scénario, un attaquant peut obtenir la capacité de supprimer définitivement des projets, des configurations de workflows et des données de suivi du développement logiciel à l’échelle de toute la plateforme. Pour les établissements financiers, ce scénario illustre précisément le type de risque que les exigences de continuité des systèmes ICT de DORA visent à couvrir. Une organisation incapable de restaurer son infrastructure DevOps à partir d’un point de restauration connu, validé et régulièrement testé, s’expose non seulement à une interruption majeure de ses opérations, mais également à un risque de sanction réglementaire.
Rubrik DevOps Protection : gardien de la sécurité de votre moteur d’innovation
LLa protection du code source, des données de gestion de projets et des mécanismes d’automatisation est devenue trop critique pour être reléguée au second plan. Les mécanismes traditionnels (historique natif des versions, scripts CLI difficiles à maintenir, etc.) exposent encore de nombreuses organisations à des risques importants de compromission, d’altération ou de suppression de données. Pour les entreprises de la région EMEA, confrontées à la fois à la menace cyber et à des exigences réglementaires croissantes, cette vulnérabilité n’est plus acceptable.
Rubrik étend aux environnements Azure DevOps et GitHub les capacités de protection des données, d’automatisation et de cyber-résilience déjà utilisées pour les workloads cloud et SaaS, notamment grâce aux fonctionnalités suivantes :
Sauvegardes immuables isolées par un air-gap logique : nous protégeons votre propriété intellectuelle critique grâce à des sauvegardes immuables isolées par un air-gap logique, entièrement administrées par Rubrik. Même en cas de compromission complète d’un compte administrateur GitHub, un attaquant ne peut ni chiffrer, ni modifier, ni supprimer les données nécessaires à la restauration. Cette immutabilité, qui empêche les cybercriminels d’altérer les sauvegardes, offre également aux équipes conformité, risque et juridique un historique fiable et infalsifiable. Un atout essentiel pour répondre aux exigences de traçabilité, de responsabilité et d’audit imposées notamment par le RGPD et NIS2.
Protection automatisée pilotée par des SLA Affranchissez-vous de la complexité des scripts personnalisés. Rubrik détecte automatiquement les nouveaux dépôts et applique les politiques de protection à grande échelle, garantissant une sauvegarde continue des données sans intervention manuelle. Cette approche permet de répondre aux exigences de gestion des sauvegardes inscrites dans l’article 21 de NIS2, ainsi qu’aux politiques de sauvegarde et de restauration prévues par l’article 12 de DORA, sans alourdir la charge opérationnelle des équipes DevOps et sécurité.
Restauration flexible et performante Restaurez rapidement vos environnements face à tout type d’incident, qu’il s’agisse d’un sinistre, d’une erreur humaine ou d’une cyberattaque. Que vous deviez effectuer une restauration granulaire au niveau d’un dépôt après un force-push malveillant ou remettre en service des environnements multi-plateformes et multi-tenant lors d’une interruption de grande ampleur, Rubrik permet de restaurer rapidement le code et les configurations à l’emplacement souhaité. Cette rapidité constitue un enjeu opérationnel majeur. Elle contribue également à répondre aux exigences de reprise d’activité et de continuité des systèmes ICT définies par DORA, tout en facilitant la collecte des éléments factuels nécessaires à l’évaluation et à la notification des incidents dans les délais imposés par NIS2, notamment lors de la fenêtre de 24 heures pour le signalement initial.
Gouvernance unifiée à l’échelle de l’entreprise : bénéficiez d’une vue centralisée de vos données de développement en parallèle de vos environnements Cette approche offre une visibilité consolidée sur l’ensemble de vos actifs critiques, ainsi que les capacités de reporting et de traçabilité nécessaires pour répondre aux exigences de responsabilité du RGPD et aux obligations de supervision et de gouvernance prévues par NIS2.
L’impératif stratégique : renforcer la résilience de votre pipeline Code-to-Cloud
N’attendez pas qu’un attaquant supprime l’un des actifs les plus précieux de votre organisation : son code. Le paysage des menaces a profondément évolué et, pour les structures opérant en EMEA, les exigences réglementaires qui l’accompagnent ont évolué elles aussi. Votre stratégie de protection des données doit désormais répondre simultanément à ces deux réalités.
Le webinaire en replay Secure your Innovation Engine vous propose une démonstration de Rubrik DevOps Protection et de sa capacité à protéger votre environnement GitHub, du code au cloud. Vous pouvez également participer à nos ateliers pratiques consacrés à la protection d’Azure DevOps avec Rubrik et à la sécurisation de votre organisation GitHub contre la perte de données, la corruption et les cybermenaces.
Certains services ou fonctionnalités mentionnés dans ce document n’ont pas encore été publiés et ne sont donc pas disponibles actuellement. Leur disponibilité générale peut être retardée ou annulée, à notre entière discrétion. Lesdits services ou fonctionnalités n’impliquent aucune promesse ou obligation ni aucun engagement de la part de Rubrik et ne peuvent être intégrés dans aucun contrat. Les clients sont invités à prendre leurs décisions d’achat en fonction des services et fonctionnalités officiellement disponibles (GA).