Un identifiant qui atteint un commit poussé est déjà divulgué, même si un commit ultérieur le supprime. Sécurité détecte les identifiants dans vos modifications et votre historique, n'en conserve aucun, et considère chacun comme ouvert jusqu'à ce que quelqu'un confirme sa rotation ou sa révocation.
Ce qui est analysé
- Chaque modification: les modifications de chaque pull request, dans le cadre du
Coroid Securitycontrôle, ainsi que les modifications des agents de Coroid avant leur commit. - La branche par défaut: chaque push, et une fois sur tout son historique. L'analyse de l'historique démarre lorsque le dépôt est connecté ou lorsque l'option Secrets fuites est activée.
- Les branches de demande de fusion: un identifiant poussé vers une branche pull request génère également une alerte, car il se trouve déjà dans le dépôt.
Une branche poussée sans pull request n'est pas analysée.
L'analyse de l'historique lit chaque commit accessible, du plus récent au plus ancien, et chaque version de fichier une seule fois. Elle fonctionne par tranches et reprend là où elle s'était arrêtée. Chaque dépôt a des limites quant à la quantité d'historique analysée (commits, octets, durée et taille de fichier) ; un dépôt dépassant ces limites présente une couverture partielle.
Ce qui est détecté
Les identifiants de fournisseur dans leurs formats connus (clés d'accès AWS, jetons GitHub et GitLab, clés OpenAI et autres), les jetons d'autorisation, les identifiants attribués à des noms tels que password ou api_key, les clés privées, les identifiants dans les URL, et les chaînes de caractères à forte entropie. Les identifiants présents dans le code ne sont détectés que si la valeur est littérale, et non une variable ou un appel de fonction.
Coroid ne conserve jamais la valeur.
Une valeur détectée passe directement du détecteur au courtier d'identifiants de Coroid, qui renvoie une empreinte numérique indexée et supprime la valeur. Seule l'empreinte est stockée. Elle est indexée par organisation, afin de ne pas pouvoir être comparée entre organisations ou devinée hors ligne.
Partout où un secret apparaît normalement (alertes, contrôles, commentaires de revue,
journaux), Coroid n'affiche que la règle, la longueur et l'emplacement, par exemple
[redacted secret: named_credential, 40 characters]. Aucune partie de la valeur n'est affichée, pas même ses premiers caractères.
Coroid n'essaie jamais d'utiliser un identifiant qu'il détecte pour vérifier s'il fonctionne.
Un identifiant, une alerte
Un identifiant présent dans plusieurs commits constitue une alerte avec plusieurs occurrences. Le même identifiant dans deux dépôts génère deux alertes, une par dépôt. Lorsque vous en attestez une, Sécurité liste les autres avec le même identifiant afin que vous puissiez les attester ensemble. Il ne le fait jamais de lui-même.
Une fuite de secret ne se ferme qu'après attestation
Supprimer un identifiant du code rend ses occurrences inexistantes, mais l'alerte reste ouverte : toute personne ayant consulté le dépôt auparavant pourrait encore en disposer. Elle ne se ferme qu'après qu'un propriétaire ou administrateur ait attesté des actions effectuées :
- Rotation ou révocation;
- la date à laquelle cela a été fait ;
- une note optionnelle.
Sécurité enregistre qui a attesté et quand, et l'affiche sur l'alerte : "Rotation le 28 octobre, attestée par Alex le 29 octobre". L'alerte passe alors à Rotation attestée.
Corriger une fuite de secret
Créer la tâche de liste de contrôle crée une tâche dans le projet avec ces étapes :
- Rotations ou révocation de l'identifiant auprès de son fournisseur.
- Le placer à l'endroit où le projet stocke ses identifiants.
- Le supprimer du code.
- Attester la rotation dans Sécurité.
La tâche ne se répète jamais ni n'essaie d'utiliser l'identifiant. Elle ne réécrit pas l'historique Git : supprimer un identifiant de l'historique relève d'une décision de votre équipe, et cela ne rend pas à nouveau sûr un identifiant divulgué.
Identifiant réel ou pas de problème
Sur une alerte de secret, les propriétaires et administrateurs répondent à S'agissait-il d'un vrai identifiant ?
- Identifiant réel maintient l'alerte ouverte jusqu'à son attestation.
- Pas de problème enregistre une exception de faux positif qui masque l'alerte, par exemple pour un jeu de données de test. Identifiant réel supprime à nouveau cette exception.
Ces réponses aident également à calibrer les détecteurs.
Blocage
Secrets fuites fonctionne en mode observation par défaut. Il ne bloque qu'une fois que ses détecteurs ont été calibrés et que l'application est activée. Consultez Protections et application.
Les organisations ayant activé l'ancienne analyse de secrets dans leur politique d'organisation continuent d'être bloquées par celle-ci, avec sa version de détecteur, jusqu'à ce que les nouveaux détecteurs passent la calibration. Cette ancienne analyse ne génère pas de constatations, donc aucune exception ni attestation ne peut contourner ce qui est bloqué.
Par défaut pour l'organisation, Bloquer les nouveaux secrets et les plus grandes modifications scannées sont classées sous « Secrets divulgués ».
Notifications
Les constatations relatives aux secrets n'envoyent pas encore de notifications. Elles apparaissent dans Sécurité → Constatations et dans Aperçu.
GitHub analyse de secrets
Si l'analyse de secrets propre à GitHub est activée pour un dépôt, Sécurité peut importer ses alertes. Une alerte d'analyse de secrets de GitHub reste ouverte tant qu'elle n'est pas résolue sur GitHub ; fusionner une correction ne la ferme donc pas là-bas. Voir GitHub alertes de sécurité.