Incidents historiques
Avant de commencer
Tous les incidents ne sont pas créés égaux. Avant de plonger tête baissée dans la remédiation de centaines ou de milliers de vos incidents historiques, nous vous suggérons de définir d'abord quelques règles pour les prioriser. Voici quelques éléments à considérer avant de décider de la sévérité d'un incident et de la priorité qu'il doit recevoir :
| Critère | Exemple de question |
|---|---|
| Type | S'agit-il de credentials de cluster Kubernetes ou d'URL de webhook Slack ? |
| Validité | Ce secret peut-il encore être exploité ? |
| Présence | Est-il toujours dans l'historique git ? |
| Statut de fuite | Mon secret a-t-il fui en dehors du périmètre de mon organisation ? |
| Exposition | Ce secret est-il exposé sur un dépôt public détenu par mon organisation ? |
| Récence | Ce secret date-t-il du dernier trimestre ou d'il y a 5 ans ? |
| Occurrences | Ce secret a-t-il été exposé dans plusieurs fichiers et dépôts ? |
| Répertoire de test | Ce secret est-il utilisé à des fins de test ? |
| Secret Manager | Ce secret est-il stocké dans un ou plusieurs Secret Managers ? |
Dans la table d'incidents GitGuardian Internal Monitoring, assurez-vous d'utiliser au maximum les fonctionnalités de recherche, de filtrage et de tri.
Traiter les incidents historiques
Étape 1. Identifier vos développeurs actifs
Exportez tous les incidents historiques depuis votre dashboard GitGuardian : filtrez vos incidents en utilisant le champ Tags avec la valeur From historical scan. Alternativement, vous pouvez utiliser l'API REST pour cette opération.
Étape 2. Impliquer les développeurs dans le processus de remédiation
Notifier tous les développeurs impliqués, deux options sont disponibles :
- Option 1 – Partager les incidents en utilisant le Developer-in-the-Loop : utilisez l'API REST de GitGuardian pour récupérer les incidents et générer des liens de partage uniques que vous devrez envoyer aux développeurs actifs par email.
- Option 2 – Inviter les développeurs actifs à rejoindre votre workspace GitGuardian :
- Pour donner aux développeurs accès à tous leurs incidents passés, utilisez le lien de connexion SSO de GitGuardian avec un niveau d'accès par défaut défini sur Member pour les nouveaux membres du workspace en combinaison avec le playbook auto-access granting.
- Allez-y et assignez les incidents historiques aux développeurs : assurez-vous que les développeurs sont conscients du processus de remédiation et des attentes que vous avez fixées pour eux.
Étape 3. Suivre les progrès de remédiation de vos développeurs
- Les Managers du workspace peuvent voir tous les incidents historiques. Recherchez un email d'auteur de commit/développeur spécifique ou filtrez sur un assigné spécifique pour voir tous leurs incidents.
- Visualisez les incidents qui ont été laissés non traités (ni ignorés ni résolus) et laissez une note pour le développeur afin qu'il reprenne le processus de remédiation.
Si vous choisissez de remédier aux incidents historiques par lots, vous pouvez utiliser l'API REST pour récupérer tous les incidents correspondant aux conditions de votre choix. N'oubliez pas de stocker la liste des Ids d'incident du lot associé pour interroger l'API à nouveau et vérifier si la remédiation a été effectuée. Visitez la documentation de référence de l'API publique GitGuardian.
Le cas particulier des « incidents orphelins »
Votre processus de remédiation pour les incidents historiques doit prendre en compte un détail important : le développeur impliqué est-il toujours dans l'effectif ? Nous appellerons les incidents qui ont été commités par des développeurs ayant quitté votre organisation des incidents orphelins. Ces développeurs ne peuvent plus contribuer au processus de remédiation. Vous devrez malheureusement faire sans leur aide ni leur contexte. Voici ce que vous pouvez faire face à cette situation :
- Si possible, vérifiez que le développeur n'est plus dans l'effectif : vous pouvez interroger votre LDAP ou Active Directory si vous en avez un. Dans le processus, identifiez à quelles équipes le développeur appartenait lorsqu'il était actif.
- Dans tous les cas, identifiez les admins de dépôt ou les utilisateurs avec accès en écriture (emplacement de l'incident).
Maintenant, remplacez Étape 2. Impliquer les développeurs dans le processus de remédiation décrite ci-dessus par l'alternative suivante :
Étape 2. Impliquer les leads d'équipe ou les security champions dans le processus de remédiation
- Une fois que toutes les équipes impactées par des incidents orphelins sont identifiées, vous pouvez assigner les incidents historiques aux engineering leads, admins de repo ou tout autre membre dans le dashboard GitGuardian.
- Alternativement, si vous avez un programme « Security Champions » en place, vous pouvez tirer parti de cette ressource utile. Les Security Champions peuvent prendre en charge la tâche de remédier aux incidents historiques au nom des développeurs qui ne sont plus dans l'effectif.
Choisissez vos assignés judicieusement ! Les membres d'équipe impliqués dans le processus de remédiation doivent pouvoir accéder aux dépôts ou fichiers dans lesquels les occurrences de secrets ont été trouvées. Sans cela, leur portée d'action pourrait être trop limitée pour aider à faire avancer le processus de remédiation.
