Skip to main content

Cette version de GitHub Enterprise Server ne sera plus disponible le 2024-06-29. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Envoi d’une branche bloquée par la protection par émission de données

La protection push vous protège de manière proactive contre les fuites de secrets dans vos dépôts. Vous pouvez résoudre les envois bloqués et, une fois le secret détecté supprimé, vous pouvez envoyer (push) les modifications à votre branche de travail à partir de la ligne de commande ou de l’interface utilisateur web.

Qui peut utiliser cette fonctionnalité ?

La protection push est disponible pour les référentiels appartenant à l’organisation dans GitHub Enterprise Server si votre entreprise possède une licence pour GitHub Advanced Security.

Pour plus d’informations, consultez « Protection des poussées pour les référentiels et les organisations ».

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

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

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