À 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 ».
Remarques:
- 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.
- In the example, commit
-
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
.
- For
-
In the editor, choose to edit the commit identified in step 3 by changing
pick
toedit
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.
-
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.