À propos de la protection push

La protection push permet d’éviter les fuites de sécurité en analysant les secrets avant que vous n’apportiez des modifications à votre référentiel.

Lorsque vous essayez d’envoyer un secret vers un dépôt sécurisé par la protection push, GitHub bloque l’envoi. Vous devez supprimer le secret de votre branche avant de l’envoyer à nouveau. Pour plus d’informations sur la résolution d’un envoi (push) bloqué, consultez « Résolution d’un envoi (push) bloqué sur la ligne de commande » et « Résolution d’une validation bloquée dans l’interface utilisateur Web » dans cet article.

Si vous estimez qu’il n’y a pas de danger à autoriser le secret, vous avez la possibilité de contourner la protection. Pour plus d’informations, consultez « Autorisation de la poussée d’un secret bloqué » et « Contournement de la protection des poussées pour un secret ».

Pour plus d’informations sur les secrets et fournisseurs de services pris en charge pour la protection par émission de données, consultez « Modèles d'analyse des secrets ».

Résolution d’un envoi (push) bloqué sur la ligne de commande

Lorsque vous tentez d’envoyer un secret pris en charge vers un référentiel sécurisé par la protection push, GitHub bloque l’envoi. Vous pouvez supprimer le secret de votre branche ou suivre une URL fournie pour autoriser l’envoi (push).

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. 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. Validez vos changements en utilisant git commit --amend.

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

10. Envoyer vos modifications avec git push.

Résolution d’une validation bloquée dans l’interface utilisateur web

Lorsque vous utilisez l’interface Web pour tenter de valider un secret pris en charge dans un référentiel sécurisé par la protection push, GitHub bloque la validation.

Vous verrez une boîte de dialogue avec des informations sur l’emplacement du secret, ainsi que des options vous permettant d’envoyer (push) le secret. Le secret sera également souligné dans le fichier afin que vous puissiez le trouver facilement.

Pour résoudre une validation bloquée dans l’interface utilisateur Web, vous devez supprimer le secret du fichier. Une fois que vous avez supprimé le secret, vous pourrez valider vos modifications.

Sinon, si vous déterminez qu’il est sûr d’autoriser le secret, utilisez les options affichées dans la boîte de dialogue pour contourner la protection push. Pour plus d’informations sur le contournement de la protection par émission de données à partir de l’interface utilisateur web, consultez « Protection des poussées pour les référentiels et les organisations ».

Pour aller plus loin

• « Protection des poussées pour les référentiels et les organisations »