À propos de la protection push
La protection push est une fonctionnalité de secret scanning conçue pour empêcher les informations sensibles, telles que les secrets ou les jetons, d’être envoyées à votre référentiel en premier lieu. Contrairement à secret scanning, qui détecte les secrets une fois qu’ils ont été validés, la protection push analyse de manière proactive votre code pour détecter les secrets pendant le processus push et bloque le push s’ils sont détectés.
La protection push vous permet d’éviter les risques associés aux secrets exposés, tels que l’accès non autorisé aux ressources ou aux services. Avec cette fonctionnalité, les développeurs reçoivent des commentaires immédiats et peuvent résoudre les problèmes potentiels avant qu’ils ne deviennent un problème de sécurité.
Pour plus d’informations à propos des secrets et fournisseurs de services pris en charge pour la protection d’envoi (push), consultez Modèles d’analyse de secrets pris en charge.
La protection par envoi (push) a certaines limites. Pour plus d’informations, consultez « Résolution des problèmes d’analyse des secrets ».
Comment fonctionne la protection push
Fonctionnement de la protection push :
- Depuis la ligne de commande. Consultez Travailler avec la protection push à partir de la ligne de commande.
- Dans l’interface utilisateur GitHub. Consultez « Utilisation de la protection push dans l’interface utilisateur GitHub. »
Une fois activé, si la protection push détecte un secret potentiel lors d’une tentative push, elle bloque l’envoi et fournit un message détaillé expliquant la raison du bloc. Vous devrez examiner le code en question, supprimer toute information sensible et réessayer le push.
Par défaut, toute personne disposant d’un accès en écriture au référentiel peut choisir de contourner la protection push en spécifiant l’une des raisons de contournement décrites dans la table. Si un contributeur contourne un bloc de protection de poussée pour un secret, GitHub :
- Crée une alerte sous l’onglet Sécurité du dépôt.
- Ajoute l’événement de contournement au journal d’audit.
- Envoie une alerte par e-mail aux propriétaires de l’organisation ou de compte personnel, aux responsables de la sécurité et aux administrateurs de référentiels, qui regardent le référentiel, avec un lien vers le secret associé et la raison pour laquelle il a été autorisé.
Ce tableau montre le comportement des alertes pour chaque façon dont un utilisateur peut contourner un blocage de la protection push.
| Motif du contournement | Comportement des alertes |
|---|---|
| Il est utilisé dans des tests | GitHub crée une alerte fermée, résolue comme « utilisé dans des tests » |
| C'est un faux positif | GitHub crée une alerte fermée, résolue comme « faux positif » |
| Je le corrigerai plus tard | GitHub crée une alerte ouverte |
À propos des avantages de la protection push
-
Sécurité préventive : la protection push agit comme un mécanisme de défense de première ligne en analysant le code pour les secrets au moment de l’envoi. Cette approche préventive permet d’intercepter les problèmes potentiels avant qu’ils ne soient fusionnés dans votre référentiel.
-
Commentaires immédiats : les développeurs reçoivent des commentaires instantanés si un secret potentiel est détecté lors d’une tentative push. Cette notification immédiate permet une correction rapide, ce qui réduit la probabilité d’exposer des informations sensibles.
-
Réduction du risque de fuites de données : en bloquant les validations qui contiennent des informations sensibles, la protection push réduit considérablement le risque de fuites de données accidentelles. Cela permet de protéger contre l’accès non autorisé à votre infrastructure, à vos services et à vos données.
-
Gestion efficace des secrets : au lieu de traiter rétrospectivement les secrets exposés, les développeurs peuvent résoudre les problèmes à la source. Cela rend la gestion des secrets plus efficace et moins fastidieuse.
-
Intégration à des pipelines CI/CD : la protection push peut être intégrée à vos pipelines d’intégration continue/de déploiement continu (CI/CD), ce qui garantit que chaque envoi est analysé pour les secrets avant qu’il ne soit déployé. Cela ajoute une couche supplémentaire de sécurité à vos pratiques DevOps.
Personnalisation de la protection push
Une fois la protection push activée, vous pouvez la personnaliser plus loin :
Intégrer avec des pipelines CI/CD
Intégrez la protection push à vos pipelines d’intégration continue/déploiement continu (CI/CD) pour vous assurer qu’il exécute des analyses pendant les processus automatisés. Cela implique généralement d’ajouter des étapes dans votre fichier de configuration de pipeline pour appeler les API de GitHub ou d’utiliser GitHub Actions.
Définir des modèles personnalisés
Définissez des modèles personnalisés que la protection push peut utiliser pour identifier les secrets et bloquer les envois (push) contenant ces secrets. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».