Intégrer Azure DevOps
Surveillez les dépôts Azure DevOps à la recherche de secrets exposés dans les fichiers sources, les fichiers de configuration et les historiques de commits.
Pourquoi surveiller Azure DevOps ?
Les dépôts Azure DevOps sont profondément intégrés aux services Azure, à Microsoft 365 et aux systèmes Active Directory d'entreprise. Lorsque les développeurs committent des identifiants ou des secrets de connexion de service, ils risquent d'exposer non seulement des applications individuelles, mais des infrastructures cloud entières, accordant potentiellement aux attaquants l'accès aux ressources Azure de production et aux données d'entreprise sensibles.
Fonctionnalités
| Fonctionnalité | Prise en charge | Détails |
|---|---|---|
| Scan historique | ✅ (Pris en charge) | Analyse complète de l'historique du dépôt |
| Détection en temps réel | ✅ (Pris en charge) | Détection instantanée via webhooks |
| Périmètre surveillé | ✅ (Pris en charge) | Surveillance granulaire de vos Orgs et dépôts |
| Périmètre d'équipe | ✅ (Pris en charge) | Contrôle d'accès basé sur les équipes |
| Vérification de présence | ✅ (Pris en charge) | Vérifier si les secrets sont toujours accessibles |
| Pièces jointes | ❌ (Non pris en charge) | Non applicable pour les dépôts de code |
Ce que nous scannons :
- Fichiers de code source, fichiers de configuration et fichiers texte bruts
- Toutes les branches du dépôt et l'historique des commits
Configuration
Prérequis :
- Compte Owner ou Manager sur votre Dashboard GitGuardian
- Permissions d'admin Azure DevOps ou d'admin de projet pour les organisations que vous souhaitez surveiller
- Connectivité réseau entre GitGuardian et vos services self-hosted. Découvrez GitGuardian Bridge pour permettre des connexions sécurisées entre GitGuardian SaaS et vos services self-hosted dans des réseaux privés.
GitGuardian peut s'intégrer à Azure Repos de deux manières différentes : au niveau de l'instance ou au niveau de l'organisation/collection.
Dans Azure Repos, les termes Organization et Collection font référence au même concept selon la version de votre Azure DevOps. Dans le dashboard de GitGuardian, nous utilisons le terme Organization car c'est le plus courant, mais ne soyez pas gêné si vous avez Collection dans votre instance Azure Repos.
L'intégration Azure DevOps Repos nécessite un personal access token pour que GitGuardian puisse accéder à vos organisations/collections Azure Repos à des fins d'analyse.
Pour activer un scan en temps réel fonctionnel de vos projets et de votre dépôt, le propriétaire du personal access token doit être soit un Organization admin, soit un Project administrator pour tous les projets de votre organisation. Cela peut se faire en étant ajouté au groupe Project Collection Administrators de l'organisation.
Créer un Personal Access Token
Nous vous recommandons vivement d'utiliser un utilisateur bot afin de générer des personal access tokens.
- Rendez-vous dans la section « User setting » d'Azure DevOps.
- Pour Azure Repos Service, plongez dans la section « Personal access tokens » et créez un nouveau token. Pour Azure Repos Server, vous devez d'abord aller dans « Security », puis sélectionner la page Personal access tokens dans la barre latérale de gauche.
- Définissez un nom (ex : « gitguardian »).
- Choisissez si vous souhaitez fournir l'accès pour l'organisation actuelle ou pour l'ensemble de l'instance.
- IMPORTANT : Vous devez cocher le scope
Readpour Code et Graph (cliquez sur le lien « Show all scopes » pour afficher ce scope).
Le scopeGraph:Readest utilisé à des fins de facturation car il nous permet de consulter les utilisateurs, les groupes et leurs appartenances. - Nous vous recommandons de définir la date d'expiration à 1 an, ce qui est le maximum autorisé.
Azure DevOps a une limite de 1 an maximum pour la validité d'un token. Cela signifie que vous devrez renouveler le token si vous souhaitez maintenir l'intégration opérationnelle.
Le personal token permet à GitGuardian d'accéder à vos dépôts via vos permissions Azure DevOps.

Cliquez sur le lien « Show all scopes » pour afficher le scope pour Graph.


Cette intégration ne surveille pas les dépôts désactivés. Si vous incluez des dépôts désactivés dans votre périmètre, ils ne seront pas vérifiés et apparaîtront avec le statut Unknown.

Veuillez vous référer à la documentation Azure DevOps pour plus d'informations sur les personal access tokens.
Intégration au niveau de l'instance
Ce mode d'intégration surveillera automatiquement tous les projets et dépôts de l'instance. Lorsqu'un nouveau projet ou un nouveau dépôt est créé sur n'importe quelle organisation, il sera automatiquement inclus dans le périmètre par GitGuardian.
Exigences
- Azure DevOps Service ou Azure DevOps Server auto-géré : version minimale garantie compatible 2019
- Un personal access token avec un scope Read pour « Code » et « Graph ».
Directives
- Naviguez vers Settings > Integrations > Sources.
- Cliquez sur Configure pour Azure Repos.
- Cliquez sur Start pour l'option au niveau de l'instance : « Monitor the entire Azure Repos instance »

- Soumettez l'URL de votre instance Azure Repos et le personal access token créé.
attentionL'URL de l'instance Azure doit être préfixée par
https://, les instances sans connexion sécurisée ne seront pas surveillées. L'URL utilisée doit être de type scheme+basename (ex :https://azuredevops.gitguardian.example). - GitGuardian commencera à scanner votre instance Azure Repos. Vous pouvez consulter les projets et dépôts surveillés dans votre page de paramètres Azure Repos en cliquant sur See my Azure Repos perimeter.
Dépannage
- Vous pouvez soumettre de nouveaux personal access tokens si vous souhaitez surveiller davantage d'instances Azure Repos.
- GitGuardian détecte automatiquement si le personal access token devient invalide (par expiration ou révocation) et vous enverra un e-mail pour vous en informer. Toutes vos données existantes resteront accessibles.
- Si vous avez beaucoup de dépôts, ils peuvent mettre un certain temps à apparaître dans votre périmètre.
Intégration au niveau de l'organisation
Cette intégration surveillera uniquement les organisations que vous sélectionnez. Lorsqu'un nouveau projet est ajouté à une organisation surveillée, il sera automatiquement ajouté au périmètre. Cependant, les nouvelles organisations ajoutées à l'instance Azure Repos ne seront pas automatiquement incluses dans le périmètre GitGuardian.
Notez que vous ne pouvez pas avoir une intégration au niveau de l'instance et une intégration au niveau de l'organisation en même temps.
Exigences
- Azure DevOps Service ou Azure DevOps Server/Data Center auto-géré : version minimale garantie compatible 2019
- Un personal access token avec un scope Read pour « Code ».
Directives
- Naviguez vers Settings > Integrations > Sources.
- Cliquez sur Configure pour Azure Repos.
- Cliquez sur Start pour l'option au niveau de l'instance : « Monitor certain Azure Repos organizations only »

- Soumettez l'URL de votre instance Azure DevOps et le personal access token créé. Si vous souhaitez installer une seule organisation, soumettez également le nom de cette organisation.
attentionL'URL de l'instance Azure doit être préfixée par
https://, les instances sans connexion sécurisée ne seront pas surveillées. L'URL utilisée doit être de type scheme+basename (ex :https://azuredevops.gitguardian.example). - GitGuardian affichera l'organisation disponible pour la surveillance.
En cliquant surInstall, GitGuardian accédera à l'organisation et scannera le contenu des dépôts.

- Vous pouvez consulter les projets et dépôts surveillés dans votre page de paramètres Azure Repos en cliquant sur See my Azure Repos perimeter :
Dépannage
- Vous pouvez soumettre de nouveaux personal access tokens si vous souhaitez surveiller davantage d'instances ou d'organisations Azure Repos.
- GitGuardian détecte automatiquement si le personal access token devient invalide (par expiration ou révocation) et vous enverra un e-mail pour vous en informer. Toutes vos données existantes resteront accessibles.
- Si vous avez beaucoup de dépôts, ils peuvent mettre un court instant à apparaître dans votre périmètre
- Si l'utilisateur Azure DevOps associé au personal access token utilisé pour l'intégration n'a pas suffisamment de permissions pour la surveillance en temps réel des projets, une icône visuelle sera affichée à côté du projet. Cette icône indique que le projet fait toujours partie de votre périmètre et peut être scanné manuellement, mais qu'il ne peut pas être surveillé en temps réel.

Faire tourner/Remplacer un Personal Access Token
Dans Azure Repos, la durée de vie maximale d'un Personal Access Token est de 365 jours, et il n'existe aucune option pour prolonger cette durée. De plus, la mise à jour des scopes d'un Personal Access Token nécessite d'en créer un nouveau ; il ne peut pas être modifié directement. Par conséquent, il est nécessaire de remplacer votre Personal Access Token au moins une fois par an pour continuer à scanner vos dépôts avec GitGuardian.
Pour minimiser les interruptions, nous recommandons de :
- Générer un nouveau Personal Access Token dans Azure DevOps avant l'expiration de l'actuel.
- Ajouter ce Personal Access Token nouvellement créé à la liste des tokens dans GitGuardian.
- Supprimer l'ancien Personal Access Token uniquement après avoir effectué les étapes 1 et 2.
Cela garantit une transition fluide, permettant au nouveau Personal Access Token de prendre le relais au cas où le token actuel expirerait ou serait supprimé, maintenant ainsi le fonctionnement de votre intégration.
Pour les installations au niveau de l'organisation, le nouveau Personal Access Token doit avoir les mêmes permissions. À défaut, cela pourrait entraîner un accès incomplet à certaines organisations. GitGuardian continuera de surveiller celles qui sont accessibles et désinstallera la ou les organisations qui ne sont plus joignables.
Scan historique automatique
Par défaut, GitGuardian effectue un scan historique pour chaque nouveau dépôt Azure Repos ajouté à votre périmètre.
Vous pouvez désactiver ce comportement dans vos paramètres Azure Repos si vous êtes Manager du workspace.

Surveillance automatique des dépôts
Par défaut, GitGuardian surveille automatiquement les dépôts ajoutés à votre périmètre.
Vous pouvez désactiver ce comportement dans vos paramètres Azure Repos si vous êtes Manager du workspace.
Comprendre les capacités de scan
Scan historique
Découvrez votre dette de secrets : Lors de votre première intégration de cette source, GitGuardian effectue un scan complet de l'intégralité de votre historique de contenu, en fonction de votre périmètre personnalisé. Cela révèle des secrets qui ont pu être exposés il y a des semaines, des mois, voire des années — vous aidant à traiter votre dette de sécurité existante.
Comment déclencher un scan historique : Rendez-vous sur votre page de périmètre, sélectionnez les sources que vous souhaitez scanner, puis cliquez sur Scan dans la barre d'actions groupées. Consultez Gérer votre périmètre surveillé pour connaître les limites de taille selon le plan, la gestion des erreurs et tous les détails.
Scan en temps réel
Détectez instantanément les nouvelles expositions : Une fois intégré, GitGuardian surveille en continu votre contenu grâce à une détection basée sur les événements. Tout contenu nouveau ou modifié contenant des secrets est détecté immédiatement, vous permettant de réagir rapidement aux nouvelles expositions.
Personnaliser votre périmètre surveillé
Une fois votre intégration Azure Repos configurée, vous avez la possibilité de configurer quels projets et dépôts surveiller dans la section des paramètres Azure Repos de votre workspace.

Si vous désélectionnez un dépôt de votre périmètre surveillé, GitGuardian ne recevra aucun commit pour vos futurs scans.
Gérer votre intégration
Surveillance de la santé et maintenance
Si vous devez modifier les paramètres de votre intégration ou résoudre des problèmes de connectivité, accédez à l'interface de gestion via Sources integration.
Désinstaller l'intégration
Bien que notre objectif soit de vous aider à maintenir une couverture de sécurité complète, vous pouvez désinstaller l'intégration chaque fois que nécessaire :
- Naviguez vers Sources integration
- Cliquez sur Edit à côté du nom de l'intégration
- Cliquez sur Configure
- Cliquez sur l'icône delete à côté de votre ressource
- Confirmez la suppression
Note : la suppression de l'intégration préserve votre historique d'incidents, mais arrête les analyses futures et les vérifications de présence pour les intégrations qui le supportent.