30 façons de perdre vos données GitHub (et comment les éviter)

GitHub est aussi critique pour vos organisations que vos applications de production les plus importantes. La protection de votre propriété intellectuelle et de votre code source est essentielle, mais ce n'est pas tout ce que contient GitHub . Les données, les configurations et les fichiers contenus dans GitHub alimentent votre équipe de développement et 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 à penser différemment à la façon dont vous le protégez.  

Nous avons décidé d'examiner les nombreuses façons dont les "données" contenues dans GitHub peuvent être supprimées, corrompues ou modifiées.  

Suppression accidentelle

1. Supprimer des dépôts, des branches, des fichiers, des étiquettes, des versions

Il est facile de supprimer des parties importantes de votre projet en quelques clics ou commandes. Qu'il s'agisse d'un référentiel entier ou d'un fichier critique, les suppressions accidentelles sont un piège courant.

Conseil : Vérifiez toujours deux fois avant d'appuyer sur le bouton de suppression. Mettez en place des règles de protection des branches et limitez le nombre de personnes autorisées à supprimer des référentiels.

2. L'utilisation abusive git rm et autres commandes

Utilisation git rm sans en comprendre pleinement l'impact peut conduire à des suppressions de fichiers involontaires. Combinez cela à une validation hâtive et vous obtiendrez une recette pour un code manquant.

Conseil : Familiarisez-vous avec les commandes Git et envisagez de créer des alias pour les commandes dangereuses qui nécessitent une confirmation.

Force Push Errors : Un grand pouvoir implique une grande responsabilité

Utilisation abusive de git push --force

3. Le "force pushing" peut écraser l'historique distant, effaçant ainsi les "commits" de l'existence.  

Conseil : Utilisation git push --force-with-lease afin d'ajouter un filet de sécurité et d'éviter de forcer les branches partagées.

4. Réécrire l'histoire qui a mal tourné

Des commandes telles que git rebase ou git filter-branch suivie d'une poussée forcée peut réécrire l'historique partagé, confondre les collaborateurs et potentiellement perdre des commits.

Conseil : Communiquez avec votre équipe avant de réécrire l'histoire et envisagez des alternatives telles que git merge lorsqu'ils travaillent en collaboration.

Mises en scène de fusion : Quand deux ne font qu'un... Mal

5. Opérations de fusion incorrectes

Fusionner des branches sans résoudre correctement les conflits peut entraîner l'abandon de modifications importantes. Les fusions en avance rapide 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 les demandes d'extraction pour les révisions de code avant de les fusionner.

Revenir sur des fusions sans précaution

L'annulation d'un commit de fusion sans en comprendre les implications peut supprimer d'importants morceaux de code.

Conseil : Utilisation git revert avec prudence et assurez-vous que vous n'annulez pas des fusions essentielles.

Les bévues de la direction générale : Les dangers de la mauvaise gestion

6. Négliger de pousser les branches locales

Les branches locales contenant des travaux essentiels peuvent disparaître si votre machine tombe en panne ou si vous oubliez de les transférer avant de passer à un nouvel environnement.

Astuce : Poussez régulièrement vos branches vers le dépôt distant et envisagez d'utiliser les brouillons de demandes d'extraction de GitHub pour en assurer le suivi.

Ecrasement des branches

La création d'une nouvelle branche portant le même nom qu'une branche existante et la poussée forcée peuvent effacer la branche d'origine.

Conseil : Vérifiez soigneusement les noms des branches et évitez de les forcer, sauf en cas d'absolue nécessité.

Catastrophes liées aux titres de compétences : Sésame... pour la catastrophe

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

Si vos informations d'identification sont compromises par hameçonnage ou par d'autres moyens, les attaquants peuvent supprimer ou modifier vos référentiels.

Conseil : Activez l'authentification à deux facteurs, utilisez des mots de passe forts et uniques et soyez vigilants face aux tentatives de phishing.

8. Exposition au jeton et à la clé 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 : Stockez vos identifiants en toute sécurité, changez régulièrement de tokens et envisagez d'utiliser les secrets cryptés de GitHub pour les données sensibles.

Cybermenaces et menaces internes : L'appel vient de l'intérieur du Parlement

9. Employés mécontents et licenciement abusif

Les anciens membres de l'équipe qui disposent d'un accès persistant peuvent causer des dégâts, que ce soit accidentellement ou intentionnellement.

Conseil : mettez en place des procédures strictes d'intégration et vérifiez régulièrement les niveaux d'accès de l'équipe.

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

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

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

Anomalies d'automatisation : Les robots malhonnêtes

11. Erreurs dans le pipeline CI/CD

Les scripts automatisés peuvent supprimer ou écraser du code en raison d'une mauvaise configuration, transformant vos robots utiles en forces destructrices.

Conseil : Examinez attentivement vos scripts CI/CD et testez-les dans un environnement sûr avant de les déployer.

12. Flux de travail défectueux et autorisations excessives

GitHub Les actions avec des permissions excessives peuvent entraîner des suppressions involontaires si les scripts ne fonctionnent pas correctement.

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

Les outils et les commandes se retournent contre vous

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

Des bogues de logiciels ou des scripts mal écrits peuvent corrompre votre référentiel ou supprimer des données de manière inattendue.

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

14. Commandes Git dangereuses

Des commandes telles que git clean -fdx peut supprimer des fichiers et des répertoires non suivis, avec parfois des effets désastreux.

Conseil : Utilisez ces commandes avec prudence et envisagez de les exécuter avec l'option -n (essai à blanc) en premier lieu.

Les énigmes de la corruption des données : Quand les bits se gâtent

15. Dépôts corrompus

Des problèmes de réseau pendant les opérations de push/pull peuvent corrompre votre référentiel et rendre 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 transmission de fichiers binaires volumineux sans Git LFS peut entraîner des problèmes de performance. La suppression incorrecte d'objets LFS peut rendre les fichiers volumineux inaccessibles.

Conseil : utilisez Git LFS pour les fichiers volumineux et tenez compte des quotas et des limites de stockage.

Calamités de configuration : Se préparer à l'échec

17. Mauvaise configuration des paramètres du référentiel

Des réglages incorrects peuvent entraîner l'exposition ou la suppression involontaire de données.

Conseil : Révisez régulièrement les paramètres de votre référentiel, en particulier lorsque des modifications sont apportées par plusieurs administrateurs.

18. Règles de protection de la branche mal appliquées

Des règles trop permissives peuvent permettre des passages en force ou des suppressions que vous n'aviez pas prévus.

Conseil : Établissez des règles strictes de protection des succursales pour les succursales principales et appliquez les révisions requises.

Les dangers du stockage temporaire et des actions basées sur le temps

19. Perte de travaux non synchronisés

Les données stockées dans des emplacements temporaires ou les travaux non sauvegardés peuvent disparaître à la suite d'une panne du système ou d'une opération de nettoyage.

Conseil : sauvegardez fréquemment votre travail et transférez souvent les modifications vers des branches distantes.

20. Des travaux programmés qui tournent mal

Les travaux Cron ou les tâches planifiées peuvent supprimer des données involontairement s'ils sont mal configurés.

Conseil : surveillez les tâches programmées et assurez-vous qu'elles se déroulent comme prévu, en particulier lorsqu'il s'agit de suppressions.

Glissements de sous-module et de synchronisation

21. Mauvaise gestion des sous-modules Git

La suppression incorrecte de sous-modules ou l'extraction de mises à jour peut écraser les modifications locales.

Conseil : comprenez le fonctionnement des sous-modules avant de les utiliser et documentez leur utilisation pour votre équipe.

22. Conflits avec d'autres outils VCS et services de synchronisation

L'utilisation de plusieurs systèmes de contrôle de version ou la synchronisation des référentiels avec des services en nuage peut entraîner une corruption.

Conseil : s'en tenir à un seul VCS par projet et éviter de synchroniser les dossiers du référentiel avec des services tels que Dropbox.

Miroir, miroir sur le mur : Les dangers d'une mise en miroir incorrecte des référentiels

23. En utilisant des commandes comme git push --mirror sans précaution peut écraser l'ensemble du référentiel cible, effaçant d'un seul coup les branches, les balises et l'historique des livraisons.

Conseil : avant d'effectuer une poussée miroir, vérifiez vos URL distantes à l'aide de la fonction git remote -v pour vous assurer que vous poussez vers le bon dépôt. Évitez d'utiliser --miroir sauf si vous êtes certain que c'est votre intention. Dans la plupart des cas, un git push suffira. Pensez à mettre en place des mesures de protection ou à utiliser des scripts qui demandent une confirmation avant d'exécuter des opérations destructrices.

Encodage des caractères et fusion du chaos conflictuel

24. Inadéquation de l'encodage

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

Conseil : uniformisez 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

La validation de fichiers comportant des marqueurs de conflit ou l'élimination accidentelle de sections de code erronées peuvent entraîner des ruptures de code.

Conseil : Résolvez soigneusement les conflits et envisagez des révisions de code pour repérer les erreurs éventuelles.

Les défis du clonage et de la cueillette des cerises

26. Clones superficiels et partiels

Utilisation git clone --depth ou l'oubli de cloner les sous-modules et les objets LFS peuvent entraîner des dépôts incomplets.

Conseil : Clonez entièrement les dépôts, sauf si vous avez une raison particulière de ne pas le faire, et assurez-vous que tous les composants nécessaires sont inclus.

27. L'utilisation abusive de git cherry-pick et git revert

L'application de modifications hors contexte ou l'annulation incorrecte de modifications peut entraîner des conflits et écraser du code.

Conseil : utilisez ces commandes avec prudence et comprenez bien les commits que vous manipulez.

--  

Liste de contrôle : Lignes directrices pour la protection GitHub  

Bien que nous ayons mis en évidence une pléthore de façons de perdre vos données GitHub , le thème sous-jacent est clair : les erreurs se produisent. Qu'il s'agisse d'une suppression, d'une commande mal comprise ou d'un script mal configuré, vos données sont toujours en danger.

La protection de vos données GitHub est cruciale pour maintenir l'intégrité, la disponibilité et la confidentialité de votre code et des actifs connexes. Vous trouverez ci-dessous une brève liste de bonnes pratiques pour vous aider à protéger efficacement vos dépôts GitHub .

Renforcer les méthodes d'authentification

• Activer l'authentification unique (SSO) : Intégrez GitHub au fournisseur d'identité (IdP) de votre organisation pour centraliser l'authentification.

• Exiger l'authentification à deux facteurs (2FA) : Exiger l'authentification à deux facteurs pour tous les utilisateurs afin d'ajouter une couche de sécurité supplémentaire. Préférez les mots de passe à usage unique basés sur le temps (TOTP) ou les clés de sécurité matérielles à l'authentification à deux facteurs basée sur les SMS.

Contrôle d'accès

• Principe du moindre privilège: Accorder aux utilisateurs les autorisations minimales nécessaires à leur rôle. Réviser et mettre à jour régulièrement les droits d'accès.

• Contrôle d'accès basé sur les rôles (RBAC) : Définir des rôles (par exemple, administrateur, développeur, testeur) et attribuer des autorisations en conséquence.

• Utilisez GitHub Teams pour gérer les autorisations de groupe.

• Protéger les branches critiques. Activez les règles de protection des branches pour empêcher les poussées et les suppressions forcées et exiger des vérifications d'état et des revues de code avant la fusion.

• Gérer les collaborateurs externes : Limitez l'accès des contributeurs tiers et fixez des dates d'expiration pour l'accès des collaborateurs, le cas échéant.

Sécuriser les informations d'identification et les données sensibles

• Évitez de livrer des secrets : Utilisez des outils tels que GitGuardian ou GitHub Secret Scanning pour détecter les secrets dans le code. Mettez en place des hooks de pré-commission pour éviter les commits accidentels de données sensibles.

• Utilisez GitHub Secrets : Stockez les clés d'API, les jetons et les mots de passe en toute sécurité sur GitHub Secrets pour Actions et Dependabot.

• Changez régulièrement vos informations d'identification : Changez régulièrement les jetons d'accès, les clés SSH et les mots de passe. Veillez à invalider immédiatement les informations d'identification compromises.

Sauvegarde et récupération

• Sauvegardes automatisées : Programmation de sauvegardes régulières des référentiels, y compris toutes les branches, les étiquettes et les problèmes.

• Stockage hors site : Stocker les sauvegardes dans des lieux sécurisés et géographiquement séparés. Crypter les données de sauvegarde en transit et au repos.

• Sauvegardes à l'aide d'un WORM : Exploitez les cibles de stockage dans les nuages publics et le verrouillage des objets pour conserver une copie sûre en cas d'événement cybernétique.  

• Tester les procédures de restauration : Vérifier périodiquement que les sauvegardes peuvent être restaurées avec succès. Documenter les étapes de la restauration et les tenir à jour.

Conclusion : Appropriez-vous vos données GitHub

GitHub est plus qu'une plateforme - c'est le cœur des efforts de développement de votre organisation, abritant non seulement le 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, c'est à vous qu'incombe la responsabilité de protéger les données contenues dans vos référentiels.

Développer en gardant à l'esprit la sécurité et la protection des données ne consiste pas seulement à prévenir les pertes, mais aussi à encourager une culture de la sensibilisation et de la diligence. En intégrant ces pratiques dans votre travail quotidien, vous créez un environnement résilient où l'innovation peut prospérer sans compromettre l'intégrité.

Prenez possession de vos données GitHub dès aujourd'hui. Ce faisant, vous protégez non seulement les actifs précieux de votre organisation, mais vous renforcez également les fondations sur lesquelles votre équipe peut construire, collaborer et réussir à l'avenir.

‍

Ressources complémentaires

• Demandez votre essai gratuit GitHub ‍
• Pour plus de détails, inscrivez-vous pour un essai gratuit‍
• Améliorez vos capacités avec R-Cloud‍
• Découvrez le potentiel de R-Graph grâce à un test complet

‍

‍