Analyse de code sans agent dans Microsoft Defender pour le cloud
L'analyse de code sans agent dans Microsoft Defender pour le cloud offre une couverture de sécurité rapide et évolutive pour tous les référentiels dans Azure DevOps. Il détecte rapidement les vulnérabilités dans le code et les configurations d'infrastructure en tant que code (IaC) sans nécessiter d'agents ou de modifications du pipeline d'intégration et de déploiement continus (CI/CD). Cette approche simplifie la configuration et la maintenance avec un seul connecteur Azure DevOps, et fournit une large couverture, des informations continues et des résultats de sécurité exploitables. Il permet aux équipes de sécurité et de développement de se concentrer sur la résolution des risques sans interrompre les flux de travail de développement.
Prérequis
État de mise en production : préversion publique
Cas d’usage pris en charge :
Clouds : clouds commerciaux Azure
Régions prises en charge : Australie Est, Canada Centre, USA Centre, Asie Est, USA Est, Europe Nord, Suède Centre, Royaume-Uni Sud, Europe Ouest
Environnements pris en charge : connecteur Azure DevOps
Rôles et autorisations :
Pour configurer le connecteur :
- Administrateur de regroupement de projets : requis dans Azure DevOps pour effectuer la configuration initiale.
- Contributeur d’abonnement : nécessaire sur l’abonnement Azure pour créer et configurer le connecteur.
Pour afficher les résultats en matière de sécurité :
- Administrateur de sécurité : peut gérer les paramètres de sécurité, les stratégies et les alertes, mais ne peut pas modifier le connecteur.
- Lecteur de sécurité : peut afficher des suggestions, des alertes et des stratégies, mais ne peut apporter aucune modification.
Principaux avantages
- Gestion proactive des risques : identifiez les risques au début du processus de développement. Cela permet de soutenir les pratiques de codage sécurisées et de réduire les vulnérabilités avant qu'elles n'atteignent la production.
- Intégration sans effort : configurez rapidement avec une configuration minimale et aucun changement de pipeline.
- Gestion centralisée à l’échelle de l’entreprise : analysez automatiquement le code sur plusieurs référentiels à l’aide d’un seul connecteur. Cela permet d'obtenir une couverture étendue pour les grands environnements.
- Insights rapides pour une correction rapide : recevoir des insights sur les vulnérabilités actionnables juste après l’intégration. Cela permet d'apporter des solutions rapides et de réduire le temps d'exposition.
- Compatible avec les développeurs et transparents : fonctionnent indépendamment des pipelines d’intégration continue et de déploiement continu (CI/CD), sans aucune modification ni intervention directe du développeur. Cela permet une surveillance continue de la sécurité sans perturber la productivité ou les flux de travail des développeurs.
Fonctionnalités de risques de détection
L'analyse de code sans agent améliore la sécurité en offrant des suggestions de sécurité ciblées pour le code et les modèles d'infrastructure en tant que code (IaC). Cela s'ajoute aux suggestions de sécurité de la gestion de la sécurité du cloud (CSPM) fournies par le biais du connecteur. Les principales capacités de détection sont les suivantes :
- Vulnérabilités du code : recherchez des erreurs de codage courantes, des pratiques de codage non sécurisées et des vulnérabilités connues dans plusieurs langages de programmation.
- Configurations incorrectes de l’infrastructure en tant que code : détectez les configurations incorrectes de sécurité dans les modèles IaC susceptibles d’entraîner des déploiements non sécurisés.
La création du connecteur renforce la sécurité en fournissant un ensemble fondamental de suggestions de sécurité pour les référentiels, les pipelines et les connexions de service.
Outils d'analyse
L’analyse du code sans agent utilise différents outils open source pour rechercher des vulnérabilités et des configurations incorrectes dans le code et les modèles IaC (Infrastructure-as-Code) :
| Outil | Langues ou IaC prises en charge | Licence |
|---|---|---|
| Bandit | Python | Apache 2.0 |
| Checkov | Modèles IaC Terraform, fichiers de plan Terraform, modèles AWS CloudFormation, fichiers manifestes Kubernetes, fichiers graphiques Helm, fichiers Docker, modèles IaC Azure d’Azure Resource Manager (ARM), modèles IaC Azure Bicep, modèles AWS SAM (modèle d'application serverless), fichiers Kustomize, modèles de framework sans serveur, fichiers de spécification OpenAPI | Apache 2.0 |
| ESLint | JavaScript, TypeScript, JSX, TSX | MIT |
| Template Analyzer | Modèles IaC ARM, modèles IaC Biceps | MIT |
| Terrascan | Modèles IaC Terraform (HCL2), fichiers manifestes Kubernetes (YAML/JSON), Dockerfiles, modèles AWS CloudFormation (YAML/JSON), modèles IaC Azure ARM, fichiers graphiques Helm (v3), fichiers Kustomize | Apache 2.0 |
Ces outils prennent en charge un large éventail de langages et de cadres IaC, garantissant une analyse approfondie de la sécurité dans l'ensemble de votre base de code.
Plateformes et types de fichiers pris en charge
Système de gestion de versions
- Azure DevOps : prise en charge complète des référentiels connectés via le connecteur Azure DevOps.
Langages de programmation
- Python
- JavaScript/TypeScript
Plateformes et configurations de l'infrastructure en tant que code (IaC)
| Plateforme IaC | Types de fichiers pris en charge | Notes |
|---|---|---|
| Terraform | .tf, .tfvars |
Prend en charge les modèles Terraform IaC dans le langage HCL2, y compris les fichiers variables dans .tfvars. |
| Terraform Plan | Fichiers JSON | Inclut des fichiers JSON représentant les configurations prévues, utilisés pour l'analyse et le balayage. |
| AWS CloudFormation | Fichiers JSON, YAML | Prend en charge les modèles AWS CloudFormation pour définir les ressources AWS. |
| Kubernetes | Fichiers YAML, JSON | Prise en charge des fichiers manifestes Kubernetes pour définir les configurations dans les clusters. |
| Helm | Structure des répertoires de la carte Helm, fichiers YAML | Respecte la structure graphique standard de Helm ; prend en charge les fichiers graphiques de Helm v3. |
| Docker | Fichiers nommés Dockerfile | Supporte les Dockerfiles pour les configurations de conteneurs. |
| Modèles ARM Azure | Fichiers JSON | Prise en charge des modèles IaC d’Azure Resource Manager (ARM) au format JSON. |
| Azure Bicep | Fichiers .bicep | Prend en charge les modèles Bicep IaC, un langage spécifique au domaine (DSL) pour ARM. |
| AWS SAM | Fichiers YAML | Prend en charge les modèles d'application sans serveur (SAM) d'AWS pour les ressources serverless. |
| Kustomize | Fichiers YAML | Prise en charge des fichiers de configuration pour la personnalisation de Kubernetes (Kustomize). |
| Serverless Framework | Fichiers YAML | Prend en charge les modèles pour le framework Serverless dans la définition des architectures sans serveur. |
| OpenAPI | Fichiers YAML, JSON | Prise en charge des fichiers de spécification OpenAPI pour la définition d'API RESTful. |
Activer l'analyse de code sans agent sur vos organisations Azure DevOps
Pour connecter vos organisations Azure DevOps à Microsoft Defender pour le cloud et activer l’analyse du code sans agent, reportez-vous aux instructions de Connecter vos organisations Azure DevOps. L'illustration suivante montre le processus d'installation rapide et simple, en vous guidant à travers chaque étape pour une intégration transparente.
Comment fonctionne l’analyse de code sans agent
L'analyse de code sans agent fonctionne indépendamment des pipelines CI/CD. Il utilise le connecteur Azure DevOps pour analyser automatiquement le code et les configurations de l'Infrastructure-as-Code (IaC). Vous n'avez pas besoin de modifier les pipelines ou d'ajouter des extensions. Cette configuration permet une analyse large et continue de la sécurité dans plusieurs référentiels. Les résultats sont traités et affichés directement dans Microsoft Defender pour le cloud.
Processus d’analyse
Une fois que vous avez activé la fonction d'analyse de codes sans agent dans un connecteur, le processus d'analyse suit les étapes suivantes :
- Découverte du référentiel : le système identifie automatiquement tous les référentiels liés via le connecteur Azure DevOps juste après la création du connecteur, puis toutes les 8 heures.
- Récupération du code : il récupère en toute sécurité le dernier code de la branche par défaut (principale) de chaque référentiel à des fins d’analyse, d’abord après la configuration du connecteur, puis tous les 3 à 4 jours.
- Analyse : le système utilise un ensemble d’outils d’analyse intégrés gérés et mis à jour dans Microsoft Defender pour le cloud pour rechercher des vulnérabilités et des configurations incorrectes dans le code et les modèles IaC.
- Traitement des résultats : il traite les résultats de l’analyse par le biais du back-end de Microsoft Defender pour le cloud pour créer des suggestions de sécurité exploitables.
- Livraison des résultats : le système présente les résultats sous forme de recommandations de sécurité dans Microsoft Defender pour le cloud, ce qui permet aux équipes de sécurité de passer en revue et de résoudre les problèmes.
Fréquence et durée des analyses
- Fréquence des analyses :
- La sécurité des référentiels, des pipelines et des connexions de service est évaluée lors de la création du connecteur, puis toutes les 8 heures.
- Le système analyse le code et les modèles d'infrastructure en tant que code (IaC) à la recherche de vulnérabilités après la création du connecteur, puis tous les 3 à 4 jours.
- Durée de l’analyse : les analyses se terminent généralement dans les 15 à 60 minutes, en fonction de la taille et de la complexité du référentiel.
Afficher et gérer les résultats de l’analyse
Une fois les analyses terminées, vous pouvez accéder aux résultats de sécurité dans Microsoft Defender pour le cloud.
Résultats d’accès
Accédez à l’onglet Recommandations de sécurité dans Microsoft Defender pour le cloud.
Examinez la liste des suggestions, qui comprend des conclusions telles que :
Les dépôts Azure DevOps doivent avoir résolu les résultats de l’analyse du code : indique les vulnérabilités trouvées dans les référentiels de code.
Les référentiels Azure DevOps doivent avoir une infrastructure en tant que résultats d’analyse du code résolus : pointe vers des configurations incorrectes de sécurité détectées dans les fichiers de modèles IaC au sein des référentiels.
D'autres suggestions de sécurité générées par le connecteur Azure DevOps peuvent inclure :
- GitHub Advanced Security pour Azure DevOps (GHAzDO) doit être activé dans les dépôts Azure DevOps
- Les Azure Pipelines ne doivent pas avoir de secrets disponibles pour les builds des fourches
- Les connexions du service Azure DevOps ne doivent pas accorder l'accès à tous les pipelines
- Les groupes de variables Azure DevOps avec des variables de secret ne doivent pas accorder l'accès à tous les pipelines
- Les connexions du service classique Azure DevOps ne doivent pas être utilisées pour accéder à un abonnement
- (Préversion) Les référentiels Azure DevOps doivent exiger au minimum une approbation à deux réviseurs pour les envois de code
- (Préversion) Les référentiels Azure DevOps ne doivent pas autoriser les demandeurs à approuver leurs propres demandes de tirage
- (Préversion) La création de pipelines classiques doit être désactivée sur Azure DevOps Projects
- Les fichiers sécurisés Azure DevOps ne doivent pas accorder l'accès à tous les pipelines
Sélectionnez une suggestion pour obtenir des informations détaillées, notamment sur les fichiers affectés, les niveaux de gravité et les conseils de remédiation.
Différence entre l'analyse de code sans agent et l'analyse in-pipeline
L'analyse de code sans agent et l'analyse en ligne à l'aide de l'extension Microsoft Security DevOps offrent toutes deux une analyse de sécurité au sein d’Azure DevOps. Ils répondent à des besoins différents mais fonctionnent bien ensemble. Le tableau suivant met en évidence les principales différences pour vous aider à choisir l'option qui correspond à vos besoins en matière de sécurité et de développement.
| Aspect | Analyse de code sans agent | Analyse dans le pipeline |
|---|---|---|
| Ajuster le cas d’utilisation | Offre une large couverture avec un minimum de perturbations pour les développeurs | Fournit des analyses détaillées, intégrées au pipeline, avec des contrôles personnalisables |
| Étendue et couverture de l’analyse | L'accent est mis sur l'infrastructure en tant que code (IaC) et l'analyse des vulnérabilités du code, programmée tous les 3 à 4 jours | Offre une couverture étendue, y compris des binaires et des images de conteneurs, déclenchée à chaque exécution du pipeline |
| Installation et configuration | Aucune autre configuration n'est nécessaire après la création du connecteur | Nécessite une installation et une configuration manuelles dans chaque pipeline Azure CI/CD |
| Intégration de pipeline | Fonctionne indépendamment des pipelines (CI/CD) sans modifier les flux de travail | S'intègre dans le pipeline CI/CD, nécessitant une configuration YAML dans chaque pipeline |
| Personnalisation de l’analyseur | Les scanners ne peuvent pas être personnalisés ou exécutés de manière sélective | Permet la personnalisation avec des scanners spécifiques, des catégories, des langues, des niveaux de sensibilité et des outils non-Microsoft |
| Résultats et commentaires | Permet d'accéder aux résultats dans Microsoft Defender pour le cloud | Offre un retour d'information en temps quasi réel dans le pipeline CI/CD, les résultats étant également visibles dans Microsoft Defender pour le cloud |
| Critères d’arrêt et d’échec | Les constructions ne peuvent pas être interrompues | Peut être configuré pour interrompre les constructions en fonction de la gravité des découvertes en matière de sécurité |
Extensibilité et impact de la performance
L'analyse de code sans agent évite de créer des ressources dans l'abonnement et ne nécessite pas d'analyse pendant le processus de pipeline. Il utilise l'API Azure DevOps REST pour extraire les métadonnées et le code. Cela signifie que les appels API sont pris en compte dans les limites de taux d’Azure DevOps, mais que vous n'avez pas à supporter de coûts directs de transfert de données. Le service gère les analyses pour s'assurer qu'elles restent dans les limites du taux Azure DevOps sans interrompre l'environnement de développement. Cette méthode permet une analyse efficace et performante des référentiels sans affecter les flux de travail DevOps. Pour plus d’informations, consultez Limites du débit et de l’utilisation d’Azure DevOps.
Sécurité des données, conformité et contrôle d'accès pour la lecture de codes sans agent
Le service d’analyse de code sans agent Microsoft Defender pour le cloud garantit une gestion sécurisée et conforme de votre code en implémentant des mesures strictes de sécurité et de confidentialité des données :
- Chiffrement des données et contrôle d’accès : le système chiffre toutes les données en transit à l’aide de protocoles standard. Seuls les services autorisés de Microsoft Defender pour le cloud peuvent accéder à votre code.
- Résidence et rétention des données : les analyses se produisent dans la même zone géographique que votre connecteur Azure DevOps (États-Unis ou Europe) pour se conformer aux lois de protection des données. Le système ne traite le code que pendant la numérisation et le supprime ensuite en toute sécurité, sans stockage à long terme.
- Accès aux référentiels : le service génère un jeton d’accès sécurisé pour Azure DevOps afin d’effectuer des analyses. Ce jeton permet de récupérer les métadonnées et le code nécessaires sans créer de ressources dans votre abonnement. Seuls les composants de Microsoft Defender pour le cloud y ont accès, ce qui protège l'intégrité des données.
- Prise en charge de la conformité : le service s’aligne sur les normes réglementaires et de sécurité pour la gestion et la confidentialité des données, garantissant ainsi un traitement et une analyse sécurisés du code client conformément aux exigences régionales en matière de protection des données.
Ces mesures garantissent un processus de lecture de codes sécurisé, conforme et efficace, tout en préservant la confidentialité et l'intégrité de vos données.
Limitations (préversion publique)
Pendant la phase de préversion publique, les limitations suivantes s’appliquent :
Aucune analyse binaire : le système analyse uniquement le code et les fichiers IaC (Infrastructure-as-Code).
Fréquence d’analyse : il analyse les référentiels tous les 3 à 4 jours.
Taille du référentiel : elle limite l’analyse aux référentiels de moins de 1 Go.
Couverture des branches : les analyses couvrent uniquement la branche par défaut (principale).
Personnalisation de l’outil : vous ne pouvez pas personnaliser les outils d’analyse.