GitHub revêt autant d’importance pour votre organisation que vos applications de production les plus cruciales. La protection de votre propriété intellectuelle et de votre code source est essentielle à la bonne marche de votre entreprise, mais GitHub ne se limite pas à cela. Les données, les configurations et les fichiers hébergés sur GitHub sont le moteur de votre équipe de développement et de votre entreprise.

Mais contrairement à l’hébergement de votre dépôt Git dans un centre de données, l’utilisation de GitHub en tant que service vous oblige à repenser votre approche en matière de protection.

Nous avons décidé de passer en revue les nombreuses façons dont les « données » présentes sur GitHub peuvent être supprimées, corrompues ou altérées.

Suppression accidentelle

1. Suppression de dépôts, de branches, de fichiers, de balises et de versions

Il est facile de supprimer des éléments importants de votre projet en quelques clics ou commandes. Qu’il s’agisse d’un dépôt entier ou d’un fichier essentiel, les suppressions accidentelles constituent un piège courant.

Conseil : Vérifiez toujours deux fois avant d’appuyer sur le bouton « Supprimer ». Mettez en place des règles de protection des branches et limitez les personnes autorisées à supprimer des dépôts.

2. Mauvaise utilisation de git rm et d’autres commandes

Utiliser git rm sans en comprendre pleinement les implications peut entraîner la suppression involontaire de fichiers. Ajoutez à cela une validation précipitée, et vous obtenez la recette idéale pour perdre du code.

Conseil : Familiarisez-vous avec les commandes Git et envisagez de créer des alias pour les commandes dangereuses afin d’exiger une confirmation.

Erreurs de « push » forcé : un grand pouvoir implique de grandes responsabilités

Utilisation inappropriée de git push --force

3. Un « push » forcé peut écraser l’historique distant, effaçant ainsi définitivement des commits.

Conseil : Utilisez git push --force-with-lease pour ajouter un filet de sécurité, et évitez d’effectuer un « push » forcé vers des branches partagées.

4. Réécriture d’historique qui tourne mal

Des commandes telles que git rebase ou git filter-branch, suivies d’un « force push », peuvent réécrire l’historique partagé, ce qui sème la confusion chez les collaborateurs et peut entraîner la perte de commits.

Conseil : Communiquez avec votre équipe avant de réécrire l’historique, et envisagez des alternatives telles que git merge lorsque vous travaillez en collaboration.

Incidents de fusion : quand deux ne font plus qu’un… pour le pire

5. Opérations de fusion incorrectes

La fusion de branches sans résolution correcte des conflits peut entraîner la perte de modifications importantes. Les fusions en mode « fast-forward » peuvent écraser du code que vous n’aviez pas l’intention de modifier.

Conseil : Examinez toujours attentivement les conflits de fusion et envisagez d’utiliser des pull requests pour les revues de code avant la fusion.

Annulation de fusions sans précaution

Annuler un commit de fusion sans en comprendre les implications peut supprimer des portions importantes de code.

Conseil : Utilisez git revert avec prudence et assurez-vous de ne pas annuler des fusions essentielles.

Erreurs de gestion des branches : les dangers d’une mauvaise gestion

6. Négliger de pousser les branches locales

Les branches locales contenant un travail crucial peuvent disparaître si votre machine tombe en panne ou si vous oubliez de les pousser avant de passer à un nouvel environnement.

Conseil : Poussez régulièrement vos branches vers le dépôt distant et envisagez d’utiliser les demandes de pull « brouillon » de GitHub pour en assurer le suivi.

Écrasement de branches

La création d’une nouvelle branche portant le même nom qu’une branche existante, associée à un « force push », peut effacer la branche d’origine.

Conseil : Vérifiez attentivement les noms des branches et évitez le « force push » sauf en cas d’absolue nécessité.

Catastrophes liées aux identifiants : « Sésame, ouvre-toi… » vers le désastre

7. Accès non autorisés et attaques par hameçonnage

Si vos identifiants sont compromis par hameçonnage ou par d’autres moyens, les attaquants peuvent supprimer ou modifier vos dépôts.

Conseil : Activez l’authentification à deux facteurs, utilisez des mots de passe forts et uniques, et restez vigilant face aux tentatives d’hameçonnage.

8. Fuite de jetons et de clés SSH

La fuite de jetons d’accès ou de clés SSH peut donner à des utilisateurs non autorisés les clés de votre royaume.

Conseil : Conservez vos identifiants en toute sécurité, renouvelez régulièrement vos jetons et envisagez d’utiliser les secrets chiffrés de GitHub pour les données sensibles.

Menaces cybernétiques et menaces internes : l’attaque vient de l’intérieur

9. Employés mécontents et départs mal gérés

Les anciens membres de l’équipe disposant encore d’un accès peuvent causer des ravages, que ce soit accidentellement ou intentionnellement.

Conseil : Mettez en place des procédures de départ strictes et vérifiez régulièrement les niveaux d’accès des équipes.

10. Absence de contrôles d’accès

Des autorisations inadéquates peuvent entraîner des suppressions accidentelles de la part de membres de l’équipe bien intentionnés.

Conseil : Utilisez les paramètres d’autorisation de GitHub pour contrôler qui peut pousser, fusionner ou supprimer des branches et des dépôts.

Anomalies d’automatisation : des robots hors de contrôle

11. Erreurs dans le pipeline CI/CD

Des scripts automatisés peuvent supprimer ou écraser du code en raison de mauvaises configurations, transformant ainsi vos bots utiles en forces destructrices.

Conseil : Vérifiez attentivement vos scripts CI/CD et testez-les dans un environnement sécurisé avant de les déployer.

12. Workflows défaillants et autorisations excessives

Les GitHub Actions dotées d’autorisations excessives peuvent provoquer des suppressions involontaires si les scripts tournent mal.

Conseil : Respectez le principe du moindre privilège lors de la configuration des workflows et utilisez des comptes de service dédiés dans la mesure du possible.

Des outils et des commandes qui se retournent contre vous

13. Bugs dans les clients Git et scripts mal configurés

Des bugs logiciels ou des scripts mal écrits peuvent corrompre votre dépôt ou supprimer des données de manière inattendue.

Conseil : Maintenez vos outils à jour et vérifiez soigneusement les scripts avant de les exécuter sur des dépôts importants.

14. Commandes Git dangereuses

Des commandes telles que git clean -fdx peuvent supprimer des fichiers et des répertoires non suivis, ce qui peut parfois avoir des conséquences désastreuses.

Conseil : Utilisez ces commandes avec prudence et envisagez de les exécuter d’abord avec l’option -n (simulation).

Les énigmes de la corruption des données : quand les bits se corrompent

15. Dépôts corrompus

Des problèmes réseau lors des opérations de push/pull peuvent corrompre votre dépôt, rendant les données inaccessibles.

Conseil : Sauvegardez régulièrement vos dépôts et utilisez les outils de récupération intégrés à Git si nécessaire.

16. Problèmes liés aux fichiers binaires et mauvaise gestion de Git LFS

La validation de fichiers binaires volumineux sans Git LFS peut entraîner des problèmes de performances. La suppression incorrecte d’objets LFS peut rendre les fichiers volumineux inaccessibles.

Conseil : Utilisez Git LFS pour les fichiers volumineux et soyez attentif aux quotas et limites de stockage.

Catastrophes de configuration : se mettre en situation d’échec

17. Mauvaise configuration des paramètres du dépôt

Des paramètres incorrects peuvent entraîner une exposition ou une suppression involontaire des données.

Conseil : Vérifiez régulièrement les paramètres de votre dépôt, en particulier lorsque des modifications sont apportées par plusieurs administrateurs.

18. Règles de protection des branches mal appliquées

Des règles trop permissives peuvent autoriser des « force push » ou des suppressions que vous n’aviez pas anticipées.

Conseil : Mettez en place des règles strictes de protection des branches pour les branches principales et imposez les révisions obligatoires.

Les dangers du stockage temporaire et des actions temporisées

19. Perte de travail non synchronisé

Les données stockées dans des emplacements temporaires ou le travail non enregistré peuvent disparaître à la suite de pannes du système ou d’opérations de nettoyage.

Conseil : Enregistrez fréquemment votre travail et effectuez souvent des « push » vers les branches distantes.

20. Tâches planifiées qui tournent mal

Les tâches Cron ou les tâches planifiées peuvent supprimer des données par inadvertance si elles sont mal configurées.

Conseil : Surveillez les tâches planifiées et assurez-vous qu’elles s’exécutent comme prévu, en particulier lorsqu’elles impliquent des suppressions.

Erreurs liées aux sous-modules et à la synchronisation

21. Mauvaise gestion des sous-modules Git

La suppression incorrecte de sous-modules ou la récupération de mises à jour peut écraser les modifications locales.

Conseil : Comprenez le fonctionnement des sous-modules avant de les utiliser et documentez leur utilisation à l’intention de votre équipe.

22. Conflits avec d’autres outils de contrôle de version et services de synchronisation

L’utilisation de plusieurs systèmes de contrôle de version ou la synchronisation de dépôts avec des services cloud peut entraîner une corruption des données.

Conseil : Limitez-vous à un seul système de contrôle de version par projet et évitez de synchroniser les dossiers de dépôt avec des services tels que Dropbox.

Miroir, miroir sur le mur : les dangers d’une mise en miroir incorrecte des dépôts

23. L’utilisation de commandes telles que git push --mirror sans la prudence nécessaire peut écraser l’intégralité du dépôt cible, effaçant d’un seul coup les branches, les balises et l’historique des commits.

Conseil : Avant d’effectuer un push en miroir, vérifiez soigneusement vos URL distantes à l’aide de git remote -v afin de vous assurer que vous effectuez le push vers le bon dépôt. Évitez d’utiliser --mirror à moins d’être certain que c’est bien votre intention. Dans la plupart des cas, un simple git push suffira. Envisagez de mettre en place des mesures de sécurité ou d’utiliser des scripts qui demandent une confirmation avant d’exécuter des opérations destructrices.

Encodage des caractères et chaos lié aux conflits de fusion

24. Incompatibilités d’encodage

Des paramètres d’encodage des caractères incohérents peuvent corrompre le contenu des fichiers, en particulier dans les environnements collaboratifs.

Conseil : Harmonisez les paramètres d’encodage au sein de votre équipe et utilisez des outils pour détecter les problèmes d’encodage.

25. Conflits de fusion non résolus

Valider des fichiers comportant des marqueurs de conflit ou supprimer accidentellement les mauvaises sections de code peut entraîner un code défectueux

Conseil : Résolvez soigneusement les conflits et envisagez des revues de code pour détecter d’éventuelles erreurs.

Difficultés liées au clonage et au « cherry-picking »

26. Clonages superficiels et partiels

L’utilisation de git clone --depth ou le fait d’oublier de cloner les sous-modules et les objets LFS peut entraîner des dépôts incomplets.

Conseil : Clonez les dépôts dans leur intégralité, sauf si vous avez une raison spécifique de ne pas le faire, et assurez-vous que tous les composants nécessaires sont inclus.

27. Mauvaise utilisation de git cherry-pick et git revert

L’application de commits hors contexte ou la restauration incorrecte de modifications peut entraîner des conflits et écraser du code.

Conseil : Utilisez ces commandes avec prudence et assurez-vous de bien comprendre les commits que vous manipulez.

--

Liste de contrôle : consignes pour protéger GitHub

Bien que nous ayons mis en évidence une multitude de façons de perdre vos données GitHub, le message sous-jacent est clair : des erreurs peuvent se produire. Qu’il s’agisse d’une suppression, d’une commande mal comprise ou d’un script mal configuré, vos données sont toujours exposées à des risques.

La protection de vos données GitHub est essentielle pour préserver l’intégrité, la disponibilité et la confidentialité de votre code et des ressources associées. Vous trouverez ci-dessous une brève liste de contrôle des meilleures pratiques pour vous aider à protéger efficacement vos dépôts GitHub.

Renforcez les méthodes d’authentification

• Activez l’authentification unique (SSO) : Intégrez GitHub au fournisseur d’identité (IdP) de votre organisation afin de centraliser l’authentification.
• Exigez l’authentification à deux facteurs (2FA) : Rendez la 2FA obligatoire pour tous les utilisateurs afin d’ajouter un niveau de sécurité supplémentaire. Privilégiez les mots de passe à usage unique basés sur le temps (TOTP) ou les clés de sécurité matérielles plutôt que la 2FA par SMS.

Contrôle d’accès

• Principe du moindre privilège : Accordez aux utilisateurs les autorisations minimales nécessaires à l’exercice de leurs fonctions. Réexaminez et mettez à jour régulièrement les droits d’accès.
• Contrôle d’accès basé sur les rôles (RBAC) : Définissez des rôles (par exemple, administrateur, développeur, testeur) et attribuez les autorisations en conséquence.
• Utilisez GitHub Teams pour gérer les autorisations de groupe.
• Protégez les branches critiques. Activez les règles de protection des branches pour empêcher les « force pushes » et les suppressions, et exigez des vérifications d’état et des revues de code avant toute fusion.
• Gérez les collaborateurs externes : Limitez l’accès des contributeurs tiers et définissez des dates d’expiration pour l’accès des collaborateurs lorsque cela est approprié.

Sécurisez les identifiants et les données sensibles

• Évitez de valider des informations confidentielles : Utilisez des outils tels que GitGuardian ou GitHub Secret Scanning pour détecter les informations confidentielles dans le code. Mettez en place des hooks de pré-commit pour empêcher les commits accidentels de données sensibles.
• Utilisez GitHub Secrets : Stockez en toute sécurité les clés API, les jetons et les mots de passe dans GitHub Secrets pour Actions et Dependabot.
• Renouvelez régulièrement vos identifiants : Modifiez périodiquement les jetons d’accès, les clés SSH et les mots de passe. Veillez à invalider immédiatement les identifiants compromis.

Sauvegarde et restauration

• Sauvegardes automatisées : Planifiez des sauvegardes régulières des dépôts, y compris toutes les branches, balises et tickets
• Stockage hors site : Stockez les sauvegardes dans des emplacements sécurisés et géographiquement distincts. Chiffrez les données de sauvegarde tant en transit qu’au repos.
• Sauvegardes compatibles WORM : Tirez parti des cibles de stockage dans le cloud public et du verrouillage d’objets pour conserver une copie sécurisée en cas de cyberincident.  
• Testez les procédures de restauration : Vérifiez régulièrement que les sauvegardes peuvent être restaurées avec succès. Documentez les étapes de restauration et veillez à les maintenir à jour.

Conclusion : prenez en main vos données GitHub

GitHub est bien plus qu’une simple plateforme : c’est le cœur des efforts de développement de votre organisation, hébergeant non seulement du code, mais aussi la propriété intellectuelle et le travail collaboratif qui font avancer vos projets. Bien que GitHub fournisse les outils et l’infrastructure, la responsabilité de la protection des données contenues dans vos dépôts vous incombe.

Développer en gardant à l’esprit la sécurité et la protection des données ne consiste pas seulement à prévenir les pertes : il s’agit de favoriser une culture de sensibilisation et de diligence. En intégrant ces pratiques à votre flux de travail quotidien, vous créez un environnement résilient où l’innovation peut s’épanouir sans compromettre l’intégrité.

Prenez dès aujourd’hui la responsabilité de vos données GitHub. Ce faisant, vous protégez non seulement les précieux actifs de votre organisation, mais vous renforcez également les fondations sur lesquelles votre équipe pourra s’appuyer pour construire, collaborer et réussir à long terme.