Introduction
Un fichier peut être utile sur votre machine tout en étant inapproprié pour un commit de code source. Ce nouveau dépôt DeskLite contient une petite modification métier et une configuration privée avec un identifiant fictif. Le fichier privé a été indexé par erreur, mais n'a jamais été commité.
Vous allez découvrir l'espace de travail Git, l'index et l'instantané d'un commit ; séparer les paramètres privés des exemples à livrer ; et utiliser un scanner d'identifiants préparé. Vous n'avez besoin ni de compte Git, ni de dépôt distant, ni de connaissances préalables de Git.
Repérer l'arbre de travail et l'index
Dans cette étape, vous identifierez les fichiers que Git prépare à enregistrer.
Git enregistre des versions sélectionnées de fichiers dans un dépôt. Son arbre de travail contient les fichiers que vous modifiez. L'index, ou zone de préparation, contient le prochain instantané que vous comptez commiter. Un commit enregistre cet instantané indexé dans l'historique local ; il ne téléverse rien automatiquement.
cd /home/labex/project/desklite-git
git status compare ces espaces :
git status
Le terminal préparé peut colorer les catégories de fichiers ; c'est le libellé qui compte. Repérez deux catégories distinctes. private.env apparaît parmi les modifications à commiter : son contenu est déjà indexé. service/app.py apparaît parmi les modifications non indexées pour le commit : sa modification métier se trouve encore uniquement dans l'arbre de travail. Le nom de la branche peut varier et n'affecte pas cette tâche.
git ls-files liste les chemins suivis, y compris les nouveaux fichiers indexés pour leur premier commit :
git ls-files
Le fichier privé apparaît alors qu'il n'a pas encore été commité. C'est le moment d'empêcher la fuite. L'historique initial des commits ne contient aucun secret. Ne créez pas encore de commit : inspectez d'abord ce qui y entrerait.
Comparer les deux types de modifications
Dans cette étape, vous comparerez la modification métier à la configuration privée indexée.
git --no-pager diff affiche les modifications non indexées. L'option globale --no-pager conserve la sortie directement dans le terminal : aucun afficheur séparé n'a besoin d'être fermé. Limitez-la au fichier métier en indiquant son chemin :
git --no-pager diff service/app.py
Les lignes commençant par - montrent l'ancien contenu ; celles commençant par + montrent le nouveau. Le nouveau programme affiche DeskLite tickets ready. Conservez cette modification métier prévue.
git --no-pager diff --cached affiche plutôt le contenu indexé. L'option --cached sélectionne l'index :
git --no-pager diff --cached
Vous devez voir private.env et ses clés SERVICE_NAME et API_TOKEN. Le jeton est fictif et ne fonctionne nulle part en dehors de ce cours. Il représente néanmoins le type de valeur qui doit rester privé.
Un instantané indexé peut différer du fichier actuellement sur disque. Vérifier uniquement l'arbre de travail peut donc laisser passer un élément déjà préparé pour un commit. Avant de commiter, inspectez les deux types de modifications.
Une identité d'auteur locale d'exemple est déjà configurée dans le dépôt. Vous ne fournirez aucune information personnelle et ne connecterez pas Git à un service externe.
Lire une détection d'identifiant à valeur masquée
Dans cette étape, vous exécuterez le scanner préparé sur le fichier privé et interpréterez la détection.
Gitleaks détecte des motifs textuels associés aux identifiants. Le lanceur du cours course-secrets exécute Gitleaks 8.24.2 avec une règle locale fixe pour notre format de jeton synthétique labex_. Il masque les valeurs correspondantes et n'effectue aucune requête réseau. Cette règle limitée du cours ne constitue pas une politique complète de détection des secrets en production.
Indiquez au lanceur un fichier ou un répertoire pour analyser son contenu actuel :
course-secrets private.env
Une détection identifiée par desklite-practice-token, un nom de fichier/numéro de ligne et un secret masqué sont attendus. La commande se termine intentionnellement avec le code 1, car elle a trouvé un identifiant. Une détection est différente d'un outil qui ne parvient pas à s'exécuter.
Cette commande analyse le fichier actuel, qu'il soit suivi par Git ou non. Une analyse de l'historique, présentée plus tard, inspecte les modifications commitées. Un historique sans secret ne rendrait pas ce fichier non commité sûr à indexer.
La valeur privée ne se trouve ici que dans le contenu indexé/de travail. Si un véritable identifiant avait déjà été exposé, le retirer d'un nouveau commit ne l'invaliderait pas et n'effacerait pas les anciennes copies : son propriétaire devrait le révoquer ou le remplacer. Cet exercice n'enseigne pas la réécriture de l'historique.
Séparer les paramètres privés de l'exemple
Dans cette étape, vous retirerez les paramètres privés du suivi Git, ajouterez une règle d'exclusion ciblée et créerez un exemple public utilisable.
git rm --cached retire un chemin de l'index et du suivi tout en préservant le fichier local. Ici, il annule l'indexation accidentelle d'un nouveau fichier privé :
git rm --cached private.env
Ouvrez .gitignore, qui indique à Git quels chemins non suivis laisser de côté :
nano .gitignore
Saisissez cette seule règle, puis enregistrez avec Ctrl+O, Enter, Ctrl+X :
/private.env
Le / initial ancre la règle à la racine de ce dépôt. N'ignorez pas service/ : il contient des fichiers à livrer. Les règles d'exclusion ne suppriment pas automatiquement les fichiers déjà suivis ni les anciens commits ; c'est pourquoi la commande précédente était nécessaire.
Créez un exemple public utilisant les mêmes clés de configuration :
nano service/config.example.env
Enregistrez :
SERVICE_NAME=DeskLite
API_TOKEN=REPLACE_ME
L'exemple indique à un futur opérateur les paramètres nécessaires sans fournir d'identifiant fonctionnel. Conservez le fichier privé d'origine localement.
ls private.env
git status
Le chemin privé ne doit plus être indexé ni répertorié comme non suivi. .gitignore et l'exemple public doivent être non suivis et prêts pour une indexation volontaire. La modification métier existante reste non indexée.
Indexer uniquement les fichiers à livrer
Dans cette étape, vous préparerez les fichiers exacts prévus pour le prochain commit.
git add copie le contenu actuel des chemins nommés dans l'index. Nommez explicitement chaque fichier prévu pour la livraison :
git add service/app.py service/config.example.env .gitignore
Examinez les catégories de fichiers et le contenu indexé :
git status
git --no-pager diff --cached
Vous devez trouver exactement la modification métier prévue, la règle d'exclusion ciblée et l'exemple sûr. Aucun jeton privé ne doit s'y trouver. Si vous modifiez à nouveau un fichier après git add, vous devez indexer le contenu mis à jour avant de commiter ; Git ne remplace pas automatiquement un instantané précédemment indexé.
Listez à nouveau les chemins suivis :
git ls-files
Les trois chemins à livrer doivent apparaître ; private.env ne doit pas apparaître. Cette vérification répond à une question différente de ls : le fichier privé local existe toujours, mais il est hors du suivi Git.
L'étape suivante analyse le répertoire à livrer. Analyser un périmètre de livraison volontairement limité ne permet pas d'affirmer que tous les fichiers ailleurs sur la machine sont exempts de secrets.
Analyser le contenu à livrer
Dans cette étape, vous vérifierez le répertoire source qui sera livré tout en préservant les paramètres locaux privés.
Exécutez le même scanner à règles fixes sur le répertoire service :
course-secrets service
Le message attendu est no leaks found, avec un code de sortie de réussite. Le scanner traite le contenu réel du code source et de l'exemple. Il ne s'appuie pas sur un rapport modifié manuellement.
La configuration privée se trouve à la racine du dépôt, hors de ce répertoire à livrer. Analyser à nouveau ce fichier privé signalerait toujours son jeton ; c'est attendu. Nous avons séparé les publics sans prétendre que les données sensibles ont cessé d'exister.
Inspectez une nouvelle fois l'instantané indexé :
git --no-pager diff --cached
L'analyse du répertoire vérifie les fichiers actuels ; le diff vérifie ce que Git enregistrera. Les deux doivent correspondre au contenu de livraison prévu. Une analyse sans détection ne renseigne que sur la règle et le périmètre configurés ; elle ne peut pas établir l'absence de tous les secrets possibles ou de toutes les failles de sécurité.
Vous disposez maintenant d'un instantané indexé et examiné. L'étape suivante l'enregistre comme commit local.
Enregistrer un commit local
Dans cette étape, vous enregistrerez l'instantané indexé et examiné dans l'historique local.
git commit enregistre l'index. L'option -m fournit un court message décrivant la modification ; les guillemets maintiennent ses mots ensemble :
git commit -m "Deliver ticket message and safe configuration example"
Un résumé de commit indiquant les trois chemins modifiés est attendu. Les identifiants de commit et les statistiques de fichiers peuvent varier : concentrez-vous sur ce qui a été inclus.
git status
L'arbre de travail doit être propre. Le fichier privé ignoré existe toujours, même si git status ne le liste pas.
Un commit est local. Rien n'a été poussé, téléversé ou partagé avec un service distant. Cela suffit pour s'entraîner à préparer une transmission sûre sans compte personnel.
Si Git indique qu'il n'y a rien à commiter, comparez git status, git ls-files et les différences indexées aux étapes précédentes. Ne résolvez pas un état inattendu en supprimant le dépôt ou son historique existant.
Vérifier l'historique et la modification métier
Dans cette étape, vous analyserez l'historique des commits et exécuterez le petit programme que vous avez conservé.
L'option --history du lanceur sélectionne l'analyse de l'historique Git par Gitleaks. Le . final désigne ce dépôt :
course-secrets --history .
Le message attendu est no leaks found. Le commit initial sans secret et votre nouveau commit de livraison doivent tous deux passer la règle fixe. La réussite de l'analyse de fichiers précédente ne suffirait pas, à elle seule, à prouver ce résultat pour l'historique.
python3 exécute le programme Python fourni. Vous n'avez pas besoin de modifier ou de comprendre la syntaxe Python dans ce lab :
python3 service/app.py
Résultat attendu :
DeskLite tickets ready
Confirmez que le fichier privé local reste hors du suivi Git :
ls private.env
git ls-files
Vous disposez maintenant de fichiers de livraison utiles, d'un exemple de configuration sûr et d'un commit local sans l'identifiant d'exercice. Le fichier privé n'a pas été supprimé et la modification métier fonctionne toujours. Aucun rapport d'analyse copié ni fichier d'investigation n'est requis.
Résumé
Vous avez séparé les paramètres locaux privés du code à livrer, examiné l'index avant de créer un commit et vérifié les fichiers à livrer ainsi que l'historique Git local avec une analyse fixe des identifiants dont les valeurs sont masquées. La modification métier et l'exemple public utile sont conservés, tandis que les paramètres privés restent hors du commit.
