Incidents temps réel

Après avoir ajouté la détection automatisée de secrets à vos dépôts, vous devez établir des processus de remédiation précis pour les incidents temps réel que la plateforme GitGuardian Internal Monitoring va remonter.

À ce stade, vous devrez déterminer :

• Quelle équipe/rôle est responsable de la remédiation des incidents. Quelle équipe/rôle sera tenue responsable des incidents ouverts.
• Quelle équipe/rôle consulter pendant le processus de remédiation (par exemple, les ingénieurs DevOps peuvent devoir intervenir pour éviter les pannes de service lors de la rotation des secrets).
• Quelle autonomie/confiance vous êtes prêt à donner aux développeurs pour la remédiation des incidents.

Chez GitGuardian, nous pensons que les développeurs devraient être au premier plan lorsqu'il s'agit de remédier aux incidents dont ils sont responsables. Pour rapprocher vos équipes de sécurité et vos développeurs, GitGuardian Internal Monitoring suggère deux options :

• La première consiste à fournir un accès externe aux incidents dans lesquels un développeur est impliqué.
• La seconde nécessite que le développeur s'inscrive sur GitGuardian et rejoigne votre workspace pour voir ses incidents in-app. Les deux options peuvent être automatisées avec ce que nous appelons les Playbooks. Ce sont des flux de processus exécutant une série de jobs automatisés sans l'intervention manuelle de vos ingénieurs sécurité ou logiciel.

Option 1. Utiliser la fonctionnalité dev-in-the-loop pour fournir un accès externe

Vous pouvez automatiser le processus de partage d'incident avec les développeurs impliqués en utilisant le playbook "Auto-share incident access to the author of the leak". Chaque fois qu'un nouvel incident est détecté, GitGuardian enverra un email avec un lien unique au développeur pour voir les détails de l'incident sur une page autonome (externe).

Vous pouvez également choisir quelles options appliquer au lien de partage :

• Option de collecte de retours : la possibilité pour le développeur de soumettre un retour sur l'incident sur la page externe.
• Option de capacité de résolution : la possibilité pour le développeur de résoudre ou d'ignorer l'incident sur la page externe.

Aux premiers stades du déploiement, les équipes de sécurité devront probablement faire tout leur possible pour vérifier les progrès des développeurs sur la remédiation — l'option de collecte de retours est utile ici. Cette option fournit aux équipes de sécurité plus de contexte sur les incidents mais laisse le soin de la résolution à leurs membres.

À mesure que les deux équipes avancent et deviennent plus à l'aise avec leurs processus de collaboration et de remédiation, nous recommandons aux équipes de sécurité d'adopter le principe « faire confiance mais vérifier ». À long terme, nous conseillons que les développeurs soient habilités à résoudre leurs incidents avec aussi peu d'intervention que possible des équipes de sécurité — l'option auto-share avec capacité de résolution est utile ici.

Option 2. Inviter les développeurs à rejoindre votre workspace

attention

L'authentification SSO doit être activée sur votre workspace pour que ce scénario fonctionne. Vous êtes également responsable d'envoyer l'URL de connexion SSO à vos membres d'équipe avant le déploiement.

Vous pouvez automatiser le processus de donner accès aux détails d'incident dans le dashboard GitGuardian pour les membres avec un niveau d'accès Restricted (généralement réservé aux développeurs) grâce au playbook auto-access granting.

GitGuardian donnera automatiquement à l'utilisateur Restricted l'accès à la page de détails d'incident dans le dashboard en faisant correspondre l'email de l'auteur du commit avec l'email de l'utilisateur du dashboard. Pour respecter le principe du moindre privilège, les utilisateurs Restricted ne peuvent obtenir l'accès qu'à leurs incidents dans le dashboard. Les utilisateurs Restricted ne peuvent pas voir les incidents de leurs coéquipiers à moins qu'on leur en donne l'accès par un Manager du workspace (généralement réservé aux leads techniques de sécurité ou aux leads de développement).

Choisir l'une ou l'autre dépend de la proximité que vous voulez avec vos développeurs dans le processus de remédiation. Vous pouvez commencer avec l'option d'accès externe pour explorer comment les équipes de sécurité et de développement devraient travailler ensemble. Au fil du temps, vous devriez envisager de migrer vers la seconde option, où les développeurs font partie de votre workspace GitGuardian.

Nous pensons que cette option est plus précieuse pour les raisons suivantes :

• Le playbook auto-access granting n'est pas seulement pour les incidents temps réel. Il s'applique également à tous les incidents historiques que le développeur a commités avant la mise en œuvre de GitGuardian. Ce playbook sera pratique pour l'étape 3. Remédier aux incidents historiques (voir ci-dessous).
• Les Technical Security Leads pourront suivre les progrès de chaque développeur sur la remédiation de leurs incidents et les notifier directement dans le dashboard si nécessaire.
• Les développeurs avec accès au dashboard peuvent générer des Personal Access Tokens pour utiliser le CLI ggshield et implémenter le scan de secrets au niveau pre-commit.