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

GitHub est aussi important pour vos organisations que vos applications de production les plus importantes. Votre propriété intellectuelle et votre code source sont essentiels à protéger, mais ce n'est pas tout ce que contient GitHub. Les données, les configurations et les fichiers de GitHub alimentent votre équipe de développement et votre entreprise.

Mais contrairement à l'hébergement de votre référentiel Git dans un centre de données, l'utilisation de GitHub en tant que service vous oblige à réfléchir différemment à la manière dont vous le protégez.

Nous avons décidé d'analyser les nombreuses façons dont les " données " de 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 avant d'appuyer sur le bouton de suppression. Mettez en place des règles de protection des branches et limitez les personnes autorisées à supprimer des référentiels.

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

L'utilisation de git rm sans en comprendre pleinement l'impact peut conduire à des suppressions de fichiers involontaires. Combinez cela avec un commit précipité, et vous avez une recette pour un code manquant.

Conseil:Familiarisez-vous avec les commandes Git et envisagez d'aliaser les commandes dangereuses pour demander une confirmation.

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

Utilisation incorrecte de git push --force

3. La poussée forcée peut écraser l'historique distant, ce qui efface effectivement les commits de l'existence.

Conseil:Utilisez git push --force-with-lease pour ajouter un filet de sécurité, et évitez de forcer les branches partagées.

4. Réécriture de l'historique qui a mal tourné

Des commandes comme git rebase ou git filter-branch suivies d'une poussée forcée peuvent réécrire l'historique partagé, confondant les collaborateurs et perdant potentiellement des commits.

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

Maladresses de fusion : Quand deux deviennent 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 rapides peuvent écraser du code que vous n'aviez pas l'intention de modifier.

Conseil:Examinez toujours soigneusement les conflits de fusion et envisagez d'utiliser les demandes de tirage pour les révisions de code avant de procéder à la fusion.

Renvoyer des fusions sans précaution

Annuler un commit de fusion sans comprendre ses implications peut supprimer d'importants morceaux de code.

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

Les bévues de branche : 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 draft pull requests de GitHub pour en garder la trace.

Overwriting Branches

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

Conseil:Vérifiez soigneusement les noms de branches et évitez le push forcé sauf en cas d'absolue nécessité.

Catastrophes d'identifiants : 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:Activer l'authentification à deux facteurs, utiliser des mots de passe forts et uniques, et être vigilant face aux tentatives d'hameçonnage.

8 Exposition 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:Stockez les informations d'identification en toute sécurité, effectuez une rotation régulière des jetons et envisagez d'utiliser les secrets cryptés de GitHub pour les données sensibles.

Menaces cybernétiques et menaces d'initiés : L'appel vient de l'intérieur

9. Employés mécontents et intégration inadéquate

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

Conseil:Mettez en place des procédures d'intégration strictes 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.

Conseil:Utilisez les paramètres d'autorisation de GitHub pour contrôler qui peut pousser, fusionner ou supprimer des branches et des référentiels.

Automation Anomalies : Robots malhonnêtes

11. Erreurs de pipeline CI/CD

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

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

12. Workflows défectueux et permissions excessives

Les actions GitHub avec des permissions excessives peuvent exécuter des suppressions involontaires si les scripts ne fonctionnent pas correctement.

Conseil:Suivez le principe du moindre privilège lors de la configuration des workflows et utilisez des comptes de service dédiés lorsque cela est possible.

Les outils et les commandes 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 référentiel ou supprimer des données de manière inattendue.

Conseil:Maintenez vos outils à jour et vérifiez deux fois les scripts avant de les exécuter sur des référentiels importants.

14. Commandes Git dangereuses

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

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

Les énigmes de la corruption des données : Quand les bits tournent mal

15. Dépôts corrompus

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

Tip:Sauvegardez régulièrement vos dépôts et utilisez les outils de récupération intégrés de 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 performance. La suppression incorrecte des 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 paramètres incorrects peuvent entraîner l'exposition ou la suppression involontaire de données.

Tip:Revoyez 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 des branches 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:Mettez en place des règles de protection des branches strictes pour les branches principales et appliquez les révisions requises.

Les périls 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 en raison de pannes de système ou d'opérations de nettoyage.

Tip:Sauvegardez fréquemment vos travaux et transférez souvent les modifications vers des branches distantes.

20. Les tâches planifiées qui tournent mal

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

Conseil:Surveillez les tâches planifiées et assurez-vous qu'elles fonctionnent comme prévu, en particulier lorsqu'il s'agit de suppressions.

Les dérapages des sous-modules et de la synchronisation

21. Mauvaise gestion des sous-modules Git

La suppression incorrecte de sous-modules ou le retrait de mises à jour peut écraser les modifications locales.

Tip: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 de référentiel avec des services tels que Dropbox.

Miroir, miroir sur le mur : Les dangers d'un miroir de référentiel incorrect

23. L'utilisation de commandes comme git push --mirror sans précaution peut écraser l'ensemble du dépôt cible, effaçant les branches, les balises et l'historique des commits d'un seul coup.

Conseil : Avant d'effectuer un push miroir, vérifiez deux fois vos URLs distantes en utilisant git remote -v pour vous assurer que vous poussez vers le bon dépôt. Evitez d'utiliser --mirror à moins d'être certain que c'est votre intention. Dans la plupart des cas, un git push normal suffira. Envisagez de mettre en place des mesures de protection ou d'utiliser des scripts qui demandent une confirmation avant d'exécuter des opérations destructrices.

Character Encoding and Merge Conflict Chaos

24. Inadéquations de codage

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

Tip:Standardisez les paramètres de codage au sein de votre équipe et utilisez des outils pour détecter les problèmes de codage.

25. Conflits de fusion non résolus

Commettre des fichiers avec des marqueurs de conflit ou rejeter accidentellement les mauvaises sections de code peut conduire à un code cassé

Conseil:Résolvez soigneusement les conflits et envisagez des révisions de code pour détecter toute erreur.

Défis liés au clonage et à la cueillette

26. Clones superficiels et partiels

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

Conseil:Le clonage complet des dépôts à moins que vous n'ayez 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-picket git revert

L'application de commits hors contexte ou l'inversion incorrecte de changements peut provoquer des conflits et écraser du code.

Conseil:Utilisez ces commandes avec prudence et comprenez parfaitement les commits que vous manipulez.

--

Liste de contrôle : Lignes directrices pour protéger 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égrer GitHub avec le fournisseur d'identité (IdP) de votre organisation pour centraliser l'authentification.
• Exiger l'authentification à deux facteurs (2FA) : Exigez 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 aux 2FA basées sur les SMS.

Contrôle de l'accès

• Principe du moindre privilège : Accordez aux utilisateurs les autorisations minimales nécessaires pour leur rôle. 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 ex, admin, développeur, testeur) et attribuez des autorisations en conséquence.
• Utilisez GitHub Teams pour gérer les autorisations de groupe.
• Protégez les branches critiques. Activez des règles de protection des branches pour empêcher les poussées et les suppressions forcées et exigez des vérifications d'état et des révisions de code avant de les fusionner.
• 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, le cas échéant.

Sécurisez 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 API, les tokens et les mots de passe en toute sécurité dans GitHub Secrets for Actions et Dependabot.
• Rotation régulière des informations d'identification: Changez les tokens d'accès, les clés SSH et les mots de passe de manière périodique. Veillez à invalider immédiatement les identifiants compromis.

Sauvegarde et récupération

• Sauvegarde automatisée:Programmez des sauvegardes régulières des référentiels, y compris toutes les branches, les balises et les problèmes
• Stockage hors site: Stockez les sauvegardes dans des emplacements sécurisés et géographiquement distincts. Cryptez les données de sauvegarde en transit et au repos.
• Sauvegardes compatibles avec le protocoleWORM: Exploitez les cibles de stockage dans le nuage public et le verrouillage des objets pour conserver une copie sûre en cas d'incident cybernétique.
• Testez les procédures de restauration : Vérifiez périodiquement que les sauvegardes peuvent être restaurées avec succès. Documentez les étapes de restauration et maintenez-les à jour.

Conclusion : Prenez possession de 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.

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 à favoriser une culture de la sensibilisation et de la diligence. En intégrant ces pratiques dans votre flux de 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 longtemps à l'avenir.

Les données de GitHub sont un élément essentiel de l'environnement de travail de votre entreprise.