Utilisation de la protection Push

À propos de l’utilisation de la protection Push

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.

Vous pouvez utiliser la protection push à partir de la ligne de commande ou de l’interface utilisateur web.

Pour plus d’informations sur l’utilisation de la protection Push, notamment sur la façon de contourner le bloc si nécessaire, consultez « Utilisation de la protection push à partir de la ligne de commande » et « Utilisation de la protection push à partir de l’interface utilisateur web » dans cet article.

Utiliser la protection push à partir de 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).

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, vous devez supprimer le secret de votre branche, de toutes les validations dans lesquelles il apparaît, avant d’envoyer (push) à nouveau. Pour plus d’informations sur la correction des secrets bloqués, consultez « Envoi d’une branche bloquée par la protection par émission de données ».

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

Dans certains cas, vous devrez peut-être contourner le blocage d'un secret. Pour plus d’informations sur la façon de contourner la protection push et d’envoyer (push) un secret bloqué, consultez « Contournement de la protection push lors de l’utilisation de la ligne de commande ».

Contournement de la protection push lors de l’utilisation de la ligne de commande

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.

1. Visitez l’URL qu’a retournée GitHub quand votre poussée a été bloquée.

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.

3. Cliquez sur M’autoriser à pousser ce secret.

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

Utiliser la protection push à partir de l'interface 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 un commit bloqué, vous pouvez supprimer le secret du fichier à l’aide de l’interface utilisateur web. Une fois que vous avez supprimé le secret, vous pourrez valider vos modifications.

GitHub n’affiche qu’un secret détecté à la fois dans l’interface utilisateur web. 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.

Les propriétaires d’organisation peuvent fournir un lien personnalisé qui s’affiche lorsqu’une poussée est bloquée. Ce lien personnalisé peut contenir des ressources et des conseils spécifiques à votre organisation. Par exemple, le lien personnalisé peut pointer vers un fichier README avec des informations sur le coffre de secrets de l’organisation, les équipes et les individus auxquels remonter les questions, ou la stratégie approuvée de l’organisation pour travailler avec des secrets et réécrire l’historique des commits.

Vous pouvez contourner le blocage en spécifiant une raison d’autoriser le secret. Pour plus d’informations sur la façon de contourner la protection push et de valider le secret bloqué, consultez « Contournement de la protection push lors de l’utilisation de l’interface utilisateur web ».

Contournement de la protection push lors de l’utilisation de l’interface utilisateur web

Si vous confirmez qu’un secret est réel, vous devez supprimer le secret de votre branche, de toutes les validations dans lesquelles il apparaît, avant d’envoyer (push) à nouveau. Pour plus d’informations sur la correction des secrets bloqués, consultez « Envoi d’une branche bloquée par la protection par émission de données ».

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. Pour plus d’informations, consultez « Suppression de données sensibles dans un dépôt ».

Si GitHub bloque un secret que vous pensez pouvoir livrer en toute sécurité, vous pouvez contourner le blocage en spécifiant une raison d'autoriser le 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.

1. Dans la boîte de dialogue qui s’est affichée lorsque GitHub a bloqué votre validation, consultez le nom et l’emplacement du secret.

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.

3. Cliquez sur Autoriser le secret.

Pour aller plus loin

• « Envoi d’une branche bloquée par la protection par émission de données »
• « Protection des poussées pour les référentiels et les organisations »