Lors d’Ignite 2025 le mois dernier Microsoft a annoncé quatre évolutions structurantes pour Microsoft Defender for Cloud destinées à mieux sécuriser des environnements hybrides / multicloud, des chaînes DevSecOps plus rapides, et l’émergence des agents IA.
L’idée directrice est claire : rapprocher encore davantage la sécurité du code jusqu’à l’exécution, et réduire les frictions entre équipes développement, SecOps et cloud ops.
Le lien vers l’article Microsoft https://techcommunity.microsoft.com/blog/microsoftdefendercloudblog/microsoft-defender-for-cloud-innovations-at-ignite-2025/4469386
–
1) Intégration native Defender for Cloud + GitHub Advanced Security : de la vulnérabilité au correctif, avec contexte “runtime”
Annonce Ignite 2025 :
Microsoft annonce une intégration native entre Defender for Cloud et GitHub Advanced Security (GHAS), en public preview.
L’objectif : casser le silo classique “outils sécurité” vs “outils dev”, en injectant le contexte d’exécution (runtime) dans les workflows GitHub, pour prioriser ce qui est réellement exploitable en production.
Microsoft met aussi en avant des capacités d’assistance IA à la remédiation, notamment via Copilot Autofix et les capacités d’agent de codage GitHub Copilot, afin d’accélérer les corrections.
Ce que Microsoft précise ailleurs (blogs / doc)
Dans la documentation Microsoft Learn, l’intégration est décrite comme une connexion “code ↔ workloads” qui :
- mappe automatiquement les dépôts aux workloads déployés,
- priorise les alertes GHAS selon le contexte runtime (exposition Internet, données sensibles, ressources critiques, chemins de mouvement latéral),
- facilite une remédiation coordonnée entre sécurité et ingénierie
Point important : pour la version “preview” documentée, Microsoft indique que l’intégration native GHAS ↔ Defender for Cloud est supportée uniquement pour les workloads conteneurs.
Côté GitHub (source Microsoft), une publication “changelog” éclaire ce que le couplage apporte dans la pratique :
- des artifacts “linked” avec traçabilité (repo d’origine, registre, lieux de déploiement),
- l’ajout d’un contexte de risque runtime fourni nativement par Defender for Cloud (ex. “internet-exposed”, “sensitive-data”),
- des filtres “production-aware” dans GHAS (Code Scanning / Dependabot / campagnes) pour cibler les sujets réellement critiques. [github.blog]
Pourquoi ça compte (lecture technique)
Cette annonce vise à résoudre un vrai problème : les backlogs AppSec gonflent parce que tout n’a pas le même impact “prod”.
En reliant le signal runtime aux findings code scanning / dépendances / secrets, on peut basculer d’une logique “gravité CVE” à une logique “exploitabilité + exposition + criticité”.
–
2) Posture + protection “agentic AI” : Defender étend la sécurité aux agents IA via Microsoft Agent 365
Deuxième annonce : Microsoft étend l’approche “posture + threat protection” à la sécurité des agents IA.
Dans son article, Microsoft parle de capacités “first-of-its-kind” (en preview) intégrées à Microsoft Agent 365 :
- inventaire unifié des agents (pro-code et low-code),
- recommandations posture + attack path analysis appliquées aux agents,
- détections orientées IA (ex. prompt injection, exposition de données sensibles, mésusage d’outils), enrichies par la threat intelligence Microsoft.
Le texte cite explicitement une couverture allant de Microsoft Foundry à Copilot Studio, pour limiter le “shadow AI / agent sprawl” et sécuriser des agents qui se connectent à des ressources cloud et à des données sensibles
Ce que Microsoft précise ailleurs (blogs / doc)
Un autre article sur Microsoft Security : Start Secure and Stay Secure on your AI Agent Journey with Microsoft Defender | Microsoft Community Hub détaille la même annonce côté “Microsoft Defender” :
- inventaire risk-based des agents Foundry + Copilot Studio,
- consolidation de métadonnées (instructions, identités, outils connectés) pour reprendre le contrôle,
- AI security posture management pour les agents Foundry (preview) et threat protection pour les agents Copilot Studio (preview), avec d’autres éléments “à venir
La documentation Microsoft Learn sur Agent 365 explicite la logique “control plane” : Agent 365 fournit une gouvernance centralisée et s’intègre à la suite sécurité Microsoft “étendue aux agents” afin de gérer posture, politiques, investigations et remédiations sur l’ensemble du parc d’agents : Secure AI agents at scale using Microsoft Agent 365 | Microsoft Learn
Pourquoi ça compte (lecture technique)
On voit émerger un modèle de sécurité “identité + posture + détection” appliqué à des entités non humaines capables d’agir : En clair : on ne sécurise plus seulement une VM, un cluster ou une identité humaine, mais un acteur autonome relié à des outils et des données.
–
3) Extension CSPM aux environnements serverless : Azure Functions, Web Apps et AWS Lambda entrent dans l’Attack Path Analysis
Troisième annonce : Defender for Cloud étend sa Cloud Security Posture Management (CSPM) aux ressources serverless et plateformes applicatives : Microsoft cite explicitement une couverture incluant Azure Functions, Azure Web Apps et AWS Lambda, avec intégration des signaux serverless dans l’attack path analysis afin de mieux visualiser les risques et les mauvaises configurations dans des architectures évènementielles.
Ce que Microsoft précise ailleurs (blogs / doc)
Dans la doc Microsoft Learn (FR), Qu’est-ce que la protection serverless ? – Microsoft Defender for Cloud | Microsoft Learn “Protection serverless” est décrite comme une capacité du plan Defender CSPM qui :
- découvre et inventorie automatiquement les ressources serverless (Web Apps, Azure Functions, AWS Lambda),
- identifie mauvaises configurations, vulnérabilités et dépendances non sécurisées,
- propose des conseils de correction et une évaluation continue,
- et intègre l’analyse du chemin d’attaque pour cartographier des chaînes potentielles impliquant le serverless.
Pourquoi ça compte (lecture technique)
Le serverless est souvent difficile à gouverner “à la même vitesse que la prod” : ressources éphémères, explosion du nombre de fonctions, permissions et endpoints parfois exposés par défaut. En l’intégrant à une logique inventaire + posture + attack path, Defender for Cloud pousse une approche “pré-breach” plus cohérente sur ces briques applicatives.
–
4) Defender for Cloud dans le portail Microsoft Defender : vers un hub unique pour posture + protection multicloud
Dernière annonce : Microsoft lance la public preview de l’intégration “cloud posture management” dans le Microsoft Defender portal.
- un Cloud Security dashboard unifiant posture et threat protection,
- l’intégration posture au sein d’Exposure Management (assets, vulnérabilités, attack paths, secure scores, recommandations),
- un inventaire d’actifs centralisé couvrant Azure / AWS / GCP,
- et un RBAC granulaire pour réduire le risque opérationnel en multicloud.
Ce que Microsoft précise ailleurs (blogs / doc)
Un billet dédié “Breaking down security silos” décrit la même intégration comme un moyen de réduire la fragmentation, avec :
- une vue unifiée posture/couverture/tendances,
- des recommandations priorisées “risk-based”,
- l’attack path analysis “across all Defenders”,
- un inventaire cloud unifié et des concepts de “cloud scopes & unified RBAC”.
La documentation Microsoft Learn Overview of Defender for Cloud in Defender portal | Microsoft Learn précise le positionnement : Defender for Cloud est intégré dans le portail Defender (security.microsoft.com) et, dans une première phase, le parcours d’onboarding et la configuration démarrent encore dans le portail Azure, puis la consommation et l’opérationnel se font dans Defender
Enfin, Microsoft documente la manière d’activer les fonctionnalités de preview dans le portail Defender (avec prérequis de rôles Entra ID et au moins un plan payant Defender for Cloud), ce qui montre que cette intégration est pensée pour cohabiter avec le portail Azure pendant la transition.
Pourquoi ça compte (lecture technique)
Pour les équipes SOC et sécurité cloud, c’est un pivot d’expérience : la posture cloud devient un signal de première classe au même endroit que les incidents XDR, l’exposition et l’investigation.
C’est aussi cohérent avec la trajectoire “unified SecOps” où Microsoft rassemble progressivement SIEM/XDR/CNAPP dans un même cockpit
–
Synthèse : Si on prend du recul, Ignite 2025 aligne Defender for Cloud sur quatre axes forts :
- DevSecOps pragmatique : prioriser et corriger plus vite grâce au contexte runtime dans GitHub.
- Sécurité des agents IA : inventaire, posture et détection adaptés à des systèmes autonomes.
- CSPM qui couvre les nouveaux patterns : le serverless devient visible et analysable dans les chemins d’attaque.
- Unification opérationnelle : posture cloud et signaux XDR dans un hub Defender unique.