Sécuriser vos dépôts Git : bonnes pratiques et sources non fiables

Sécuriser vos dépôts Git ne se limite pas à garder le code privé. Un dépôt peut contenir des secrets, des hooks exécutables, des risques liés à la chaîne d'approvisionnement, un historique sensible et une configuration qui affecte chaque développeur qui le clone.

De bonnes pratiques de sécurité Git vous aident à éviter les fuites d'identifiants, une automatisation dangereuse et une confiance accidentelle dans du code provenant de sources inconnues. Les bases sont simples, mais elles doivent être appliquées de manière cohérente.

Protéger les secrets avant qu'ils n'atteignent Git

Le secret le plus sûr est celui qui n'entre jamais dans le dépôt. Les clés API, les clés privées SSH, les identifiants cloud, les mots de passe de base de données, les jetons et les fichiers .env doivent rester en dehors de Git.

Ajoutez les fichiers secrets locaux à .gitignore :

.env
.env.*
*.pem
id_rsa
id_ed25519

Soyez prudent avec .env.example. Ce fichier est souvent utile, mais il doit contenir des valeurs factices de remplacement :

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=replace-me

Ne collez pas de valeurs réelles "juste pour tester". L'historique Git se souvient des anciennes versions même après avoir supprimé une ligne dans un commit ultérieur.

Si vous commettez accidentellement un secret, traitez-le comme exposé. Supprimez-le de l'arborescence actuelle, faites pivoter l'identifiant dans le service qui l'a émis, puis décidez si un nettoyage de l'historique est nécessaire. Réécrire l'historique peut aider à réduire l'exposition future, mais ne garantit pas que le secret n'a jamais été copié.

Les équipes devraient également utiliser l'analyse des secrets. De nombreuses plateformes Git hébergées offrent une analyse des modèles de jetons courants. Les outils de pré-commit locaux peuvent détecter les erreurs plus tôt, avant qu'un push n'atteigne le serveur.

Pour les modèles opérationnels connexes, consultez maîtriser les variables d'environnement pour la configuration et les secrets.

Verrouiller l'accès et les modifications de branches

La sécurité du dépôt commence par le contrôle d'accès. Donnez aux personnes le moins d'accès possible. Quelqu'un qui ne fait que réviser du code n'a probablement pas besoin de droits d'administration. Un compte de service CI n'a probablement pas besoin d'autorisation pour réécrire des branches.

Examinez régulièrement ces paramètres :

Administrateurs et propriétaires du dépôt.
Collaborateurs avec accès en écriture.
Clés de déploiement et utilisateurs machines.
Jetons d'accès personnels utilisés par l'automatisation.
Webhooks qui reçoivent des événements du dépôt.
Règles de protection des branches.

Les branches protégées sont l'un des contrôles les plus utiles. Pour les branches importantes comme main, exigez des pull requests, des vérifications de statut et une révision avant la fusion. Désactivez les pushs forcés à moins que votre équipe n'ait une raison très spécifique de les autoriser.

Les commits signés ou les tags signés peuvent également aider dans les environnements à plus haute confiance. Ils ne rendent pas le code sûr par eux-mêmes, mais ils peuvent prouver qu'un commit ou un tag de version a été créé par une clé que votre équipe reconnaît.

Utilisez les tags avec précaution pour les versions. Si un processus de déploiement fait confiance aux tags, restreignez qui peut les créer ou les déplacer. Un tag de version déplacé peut confondre les audits et les déploiements.

Soyez prudent avec les dépôts non fiables

Cloner du code depuis une source non fiable est courant. L'exécuter immédiatement est la partie risquée. Un dépôt Git peut inclure des scripts de construction, des scripts de cycle de vie de paquets, des Makefiles, des conteneurs, une configuration CI et des instructions qui exécutent du code sur votre machine.

Avant d'exécuter quoi que ce soit, inspectez le dépôt :

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

Ensuite, vérifiez les fichiers à haut risque :

Scripts shell tels que install.sh ou bootstrap.sh.
Scripts de paquets dans package.json.
Fichiers CI sous .github/workflows/, .gitlab-ci.yml ou chemins similaires.
Dockerfiles et fichiers compose.
Makefiles.
Manifestes de dépendances spécifiques au langage.

N'exécutez pas de commandes curl | bash à partir d'un README aléatoire. Si un projet nécessite un installateur, téléchargez-le, lisez-le et exécutez-le dans un environnement jetable si possible.

Les hooks Git méritent une mention spéciale. Les hooks dans .git/hooks/ ne sont normalement pas transférés en tant que hooks actifs lorsque vous clonez un dépôt. C'est bien. Mais un dépôt peut inclure des scripts qui installent des hooks pour vous. Lisez ces scripts avant de les exécuter car les hooks peuvent s'exécuter lors des commits, des fusions, des rebases et des pushs.

Pour le code inconnu, utilisez l'isolation. Une machine virtuelle temporaire, un conteneur ou un environnement de développement verrouillé réduit le rayon d'explosion si un script se comporte mal. Ne montez pas vos clés SSH, vos identifiants cloud ou votre kubeconfig de production dans un environnement utilisé pour du code non fiable.

Garder l'historique et les fichiers du dépôt propres

La sécurité est plus facile lorsque le dépôt est ordonné. Les gros fichiers binaires, les archives générées, les secrets vendus et les anciens dumps de configuration rendent la révision plus difficile et augmentent les risques.

Utilisez .gitignore pour les fichiers locaux et .gitattributes pour les règles de gestion des fichiers. Par exemple :

*.sh text eol=lf
*.png binary
*.jpg binary

Si votre projet a besoin de gros fichiers, demandez-vous si Git Large File Storage est approprié. Git standard n'est pas idéal pour les artefacts de construction volumineux ou les fichiers multimédias. Les stocker directement peut ralentir les clones et rendre le nettoyage des fichiers sensibles plus difficile.

Examinez les pull requests pour les modifications sensibles à la sécurité, pas seulement la logique applicative. Surveillez :

Nouveaux identifiants ou jetons.
Nouveaux appels réseau dans les scripts.
Changements de source de dépendances.
Nouvelles autorisations CI.
Modifications des scripts de déploiement.
Changements larges de .gitignore qui cachent des fichiers importants.

Faites également attention aux sous-modules. Ils pointent vers des dépôts externes et des commits spécifiques. Si votre projet les utilise, examinez attentivement les URL des sous-modules et les mises à jour.

Quand faire appel à un professionnel

Faites appel à un ingénieur en sécurité, un responsable DevOps ou un responsable de la gestion des incidents si un secret a été poussé vers un dépôt public, une branche protégée a été poussée de force de manière inattendue, ou un contributeur inconnu a modifié l'automatisation CI ou de déploiement.

Vous devriez également demander de l'aide si vous soupçonnez que l'historique du dépôt a été falsifié. Préserver les preuves peut être plus important que de nettoyer rapidement, surtout dans un environnement d'entreprise.

Sécuriser les dépôts Git se résume à une confiance disciplinée. Gardez les secrets à l'écart, limitez l'accès, protégez les branches importantes et inspectez le code non fiable avant de l'exécuter. Ces habitudes évitent la plupart des problèmes de sécurité des dépôts avant qu'ils ne deviennent des incidents.