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 voir quelles options sont disponibles pour vous pour autoriser l’envoi (push). Pour plus d’informations, consultez « Contournement de la protection Push » et « Demande de privilèges de contournement ».

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 ».

Note

Si votre configuration Git prend en charge les envois vers plusieurs branches, et non uniquement vers la branche par défaut, votre envoi peut être bloqué en raison de l’envoi (push) de références supplémentaires et involontaires. Pour plus d’informations, consultez les options push.default dans la documentation Git.
Si l’secret scanning à l’occasion de l’expiration d’un envoi (push), GitHub exécute toujours une analyse après l’envoi (push).

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 ».

Note

Pour savoir comment résoudre une validation bloquée dans l’interface utilisateur GitHub, consultez « Utilisation de la protection push dans l’interface utilisateur GitHub ».

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.

Supprimez le secret de votre code.
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.
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.

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

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

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.
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.

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

Enregistrez et fermez l’éditeur pour lancer le rebasement interactif.
Supprimez le secret de votre code.
Validez vos changements en utilisant git commit --amend.
Exécutez git rebase --continue pour terminer la relocalisation.
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.

Visitez l’URL qu’a retournée GitHub quand votre poussée a été bloquée.
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.
Remarque : 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 ».
Cliquez sur M’autoriser à pousser ce secret.
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.

Demande de privilèges de contournement

Si votre envoi (push) a été bloqué par la protection push et que vous pensez que le secret peut être envoyé en toute sécurité, vous pouvez demander l'autorisation de contourner le blocage. Votre demande est envoyée à un groupe désigné d’examinateurs, qui approuvera ou refusera la demande.

Les demandes expirent après 7 jours.

Visitez l’URL qu’a retournée GitHub quand votre poussée a été bloquée.
Sous « Ou demander des privilèges de contournement », ajoutez un commentaire. Par exemple, vous pouvez expliquer pourquoi vous pensez que le secret peut être transmis en toute sécurité, ou fournir le contexte de la demande de contournement du blocage.
Cliquez sur Envoyer la demande.
Vérifiez vos notifications par e-mail pour obtenir une réponse à votre demande.

Une fois votre demande examinée, vous recevrez un e-mail vous informant de la décision.

Si votre demande est approuvée, vous pouvez envoyer (push) la validation (ou les validations) contenant le secret au référentiel, ainsi que les validations futures qui contiennent le même secret.

Si votre demande est refusée, vous devez supprimer le secret de toutes les validations contenant le secret avant d’envoyer (push) à nouveau. Pour plus d'informations sur la manière de supprimer un secret bloqué, consultez « Résolution d’un envoi (push) bloqué ».