Working with push protection from the command line

Learn your options for unblocking your push from the command line to GitHub if secret scanning detects a secret in your changes.

Qui peut utiliser cette fonctionnalité ?

Utilisateurs avec accès en écriture

Dans cet article

About push protection from the command line

Push protection prevents you from accidentally committing secrets to a repository by blocking pushes containing supported secrets.

When you attempt to push a supported secret from the command line to a repository secured by push protection, GitHub will block the push.

You should either:

Up to five detected secrets will be displayed at a time on the command line. If a particular secret has already been detected in the repository and an alert already exists, GitHub will not block that secret.

If you confirm a secret is real and that you intend to fix it later, you should aim to remediate the secret as soon as possible. For example, you might revoke the secret and remove the secret from the repository's commit history. Real secrets that have been exposed must be revoked to avoid unauthorized access. You might consider first rotating the secret before revoking it. For more information, see Suppression de données sensibles dans un dépôt.

Remarque

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

Resolving a blocked push

To resolve a blocked push, you must remove the secret from all of the commits it appears in.

Remarque

To learn how to resolved a blocked commit in the GitHub UI, see Working with push protection in the GitHub UI.

Removing a secret introduced by the latest commit on your branch

If the blocked secret was introduced by the latest commit on your branch, you can follow the guidance below.

  1. Remove the secret from your code.
  2. To commit the changes, run git commit --amend --all. This updates the original commit that introduced the secret instead of creating a new commit.
  3. Push your changes with git push.

Removing a secret introduced by an earlier commit on your branch

You can also remove the secret if the secret appears in an earlier commit in the Git history. To do so, you will need to identify which commit first introduced the secret and modify the commit history with an interactive rebase.

  1. Examine the error message that displayed when you tried to push your branch, which lists all of the commits that contain the 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. Next, run git log to see a full history of all the commits on your branch, along with their corresponding timestamps.

    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. Save and close the editor to start the interactive rebase.

  7. Remove the secret from your code.

  8. Add your changes to the staging area using git add ..

    Remarque

    The full command is git add .:

    • There is a space between add and ..
    • The period following the space is part of the command.

  9. Commit your changes using git commit --amend.

  10. Run git rebase --continue to finish the rebase.

  11. Push your changes with git push.

Bypassing push protection

If GitHub blocks a secret that you believe is safe to push, you may be able to bypass the block by specifying a reason for allowing the secret to be pushed.

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 d’envoi (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 référentiel qui ont opté pour les notifications par e-mail.

If you don't see the option to bypass the block, the repository administrator or organization owner has configured tighter controls around push protection. Instead, you should remove the secret from the commit, or submit a request for "bypass privileges" in order to push the blocked secret. For more information, see Requesting bypass privileges.

  1. Accédez à l'URL renvoyée par GitHub quand votre envoi (push) a été bloqué, en tant que même utilisateur qui a effectué l’envoi (push). Si un autre utilisateur tente de visiter cette URL, il reçoit une erreur 404.

  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.

    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 « Push protection for users ».

  3. Click Allow me to push this secret.

  4. Reattempt the push on the command line within three hours. If you have not pushed within three hours, you will need to repeat this process.

Requesting bypass privileges

If your push has been blocked by push protection and you believe the secret is safe to push, you can request permission to bypass the block. Your request is sent to a designated group of reviewers, who will either approve or deny the request.

Requests expire after 7 days.

  1. Accédez à l'URL renvoyée par GitHub quand votre envoi (push) a été bloqué, en tant que même utilisateur qui a effectué l’envoi (push). Si un autre utilisateur tente de visiter cette URL, il reçoit une erreur 404.
  2. 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.
  3. Cliquez sur Envoyer la demande.
  4. 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.

If your request is approved, you can push the commit (or commits) containing the secret to the repository, as well as any future commits that contain the same secret.

If your request is denied, you will need to remove the secret from all commits containing the secret before pushing again. For information on how to remove a blocked secret, see Resolving a blocked push.

Further reading