Analyse de secrets

Les informations d’identification exposées dans les systèmes d’ingénierie offrent des opportunités facilement exploitables pour les attaquants. Pour vous défendre contre cette menace, GitHub Advanced Security pour Azure DevOps analyse les informations d’identification et d’autres contenus sensibles dans votre code source. La protection Push empêche également toute fuite d’informations d’identification.

L’analyse des secrets de votre référentiel recherche tous les secrets qui peuvent déjà exister dans votre code source dans l’historique et la protection push empêche toute nouvelle exposition de secrets dans le code source.

GitHub Advanced Security pour Azure DevOps fonctionne avec Azure Repos. Si vous souhaitez utiliser GitHub Advanced Security avec des référentiels GitHub, consultez GitHub Advanced Security.

À propos des alertes d’analyse des secrets

Lorsque Advanced Security est activé, il analyse les référentiels pour les secrets émis par un grand nombre de fournisseurs de services et génère des alertes d’analyse de secrets.

Si l’accès à une ressource nécessite des informations d’identification jumelées, l’analyse des secrets crée une alerte uniquement lorsque les deux composants de la paire sont détectés dans le même fichier. Le jumelage garantit que les fuites les plus critiques ne sont pas masquées derrière des informations sur les fuites partielles. La correspondance des paires permet également de réduire les faux positifs, car les deux éléments d’une paire doivent être utilisés ensemble pour accéder à la ressource du fournisseur.

L’onglet Sécurité avancée chez Repos>Advanced Security dans Azure DevOps est le hub pour afficher vos alertes de sécurité. Sélectionnez l’onglet Secrets pour afficher les alertes d’analyse des secrets. Vous pouvez filtrer par état et par type de secret. Vous pouvez accéder à une alerte pour plus de détails, notamment des conseils de correction. Après avoir activé Advanced Security, une analyse démarre pour le référentiel sélectionné, comprenant tous les commits historiques. Au fil du temps, les alertes commencent à apparaître à mesure que l’analyse progresse.

Il n’y a aucun impact sur les résultats si les branches sont renommées. Cela peut prendre jusqu’à 24 heures avant l’affichage du nouveau nom.

Pour corriger les secrets exposés, invalidez les informations d’identification exposées et créez-en un à sa place. Le secret nouvellement créé doit ensuite être stocké en toute sécurité de manière à ne pas le renvoyer directement dans le code. Par exemple, le secret peut être stocké dans Azure Key Vault. La plupart des ressources ont à la fois des informations d’identification primaires et secondaires. La méthode permettant de restaurer des informations d’identification principales par rapport à des informations d’identification secondaires est identique, sauf indication contraire.

Gérer les alertes d’analyse des secrets

Affichage des alertes pour un dépôt

Toute personne disposant d’autorisations contributeur pour un référentiel peut afficher un résumé de toutes les alertes pour un référentiel sous l’onglet Advanced Security sous Repos. Sélectionnez l’onglet Secrets pour afficher toutes les alertes d’analyse des secrets.

Si Advanced Security a récemment été activé pour votre référentiel, une carte indique que Advanced Security analyse toujours votre référentiel.

Une fois l’analyse terminée, tous les résultats sont affichés. Une seule alerte est générée pour chaque information d’identification unique détectée, dans toutes les branches et l’historique de votre référentiel. Il n’existe aucun filtre de branche, car ils sont regroupés dans une alerte.

Les secrets des non-fournisseurs sont visibles en sélectionnant « Autre » dans la liste déroulante Confiance de l’onglet Analyse des secrets.

Détails de l’alerte

Lorsque vous accédez à une alerte, une vue d’alerte détaillée s’affiche et affiche plus de détails sur la recherche et fournit des conseils de correction spécifiques pour résoudre l’alerte.

Avec les secrets des non-fournisseurs, l’étiquette Confiance : autre apparaît également via le badge de gravité dans l’affichage des détails de l’alerte.

Correction des alertes d’analyse des secrets

Chaque secret a des étapes de correction uniques pour vous guider dans la façon de révoquer et de régénérer un nouveau secret à sa place. Le détail de l’alerte partage des étapes ou de la documentation spécifiques pour chaque alerte.

Une alerte d’analyse de secret reste ouverte jusqu’à ce qu’elle soit fermée. Pour attester qu’une alerte d’analyse de secret est corrigée :

1. Accédez à l’alerte que vous souhaitez fermer et sélectionnez l’alerte.
2. Sélectionnez la liste déroulante Fermer l’alerte.
3. Si ce n’est pas déjà fait, sélectionnez Correction.
4. Sélectionnez Fermer pour envoyer et fermer l’alerte.

Ignorer les alertes d’analyse des secrets

Pour ignorer les alertes dans Advanced Security, vous avez besoin des autorisations appropriées. Par défaut, seuls les administrateurs de projet peuvent ignorer les alertes de sécurité avancée. Pour plus d’informations sur les autorisations Advanced Security, consultez Gérer les autorisations Advanced Security.

Pour ignorer une alerte :

1. Accédez à l’alerte que vous souhaitez fermer et sélectionnez-la.
2. Sélectionnez la liste déroulante Fermer l’alerte.
3. S’il n’est pas déjà sélectionné, sélectionnez Risque accepté ou Faux positif comme raison de fermeture.
4. Ajoutez un commentaire facultatif dans la zone de texte Commentaire.
5. Sélectionnez Fermer pour envoyer et fermer l’alerte.
6. L’état d’alerte passe d’Ouvert à Fermé et affiche le motif pour ignorer.

Toute alerte précédemment ignorée peut être rouverte manuellement.

Sécurisation des secrets compromis

Une fois qu’un secret est validé dans un référentiel, il est compromis. Microsoft recommande les actions suivantes pour les secrets compromis :

• Pour un jeton d’accès personnel Azure DevOps compromis, supprimez le jeton compromis, créez un nouveau jeton et mettez à jour tous les services qui utilisent l’ancien jeton.
• Pour tous les autres secrets, vérifiez d’abord que le secret validé dans Azure Repos est valide. Si c’est le cas, créez un secret, mettez à jour tous les services qui utilisent l’ancien secret, puis supprimez l’ancien secret.
• identifiez les actions effectuées par le jeton compromis sur les ressources de votre entreprise.

Lors de la mise à jour d’un secret, veillez à stocker le nouveau secret en toute sécurité et assurez-vous qu’il est toujours accessible et qu’il n’est jamais stocké en texte brut. Une option possible est par le biais d’Azure Keyvault ou d’autres solutions de gestion des secrets.

Protection push de secret

La protection Push vérifie les envois entrants pour les secrets à haut niveau de confiance et empêche le push de passer. Un message d’erreur affiche tous les secrets identifiés pour vous permettre de les supprimer ou de continuer à envoyer les secrets si nécessaire.

À propos des alertes de protection des poussées

Les alertes de protection push sont des alertes utilisateur qui sont signalées par la protection push. L’analyse des secrets en tant que protection Push analyse actuellement les référentiels des secrets émis par certains fournisseurs de services.

Si l’accès à une ressource nécessite des informations d’identification jumelées, l’analyse des secrets crée une alerte uniquement lorsque les deux composants de la paire sont détectés dans le même fichier. Le jumelage garantit que les fuites les plus critiques ne sont pas masquées derrière des informations sur les fuites partielles. La création de paires permet également de réduire les faux positifs, car les deux éléments d’une paire doivent être utilisés ensemble pour accéder à la ressource du fournisseur.

La protection Push peut ne pas bloquer les versions antérieures de certains jetons, car ces jetons peuvent générer un nombre plus élevé de faux positifs que leur version la plus récente. La protection Push peut également ne pas bloquer les jetons hérités. Pour les jetons tels que les clés de stockage Azure, Advanced Security prend uniquement en charge les jetons récemment créés, et non les jetons qui correspondent aux modèles hérités.

Protection push à partir de la ligne de commande

La protection push est intégrée en mode natif dans Azure DevOps Git. Si vos commits contiennent un secret identifié, vous voyez une erreur indiquant que votre envoi a été rejeté.

Protection push à partir de l’interface web

La protection Push fonctionne également à partir de l’interface web. Si un secret est identifié dans un commit, vous voyez le bloc d’erreur suivant qui vous empêche d’envoyer vos modifications :

Que faire si votre envoi a été bloqué

La protection push bloque les secrets trouvés dans des fichiers texte bruts qui sont généralement (mais pas limités à) des fichiers texte tels que le code source ou les fichiers de configuration JSON. Ces secrets sont stockés en texte brut. Si un acteur incorrect accède aux fichiers et qu’il est publié dans un référentiel public, les secrets sont utilisables par toute personne.

Il est recommandé de supprimer le secret du fichier avec indicateur, puis de supprimer le secret de l’historique de validation. Si le secret marqué est un espace réservé ou un exemple de secret, il est recommandé de mettre à jour le faux secret pour placer la chaîne Placeholder devant le faux secret.

Si le secret a été ajouté à votre commit précédent immédiat, modifiez le commit et créez-en un nouveau :

1. Supprimez le secret de votre code.
2. Validez les modifications à l’aide de git commit --amend
3. Envoyez à nouveau vos modifications.

Si le secret a été ajouté plus loin dans l’historique, modifiez vos commits à l’aide d’une nouvelle base interactive :

1. Utilisez git log pour déterminer le commit que vous avez validé pour la première fois le secret.
2. Effectuez un rebasement interactif : git rebase -i [commit ID before credential introduction]~1
3. Identifiez votre validation à modifier en passant pick à edit sur la première ligne du texte qui apparaît dans l’éditeur.
4. Supprimez le secret de votre code.
5. Validez la modification avec git commit --amend.
6. Terminez la relocalisation en exécutant git rebase --continue.

Envoyer un secret bloqué

Le contournement des secrets marqués n’est pas recommandé, car le contournement peut mettre en danger la sécurité de votre entreprise. Si vous vérifiez qu’un secret identifié n’est pas un faux positif, vous devez supprimer le secret de l’historique de votre branche entière avant de tenter de renvoyer vos modifications.

Si vous pensez qu’un secret bloqué est un faux positif ou sûr à envoyer, vous pouvez contourner la protection push. Incluez la chaîne skip-secret-scanning:true dans votre message de validation. Même si vous ignorez la protection push, une alerte d’analyse des secrets est générée dans l’expérience utilisateur de l’alerte une fois que le secret est envoyé.