Travailler avec la protection push à partir de la ligne de commande

À propos de la protection push à partir de la ligne de commande

La protection Push vous empêche de valider accidentellement des secrets dans un référentiel en bloquant les envois de données contenant des secrets pris en charge.

Lorsque vous tentez d’envoyer un secret pris en charge depuis la ligne de commande vers un référentiel sécurisé par la protection push, GitHub bloque l’envoi.

Vous devez :

• Supprimez le secret de votre branche. Pour plus d’informations, consultez « Résolution d’un envoi (push) bloqué ».
• Suivre une URL fournie pour autoriser l’envoi (push). Pour plus d’informations, consultez « Contournement de la protection Push ».

Jusqu’à cinq secrets détectés s’affichent à la fois sur la ligne de commande. Si un secret particulier a déjà été détecté dans le dépôt et qu’une alerte existe déjà, GitHub ne bloque pas ce secret.

Si vous confirmez qu’un secret est réel et que vous avez l’intention de le corriger ultérieurement, vous devez veiller à effectuer la correction dès que possible. Par exemple, vous pouvez révoquer le secret et le supprimer de l’historique des commits du dépôt. Les secrets réels exposés doivent être révoqués pour éviter tout accès non autorisé. Vous pouvez commencer par faire pivoter le secret avant de le révoquer. Pour plus d’informations, consultez « Suppression de données sensibles dans un dépôt ».

Résolution d’un push bloqué

Pour résoudre un push bloqué, vous devez supprimer le secret de tous les commits dans lesquels il apparaît.

• Si le secret a été introduit par votre dernier commit, consultez « Suppression d’un secret introduit par le dernier commit sur votre branche ».
• Si le secret apparaît dans les commits précédents, consultez « Suppression d’un secret introduit par un commit antérieur sur votre branche ».

Suppression d’un secret introduit par la dernière validation sur votre branche

Si le secret bloqué a été introduit par la dernière validation sur votre branche, vous pouvez suivre l’aide apportée ci-dessous.

1. Supprimez le secret de votre code.
2. Pour valider les modifications, exécutez git commit --amend --all. Cela met à jour la validation d’origine qui a introduit le secret au lieu de créer une validation.
3. Envoyer vos modifications avec git push.

Suppression d’un secret introduit par une validation antérieure sur votre branche

Vous pouvez également supprimer le secret s’il apparaît dans une validation antérieure dans l’historique Git. Pour ce faire, vous devrez identifier la première validation qui a introduit le secret et modifier l’historique des validations à l’aide d’un rebasement interactif.

1. Examinez le message d’erreur qui s’affiche lorsque vous avez essayé d’envoyer (push) votre branche, qui répertorie toutes les validations qui contiennent le secret.

   remote:   —— GitHub Personal Access Token ——————————————————————
   remote:    locations:
   remote:      - commit: 8728dbe67
   remote:        path: README.md:4
   remote:      - commit: 03d69e5d3
   remote:        path: README.md:4
   remote:      - commit: 8053f7b27
   remote:        path: README.md:4
   

2. Ensuite, exécutez git log pour afficher un historique complet de toutes les validations sur votre branche, ainsi que leurs horodatages correspondants.

   test-repo (test-branch)]$ git log
   commit 8053f7b27 (HEAD -> main)
   Author: Octocat <1000+octocat@users.noreply.github.com
   Date:   Tue Jan 30 13:03:37 2024 +0100
   
     my fourth commit message
   
   commit 03d69e5d3
   Author: Octocat <1000+octocat@users.noreply.github.com>
   Date:   Tue Jan 30 13:02:59 2024 +0100
   
     my third commit message
   
   commit 8728dbe67
   Author: Octocat <1000+octocat@users.noreply.github.com
   Date:   Tue Jan 30 13:01:36 2024 +0100
   
     my second commit message
   
   commit 6057cbe51
   Author: Octocat <1000+octocat@users.noreply.github.com
   Date:   Tue Jan 30 12:58:24 2024 +0100
   
     my first commit message
   
   

3. Focusing only on the commits that contain the secret, use the output of git log to identify which commit comes earliest in your Git history.

   • In the example, commit 8728dbe67 was the first commit to contain the secret.

4. Start an interactive rebase with git rebase -i <COMMIT-ID>~1.

   • For <COMMIT-ID>, use the commit identified in step 3. For example, git rebase -i 8728dbe67~1.

5. In the editor, choose to edit the commit identified in step 3 by changing pick to edit on the first line of the text.

   edit 8728dbe67 my second commit message
   pick 03d69e5d3 my third commit message
   pick 8053f7b27 my fourth commit message
   

6. Enregistrez et fermez l’éditeur pour lancer le rebasement interactif.

7. Supprimez le secret de votre code.

8. Ajoutez vos modifications à la zone intermédiaire à l’aide de git add ..

   Note

   La commande complète est git add . :

   • Il y a un espace entre add et ..
   • La période qui suit l’espace fait partie de la commande.

9. Validez vos changements en utilisant git commit --amend.

10. Exécutez git rebase --continue pour terminer la relocalisation.

11. Envoyer vos modifications avec git push.

Contournement de la protection Push

Si GitHub bloque un secret que vous pensez pouvoir envoyer (push), vous pourrez contourner le blocage en spécifiant une raison pour autoriser l'envoi (push) du secret.

Lorsque vous autorisez un secret à être poussé, une alerte est créée sous l’onglet Sécurité. GitHub ferme l’alerte et n’envoie pas de notification si vous spécifiez que le secret est un faux positif ou qu’il est utilisé uniquement dans les tests. Si vous spécifiez que le secret est bien réel et que vous le corrigerez plus tard, GitHub garde l’alerte de sécurité ouverte et envoie des notifications à l’auteur du commit, ainsi qu’aux administrateurs du dépôt. Pour plus d’informations, consultez « Gestion des alertes à partir de l’analyse des secrets ».

Quand un contributeur contourne un bloc de protection push pour un secret, GitHub envoie également une alerte par e-mail aux propriétaires de l’organisation, responsables de la sécurité et administrateurs de dépôt qui ont opté pour les notifications par e-mail.

Si vous ne voyez pas l’option permettant de contourner le bloc, l’administrateur du référentiel ou propriétaire d'organisation a configuré des contrôles plus stricts autour de la protection push. Au lieu de cela, vous devez supprimer le secret de la validation ou envoyer une demande de « contournement des privilèges » afin d’envoyer (push) le secret bloqué. Pour plus d'informations, consultez « Demande de privilèges de contournement » dans la documentation GitHub Enterprise Cloud.

1. Visitez l’URL qu’a retournée GitHub quand votre poussée a été bloquée.

2. Choisissez l’option qui décrit le mieux la raison pour laquelle vous devez être en mesure de pousser le secret.

   • Si le secret est utilisé uniquement dans des tests et ne représente aucune menace, cliquez sur Il est utilisé dans des tests.

   • Si la chaîne détectée n’est pas un secret, cliquez sur Il s’agit d’un faux positif.

   • Si le secret est réel, mais que vous avez l’intention de le corriger plus tard, cliquez sur Je le corrigerai plus tard.

   Note

   Vous devez spécifier une raison de contourner la protection push si l’analyse des secrets est activée dans le référentiel.

   Lors d’une poussée vers un dépôt public pour lequel l’analyse des secrets n’est pas activée, vous êtes toujours protégé contre l’envoi (push) accidentel de secrets grâce à la protection push pour les utilisateurs, qui est activée par défaut pour votre compte d’utilisateur.

   Avec la protection push pour les utilisateurs, GitHub bloque automatiquement les envois (push) vers les dépôts publics si ces envois contiennent des secrets pris en charge, mais vous n’avez pas besoin de spécifier une raison d’autoriser le secret, et GitHub ne génère pas d’alerte. Pour plus d’informations, consultez « Protection par émission de données pour les utilisateurs ».

3. Cliquez sur M’autoriser à pousser ce secret.

4. Retentez la poussée sur la ligne de commande dans un délai de trois heures. Si vous n’effectuez pas la poussée dans les trois heures, vous devrez répéter ce processus.

Pour aller plus loin

• Utilisation de la protection push dans l’interface utilisateur GitHub
• Travailler avec la protection push à partir de l’API REST