Éviter l’ajout de secrets à l’historique

Un identifiant placé dans un fichier du site ou dans une configuration locale peut être enregistré dans Git et partagé avec toute l’équipe. Même si vous supprimez ensuite la ligne, le secret peut rester accessible dans l’historique.

Vous allez réduire ce risque en ignorant les fichiers locaux appropriés et en inspectant les changements avant de les valider. Si un secret a été exposé, la priorité est de le révoquer ou de le remplacer auprès du service qui l’a émis, puis de vérifier les conséquences de l’exposition.

Ignorer les fichiers locaux sensibles

Dans le projet du site, les fichiers de configuration propres à un poste ou contenant des valeurs privées ne doivent pas être versionnés. Le fichier .gitignore permet d’exclure ces fichiers lorsqu’ils ne sont pas encore suivis par Git. Il est déjà prévu parmi les fichiers du dépôt : ajoutez-y uniquement les motifs adaptés aux fichiers réellement utilisés par l’équipe.

# .gitignore
.env
.env.*
!.env.example

Ici, Git ignore le fichier local .env et les variantes telles que .env.developpement, tout en laissant la possibilité de versionner un modèle sans valeur secrète, .env.example. N’ajoutez pas de valeur réelle dans ce modèle : documentez seulement les noms des paramètres attendus. Adaptez ces motifs si votre équipe utilise d’autres noms de fichiers sensibles.

Inspecter les changements avant validation

Avant de créer un commit, vérifiez quels fichiers sont modifiés, puis examinez leur contenu. Une règle d’exclusion est utile, mais elle ne remplace pas cette inspection : un secret peut être ajouté dans un fichier suivi du dépôt, par exemple un document HTML ou le fichier README.md.

git status --short
git diff --check
git diff -- . ':!.gitignore'
git diff --cached --check
git diff --cached -- . ':!.gitignore'
git check-ignore -v .env

git status affiche les fichiers modifiés. git diff et git diff --cached affichent respectivement les changements non indexés et indexés. git check-ignore indique quelle règle ignore .env ; si le fichier existe et correspond à la règle, sa sortie précise le fichier .gitignore et le motif appliqué.

Inspectez les deux différences : un changement peut être indexé pour le commit tandis qu’un autre ne l’est pas. Cherchez toute valeur qui ressemble à un mot de passe, une clé privée ou un jeton d’accès, et confirmez auprès de la personne responsable qu’elle est destinée à être partagée. Pour repérer dans le contenu suivi des noms de fichiers souvent sensibles, vous pouvez aussi lancer la recherche suivante ; elle ne remplace pas l’examen humain ni un outil de détection spécialisé.

git grep -n -I -E 'PRIVATE KEY|api[_-]?key|password|token' -- . ':!.gitignore'

La commande affiche les lignes correspondantes dans les fichiers suivis de la révision courante. L’absence de résultat signifie seulement qu’aucun des termes recherchés n’a été trouvé ; elle ne prouve pas que le dépôt est exempt de secrets.

Traiter un secret exposé

Si vous découvrez un secret dans un changement qui n’a pas encore été partagé, ne créez pas le commit : retirez la valeur, placez-la dans le mécanisme local approprié, puis inspectez à nouveau les changements indexés et non indexés. Si le secret a été commité, poussé ou transmis à un service d’intégration continue, partez du principe qu’il est compromis, même si vous avez ensuite supprimé la ligne du fichier.

1. Avertissez la personne responsable du service concerné, en suivant les règles de signalement de l’équipe.
2. Révoquez l’identifiant exposé ou désactivez-le, puis émettez un remplacement par le canal sécurisé prévu par le service.
3. Mettez à jour les systèmes autorisés qui en ont besoin sans inscrire la nouvelle valeur dans Git, un ticket public ou les journaux du pipeline.
4. Vérifiez les journaux d’utilisation disponibles afin de repérer d’éventuels accès inhabituels et consignez l’incident sans recopier la valeur secrète.
5. Retirez la valeur des fichiers courants et contrôlez les changements. Si sa présence dans l’historique doit être traitée, coordonnez une intervention dédiée avec l’équipe : une réécriture peut affecter les autres clones et ne rend pas un secret déjà divulgué à nouveau sûr.

La suppression d’un secret de l’historique n’est donc pas un substitut à sa révocation ou à son remplacement. Suivez la procédure de votre service d’hébergement et coordonnez toute réécriture d’historique avant de l’entreprendre ; les copies, caches ou journaux peuvent conserver des traces indépendamment de la branche courante.

À retenir

• Ignorez les fichiers locaux sensibles dans .gitignore et ne versionnez que des modèles dépourvus de valeurs privées.
• Examinez les changements indexés et non indexés avant chaque commit ; les recherches automatisées ne garantissent pas l’absence de secret.
• .gitignore n’efface ni un fichier déjà suivi ni les secrets présents dans l’historique.
• Après toute exposition, révoquez ou remplacez le secret auprès du service émetteur, puis vérifiez les usages et coordonnez la suite avec l’équipe.

La prochaine leçon portera sur les protections de branche qui empêchent la fusion lorsque les contrôles requis ne sont pas satisfaits.