Examiner la protection d’envois (push) GitHub

  • 7 minutes

Alors que l’analyse de secrets détecte les informations d’identification déjà présentes dans votre dépôt, la protection d’envois (push) empêche en premier lieu les secrets d’y entrer. Cette approche proactive arrête les vulnérabilités de sécurité avant qu’elles ne deviennent des incidents nécessitant une correction.

Qu’est-ce que la protection des envois (push) ?

La protection Push GitHub est une fonctionnalité de sécurité préventive qui empêche les validations contenant les secrets détectés d’être envoyées à un référentiel. Lorsque vous tentez d’envoyer du code contenant un secret à haut niveau de confiance, GitHub arrête l’opération push et affiche un message d’erreur identifiant les informations d’identification détectées.

Considérez la protection push comme une porte de sécurité entre votre environnement local et le référentiel distant. Il inspecte chaque validation avant de l’autoriser, bloquant les validations contenant des secrets et vous obligeant à corriger le problème localement avant de continuer.

Fonctionnement de la protection d’envois (push)

La protection Push s’intègre en toute transparence au flux de travail Git standard tout en fournissant une détection robuste des informations d’identification.

Processus de la protection d’envois (push)

Lorsque vous envoyez (push) des validations vers un référentiel avec la protection Push activée :

  1. Initiation push : vous exécutez git push pour charger des validations sur GitHub.

  2. Analyse préalable avant réception : GitHub analyse tous les commits dans le push pour détecter les modèles de secrets.

  3. Détection : un modèle secret à haut niveau de confiance est identifié.

  4. Rejet push : l’envoi est rejeté avec un message d’erreur montrant :

    • Type de secret (par exemple, « Clé API Stripe »).
    • Chemin du fichier et numéro de ligne.
    • Options de correction ou de contournement.

Le rejet d’envois (push) se produit avant l’ajout de tout commit au dépôt distant, veillant à ce que le secret n’entre jamais dans l’historique du dépôt.

Exemple de réponse de protection par Push

Lorsque la protection push détecte un secret, vous voyez une sortie similaire à :

$ git push origin main
remote: 
remote: —————— GitHub Push Protection ——————
remote: 
remote: Secret found in the following locations:
remote: 
remote:   • src/PaymentProcessor.cs:15
remote:     - Secret type: Stripe API Key
remote:     - Detected: sk_live_51Abc123...
remote: 
remote: Push protection has blocked this push.
remote: 
remote: To push these commits, you must:
remote:   1. Remove the secret from the commits (recommended)
remote:   2. Request a bypass (requires justification)
remote: 
To https://github.com/user/repo.git
 ! [remote rejected] main -> main (push declined due to secret scanning)
error: failed to push some refs to 'https://github.com/user/repo.git'

Critères de détection

La protection d’envois (push) utilise les mêmes modèles de secrets que l’analyse de secrets, mais applique des critères plus stricts :

  • Modèles à haute confiance uniquement : détecte les secrets avec des modèles vérifiables bien définis pour minimiser les faux positifs.
  • Validation active : vérifie que les modèles correspondent aux formats d’informations d’identification légitimes.
  • Analyse du contexte : considère le code environnant pour distinguer les secrets réels des données de test.

Cette approche conservatrice se concentre sur la prévention des expositions d’informations d’identification définitives tandis que l’analyse de secrets post-commit intercepte des modèles de confiance inférieure.

Disponibilité de la protection Push

La disponibilité de la protection push varie en fonction de la visibilité du référentiel et du niveau d’abonnement GitHub.

Dépôts publics

Pour les dépôts publics :

  • Activé par défaut : tous les nouveaux référentiels publics ont automatiquement activé la protection push (depuis 2024).
  • Gratuit : aucun coût associé à la fonctionnalité.
  • Disponible globalement : fonctionne pour tous les utilisateurs avec des référentiels publics.

Dépôts privés

Pour les dépôts privés, la protection push nécessite GitHub Advanced Security :

  • GitHub Enterprise Cloud : disponible avec licence Advanced Security.
  • GitHub Enterprise Server : disponible avec une licence Advanced Security.
  • Contrôle au niveau de l’organisation : les administrateurs activent la protection au niveau de l’organisation ou du référentiel.

Pour obtenir des instructions détaillées sur l’activation de la protection push, consultez la documentation sur la protection Push de GitHub.

Gestion des blocs de protection d’envois (push)

Lorsque la protection d’envois (push) bloque un envoi (push), vous disposez de trois options de résolution possibles.

L’approche sécurisée consiste à supprimer le secret de vos commits :

  1. Identifiez le secret : passez en revue le message d’erreur pour localiser le fichier et la ligne contenant le secret.

  2. Supprimez le secret localement : modifiez le fichier pour supprimer les informations d’identification codées en dur :

    // Before (blocked by push protection)
private const string StripeKey = "sk_live_51Abc123...";

// After (reads from environment variable)
private readonly string _stripeKey = Environment.GetEnvironmentVariable("STRIPE_API_KEY");

  3. Modifiez la validation : si le secret se trouve dans votre validation la plus récente :

    git add .
git commit --amend --no-edit

  4. Réécrire l'historique des commits plus anciens : si le secret se trouve dans des commits antérieurs, utilisez une réorganisation interactive :

    git rebase -i HEAD~5  # Adjust number based on how far back the commit is

    Marquez les commits problématiques pour modification, supprimez le secret, puis poursuivez le rebaser.

  5. Push avec succès : avec le secret supprimé, effectuez le push à nouveau :

    git push origin main

Cette approche garantit qu’aucun secret n’entre dans l’historique du référentiel.

Contourner la protection (utiliser avec précaution)

Dans des circonstances limitées, vous devrez peut-être contourner la protection Push. Les raisons valides sont les suivantes :

  • Faux positifs : le modèle détecté n’est pas réellement un secret (par exemple, des données de test, une documentation).
  • Exposition déjà connue : le secret est déjà exposé ailleurs et la rotation est planifiée séparément.
  • Migration de code héritée : déplacement du code existant avec des secrets (correction des secrets dans un processus séparé).

Pour contourner la protection push, GitHub fournit une option de contournement lors de l’affichage de l’erreur push bloquée. Vous devez fournir une justification pour la déviation.

Important

Le contournement de la protection d’envois (push) n’ignore pas l’alerte de l’analyse de secrets. Le secret est toujours marqué sous l’onglet Sécurité et nécessite une correction. Utilisez le contournement uniquement lorsqu’il est nécessaire et assurez-vous que les secrets contournés font toujours l’objet d’une rotation et d’une sécurisation correcte.

Autoriser le modèle

Si votre organisation configure des modèles autorisés (exemptions pour les informations d’identification de test, exemples fiables connus ou chemins d’accès de fichiers spécifiques), le modèle peut être autorisé automatiquement. Contactez l’équipe de sécurité de votre organisation si vous pensez qu’un modèle doit être ajouté à la liste autorisée.

Interaction entre l’analyse de secrets et la protection d’envois (push)

L’analyse de secrets et la protection d’envois (push) fonctionnent ensemble en tant que couches complémentaires de protection des informations d’identification :

  • Protection push (proactive) : empêche les secrets d’entrer dans le dépôt dès le début.
  • Analyse des secrets (détective) : intercepte les secrets qui contournent la protection Push ou existaient avant l’activation de la protection Push.

Scénarios courants

Comprendre comment ces fonctionnalités interagissent vous aide à répondre de manière appropriée.

Activation des deux fonctionnalités, nouveau secret

Lorsque les deux fonctionnalités sont actives et que vous tentez de valider un nouveau secret, la protection push empêche entièrement le problème :

  1. Vous tentez d’envoyer (push) un commit ayant un secret.
  2. La protection d’envois (push) bloque l’envoi (push).
  3. Vous supprimez le secret et envoyez (push) correctement.
  4. Aucune alerte d’analyse de secret n’est générée (le secret n'a jamais été introduit dans le dépôt).

Protection Push ignorée

Lorsque vous contournez la protection d’envois (push), l’analyse de secrets crée toujours une alerte nécessitant une correction :

  1. Vous contournez la protection d’envois (push) avec une justification.
  2. Le commit entre dans le référentiel.
  3. L’analyse des secrets génère une alerte sous l’onglet Sécurité.
  4. Vous devez toujours corriger le secret exposé.

Secret enregistré avant l’activation de la protection

Les secrets historiques nécessitent un nettoyage manuel, même après l’activation de la protection Push :

  1. La protection Push vient d'être activée.
  2. L’analyse de secrets découvre le secret historique.
  3. L’alerte s’affiche sous l’onglet Sécurité.
  4. Vous devez supprimer le secret de l’historique Git.

Modèle de faible confiance

Chaque fonctionnalité de sécurité gère les modèles ambigus différemment, fournissant une détection en couches :

  1. Vous commitez du code avec un modèle ambigu.
  2. La protection Push autorise l’envoi (bloque uniquement les secrets à haut niveau de confiance).
  3. L’analyse des secrets peut générer une alerte pour révision.
  4. Vous évaluez si c’est un vrai secret.

Meilleures pratiques

Pour optimiser l’efficacité de la protection :

  • Activer les deux fonctionnalités : la protection maximale nécessite à la fois l’analyse secrète et la protection push.
  • Ne vous fiez pas à la déviation : traitez le contournement comme une action exceptionnelle nécessitant de la documentation.
  • Nettoyer les secrets historiques : l’activation de la protection Push ne nettoie pas rétroactivement les secrets existants ; utilisez des alertes d’analyse des secrets pour guider le nettoyage.
  • Marquer clairement les données de test : commentez les informations d’identification de test pour aider les deux systèmes à les distinguer des secrets réels.

Limitations et considérations

Comprendre les limitations de la protection Push peut vous aider à implémenter une sécurité complète :

Limitations de l’étendue

La protection push fonctionne uniquement au moment de l’envoi de la requête push.

  • Aucune protection locale : les secrets dans les commits locaux ne sont pas détectés tant que vous n’avez pas effectué un push.
  • Détection basée sur des modèles : Les formats d’informations d’identification personnalisés ou propriétaires inconnus pour GitHub peuvent ne pas être détectés.
  • Aucune protection pour les flux de travail non Git : n’empêche pas les secrets dans les chargements de fichiers manuels ou les modifications apportées au référentiel basé sur l’API.

Impact du flux de travail

La protection Push nécessite une action immédiate :

  • Les envois push bloqués doivent être résolus : vous ne pouvez pas différer la correction comme avec les alertes post-validation.
  • Interruption potentielle du flux de travail : les développeurs qui ne connaissent pas la gestion des secrets peuvent trouver des blocs frustrants.

Fournir une bonne documentation et une formation réduit les interruptions de flux de travail tout en conservant la sécurité.

Pratiques complémentaires

Utilisez d’autres outils en même temps que la protection push :

  • Hooks de pré-commit : interceptez des secrets localement avant de tenter d’effectuer un push.
  • Modèles de variables d’environnement : fournissez des .env.example fichiers affichant les variables requises sans valeurs réelles.
  • Bibliothèques de gestion des secrets : utilisez le Kit de développement logiciel (SDK) Azure Key Vault, le Kit de développement logiciel (SDK) Amazon Web Services (AWS) Secrets Manager ou des outils similaires.
  • Révision du code : entraîner les réviseurs à surveiller les informations d’identification codées en dur.