Investiguez et remédiez votre premier incident ouvert
Qu'est-ce qu'un incident de secret ? Quelles en sont les implications ?
Les incidents de secret sont des problèmes ouverts qui nécessitent votre attention pour être résolus. Ils sont créés par notre moteur de détection de secrets qui scanne en continu vos dépôts monitorés à la recherche de secrets en clair et les affiche dans votre tableau de bord GitGuardian.
Laisser un secret en clair dans le contrôle de source représente une menace pour la sécurité des ressources protégées par ce secret. Pour en savoir plus sur les raisons pour lesquelles les secrets en clair sont une vulnérabilité qui nécessite l'attention de vos équipes Application ou Product Security, consultez le paragraphe correspondant dans notre section Concepts fondamentaux de Secrets Detection.
Quelles sont les occurrences d'un incident ?
Le même secret peut apparaître plusieurs fois dans votre VCS. On parle alors d'occurrences.
GitGuardian rationalise le processus de remédiation en regroupant automatiquement plusieurs occurrences du même secret en un seul incident de secret.
Ainsi, une occurrence d'un incident de secret est identifiée de manière unique par la combinaison des paramètres suivants :
- la source (par exemple : un dépôt GitHub ou un projet GitLab) impactée par l'occurrence du secret,
- le commit dans lequel nous avons détecté l'occurrence du secret,
- le fichier du commit contenant l'occurrence du secret,
- la ligne dans le fichier du commit où le secret est apparu.
Les alertes ne sont envoyées que lorsqu'un nouvel incident est créé ou rouvert à cause d'une régression. Une nouvelle occurrence rattachée à un incident de secret déjà ouvert ne déclenchera pas d'alerte.
GitGuardian définit une limite maximale de 1 000 occurrences pour un seul incident de secret (cela ne s'applique pas à la plateforme Self-Hosted).
Quelles sont les étapes critiques pour remédier un secret compromis ?
L'étape la plus importante est de révoquer le secret.
Une fois qu'un secret est exposé, il doit être considéré comme compromis et potentiellement exploitable par des attaquants.
Mais pour éviter une interruption opérationnelle, évaluez toujours d'abord l'impact d'une révocation.
GitGuardian vous fournit beaucoup de contexte et d'informations pour évaluer l'impact de l'exposition, mais surtout, mesurer l'impact de la révocation, grâce à l'identification des workloads utilisant ces identifiants.
Workflow de remédiation recommandé :
- Stockage sécurisé : stockez correctement le secret dans un secret manager ou un coffre sécurisé.
- Mettez à jour le code : corrigez le code de votre application pour récupérer le secret depuis l'emplacement de stockage sécurisé.
- Testez et déployez : réalisez des tests de non-régression, déployez en production et monitorer que votre application fonctionne comme attendu.
- Faites tourner et révoquez : générez de nouveaux identifiants, mettez-les à jour dans votre secret manager et révoquez/désactivez le secret compromis pour vous assurer qu'aucun attaquant ne puisse accéder au service concerné.
- Vérifiez les accès non autorisés : examinez les logs pour voir si le secret a été utilisé de manière malveillante, et procédez au processus de mitigation si une brèche est confirmée.
Cette approche garantit que vos systèmes restent opérationnels tout au long du processus de remédiation tout en mettant en œuvre des pratiques sécurisées de gestion des secrets.
Guides détaillés de remédiation :
Choisissez le guide qui correspond à votre situation :
- Pour les incidents internes (secrets dans vos dépôts monitorés) : Scénarios de remédiation
- Pour les incidents publics (secrets trouvés sur GitHub public) : Remédier les incidents publics
- Pour les fuites publiques GitHub (guide complet étape par étape) : Remédiation de fuites publiques GitHub
Que faire si je n'ai pas toutes les informations dont j'ai besoin ?
Obtenir plus de contexte :
- Impliquez le développeur qui a commité le secret - il a le plus de connaissances sur ce à quoi le secret donne accès
- Consultez la documentation du détecteur - chaque type de secret a des instructions de révocation spécifiques
- Utilisez la timeline de l'incident - examinez tous les commits et fichiers liés
- Suivez le processus d'investigation - utilisez notre guide d'investigation d'incident pour une analyse approfondie
Besoin d'aide pour le processus de remédiation ?
- Contactez votre équipe sécurité si vous n'avez pas la permission de révoquer le secret
- Utilisez les fonctionnalités de partage de GitGuardian pour collaborer avec les bons interlocuteurs
- Consultez notre documentation des détecteurs pour des conseils spécifiques sur la révocation de différents types de secrets
Prévention pour le futur :
Maintenant que vous avez géré votre premier incident, envisagez de mettre en œuvre ces mesures préventives pour attraper les secrets avant qu'ils n'entrent dans vos dépôts :
- Installez GitGuardian CLI (ggshield) - scannez les secrets localement et dans les pipelines CI/CD avant que le code ne soit commité
- Mettez en place des pre-commit hooks - empêchez automatiquement les secrets d'être commités dans vos dépôts
- Adoptez des pratiques sécurisées de gestion des secrets - utilisez des solutions appropriées de gestion de secrets au lieu de hardcoder les identifiants.