Partager via

Configurer l’analyse du code sans agent (Aperçu)

L’analyse du code sans agent dans Microsoft Defender pour Cloud offre une couverture de sécurité rapide et évolutive pour tous les référentiels dans Azure DevOps et GitHub. L’analyse du code sans agent analyse automatiquement le code, les dépendances open source et l’infrastructure en tant que code (IaC) pour identifier les vulnérabilités et les configurations incorrectes sans nécessiter de modifications apportées à vos pipelines de build ou de déploiement. Cette approche simplifie la configuration et la maintenance avec un seul connecteur Azure DevOps ou GitHub, et fournit une couverture étendue, des insights continus et des résultats de sécurité actionnables. 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.

Vous pouvez personnaliser les scanneurs à exécuter et définir exactement les organisations, projets ou référentiels à inclure ou exclure de l’analyse.

Prérequis

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

Voici quelques-uns des principaux avantages de l’analyse du code sans agent dans Microsoft Defender pour Cloud :

  • Gestion proactive des risques : identifiez les risques au début du processus de développement. Cela permet des pratiques de codage sécurisées et réduit les vulnérabilités avant d’atteindre la production. 
  • Intégration sans effort : configurer rapidement avec une configuration minimale et sans modifications 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 offre une couverture étendue pour les environnements volumineux. 
  • Insights rapides pour une correction rapide : recevoir des insights sur les vulnérabilités actionnables juste après l’intégration. Cela permet des correctifs rapides et réduit le temps d’exposition. 
  • Compatible avec les développeurs : fonctionnent indépendamment des pipelines d’intégration continue et de déploiement continu (CI/CD), sans modification ou implication directe des développeurs. Cela permet une surveillance continue de la sécurité sans perturber la productivité ou les flux de travail des développeurs.
  • Couverture et contrôle flexibles : Choisissez les scanners qui fonctionnent et ce qui est scanné. Vous pouvez couvrir tout par défaut ou personnaliser les paramètres pour inclure ou exclure des organisations, des projets ou des référentiels spécifiques. Cela vous permet de faire correspondre la couverture de sécurité à votre profil de risque et aux besoins opérationnels, sans complexité supplémentaire.
  • Création d’un module de facturation de logiciels (SBOM) : la génération automatique d’un SBOM sur chaque analyse permet aux équipes d’obtenir un inventaire précis et interrogeable des dépendances et des versions entre leurs référentiels, sans modifications de flux de travail supplémentaires. Cela permet une analyse rapide de l’impact, une réponse plus rapide aux vulnérabilités nouvellement divulguées et une prise de décision confiante lors de l’évaluation de l’exposition à des packages ou versions spécifiques.

Fonctionnalités de risques de détection

L’analyse du code sans agent améliore la sécurité en fournissant des recommandations ciblées et exploitables dans le code d’application, des modèles IaC (Infrastructure as code) et des dépendances tierces. Cela s'ajoute aux recommandations de sécurité de gestion de la posture de sécurité du cloud fournies via le connecteur. Les principales fonctionnalité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.
  • Vulnérabilités de dépendance : identifiez les vulnérabilités connues dans les packages open source et les packages de système d’exploitation découverts dans les référentiels.
  • Facture de logiciels (SBOM) : générer automatiquement un inventaire complet et interrogeable des dépendances et leurs versions pour chaque dépôt,

La création du connecteur améliore la sécurité en fournissant des recommandations de gestion de la posture de sécurité cloud fondamentales 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 License
Analyseur de modèle Modèles IaC ARM, modèles IaC Biceps MIT
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
Bandit Python Apache 2.0
ESLint JavaScript, TypeScript, JSX, TSX MIT
Trivy Analyse des vulnérabilités des packages de dépendances et du système d’exploitation à partir de manifestes de référentiel et de fichiers verrouillés (mode système de fichiers) Apache 2.0
Syft Alpine (apk), paquets Bitnami, C (conan), C++ (conan), Dart (pubs), Debian (dpkg), Dotnet (deps.json), Objective-C (cocoapods), Elixir (mix), Erlang (rebar3), Go (go.mod, Go binaries), GitHub (workflows, actions), Haskell (cabel, stack), Java (jar, ear, war, par, sar, nar, rar, native-image), JavaScript (npm, yarn), Plugins Jenkins (jpi, hpi), archives du noyau Linux (vmlinz), modules du noyau Linux (ko), Nix (sorties dans /nix/store), PHP (composer, PECL, Pear), Python (wheel, egg, poetry, requirements.txt, uv), Red Hat (rpm), Ruby (gem), Rust (cargo.lock, binaire auditable), Swift (cocoapods, swift-package-manager), plug-ins Wordpress, fournisseurs Terraform (.terraform.lock.hcl) Apache 2.0

Ces outils prennent en charge un large éventail de langages et d’infrastructures IaC (Infrastructure as-code), ce qui garantit une analyse approfondie de la sécurité dans votre base de code.

Systèmes 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.

  • GitHub : prise en charge complète des référentiels connectés via le connecteur GitHub.

Langages de programmation

  • Analyse statique du code : Python ; JavaScript/TypeScript.

  • Écosystèmes de dépendances (via Trivy) : Node.js (npm, yarn), Python (pip, Pipenv, Poetry), Java (Maven, Gradle), .NET (NuGet), Go modules, Ruby (RubyGems), PHP (Composer), Rust (Cargo) et d’autres langages et écosystèmes de package pris en charge via des manifestes et des fichiers de verrouillage.

Plateformes et configurations de l'infrastructure en tant que code (IaC)

Plateforme IaC Types de fichiers pris en charge Remarques
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 du code sans agent sur vos organisations Azure DevOps et GitHub

Vous pouvez connecter des organisations Azure DevOps et GitHub à Defender for Cloud pour activer l’analyse du code sans agent. Suivez les étapes décrites dans Connecter vos organisations Azure DevOps ou connectez vos organisations GitHub pour commencer.

Image GIF montrant le processus de configuration pour activer la lecture de codes sans agent

Personnaliser la couverture et l’étendue du scanneur

Pour GitHub et Azure DevOps, vous pouvez contrôler les scanneurs qui s’exécutent et spécifier exactement quels référentiels sont inclus ou exclus de l’analyse sans agent.

Capture d’écran montrant les paramètres personnalisés de l’analyse du code sans agent.

  • Sélectionnez des scanneurs : activez ou désactivez chaque scanneur de code et d’infrastructure en tant que code (IaC) en fonction de vos besoins.

  • Définir l’étendue de l’analyse : Déterminez si vous souhaitez analyser tous les référentiels par défaut ou définir une étendue personnalisée pour inclure ou exclure des organisations, des projets ou des référentiels spécifiques.

    • Mode d’exclusion : Analyser tout sauf ce que vous énumérez.
    • Mode d’inclusion : Analysez uniquement ce que vous listez.

  • Options d’étendue personnalisées :

    • Pour GitHub, définissez l’étendue par propriétaire ou référentiel.
    • Pour Azure DevOps, définissez l’étendue par organisation, projet ou référentiel.

  • Découvrir automatiquement les nouveaux référentiels : La découverte automatique de nouveaux référentiels est toujours limitée aux organisations ou projets inclus dans l’étendue du connecteur. Elle est activée par défaut lors de l’utilisation du mode d’exclusion et aucune liste d’étendue personnalisée n’est définie. Les dépôts nouvellement créés sont analysés automatiquement.

    La découverte automatique n’est pas disponible en mode d’inclusion, car seuls les référentiels répertoriés sont analysés.

    Cela vous permet de faire correspondre l’analyse à vos besoins de sécurité, de maintenir la couverture à jour à mesure que votre environnement augmente et d’éviter les analyses inutiles ou les zones non analysés.

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 ou GitHub pour analyser automatiquement le code et les configurations IaC (Infrastructure-as-code). 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.

Diagramme montrant l’architecture d’une analyse de code sans agent.

Processus d’analyse

Une fois que vous avez activé la fonctionnalité d’analyse du code sans agent au sein d’un connecteur, le processus d’analyse comprend les étapes suivantes :

  1. Découverte du référentiel : le système identifie automatiquement tous les référentiels liés via le connecteur Azure DevOps et GitHub immédiatement après la création du connecteur, puis toutes les 8 heures.

  2. Récupération du code : il récupère en toute sécurité le code le plus récent de la branche par défaut (principale) de chaque référentiel pour l’analyse, initialement après l’installation du connecteur, puis quotidiennement.

  3. Analyse : le système utilise un ensemble d’outils d’analyse intégrés gérés et mis à jour dans Microsoft Defender for Cloud pour rechercher des vulnérabilités et des configurations incorrectes dans les modèles IaC (code et infrastructure-as-code). Il crée également un SBOM pour permettre la gestion des packages interrogeables.

  4. 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.

  5. 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 d’analyse :

    • L’état de la sécurité des référentiels, des pipelines et des connexions de service est évalué lors de la création du connecteur, puis toutes les huit heures.
    • Le système analyse le code et les modèles IaC (Infrastructure-as-Code) pour détecter les vulnérabilités après avoir créé le connecteur, puis quotidiennement.

  • 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

  1. Accédez à l’onglet Recommandations de sécurité dans Microsoft Defender pour le cloud.

  2. Passez en revue les recommandations pour les référentiels Azure DevOps et GitHub, tels que :

  3. Pour obtenir la gamme complète de recommandations prises en charge pour les deux plateformes, consultez : Recommandations de sécurité Azure DevOps et GitHub.

    Les recommandations incluent des éléments tels que l’exigence d’approbations multi-réviseurs, la restriction de l’accès secret et l’application des meilleures pratiques pour les environnements Azure DevOps et GitHub.

    Sélectionnez une recommandation pour afficher des détails sur les fichiers concernés, la gravité et les étapes de correction.

Différence entre l'analyse de code sans agent et l'analyse in-pipeline

L’analyse du code sans agent et l’analyse dans le pipeline à l’aide de l’extension Microsoft Security DevOps offrent toutes deux une analyse de sécurité dans Azure DevOps et GitHub. Ils servent des besoins différents, mais se complètent. Le tableau suivant met en évidence les principales différences pour vous aider à choisir l’option qui convient le mieux à 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 Se concentre sur l’infrastructure en tant que code (IaC), les vulnérabilités de code et les vulnérabilités de dépendance open source sur une base planifiée (quotidienne) 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 Vous permet de sélectionner les scanneurs qui s’exécutent 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 REST Azure DevOps et GitHub pour extraire des métadonnées et du code. Cela signifie que les appels d’API comptent vers les limites de débit Azure DevOps et GitHub, mais vous n’entraînez pas de coûts directs de transfert de données. Le service gère les analyses pour s’assurer qu’elles restent dans les limites de débit Azure DevOps et GitHub 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 les limites de débit et d’utilisation d’Azure DevOps et les limites de débit pour l’API REST GitHub.

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 vos connecteurs Azure DevOps et GitHub (États-Unis ou UE) 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 et GitHub 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 : seuls le code (SAST) et les outils d’analyse IaC sont exécutés.
  • Fréquence d’analyse : il analyse les référentiels lors de l’activation, puis quotidiennement.
  • 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 (généralement main).
  • Personnalisation de l’outil : vous ne pouvez pas personnaliser les outils d’analyse.

Actuellement, SBOM présente les limitations suivantes :

  • Le référentiel a besoin d’un fichier de verrouillage ; sinon, seules les dépendances directes sont trouvées
  • La limite de taille SBOM est limitée à 1 Mo. S’il existe un grand nombre de packages identifiés, notre ingestion dans la carte cloud échoue.
  • L’activation de SBOM n’est pas configurable. Un SBOM est généré lors de chaque analyse sans agent.
  • Le délai d’expiration est défini sur 15 minutes pour que l’outil SBOM s’exécute.
  • La désactivation de l’agentless ne supprime pas les recommandations SBOM.

Contenu connexe

  • Last updated on