Microsoft Defender for Cloud Blog articles

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Mon, 03 Aug 2026 18:50:45 GMT

*This will be the last monthly MDC newsletter. To keep up with the latest, please visit: What's new in MDC

What's new in Defender for Cloud?

Multiple container security features are now Generally Available: Container-level misconfiguration recommendations for Kubernetes, Upgrade AKS version recommendations, VA for runtime-discovered container images on EKS and GKE, Kubernetes notes VA for EKS and GKE, scanning support for Docker hardened container images. For more information, see this page here.

Database-level recommendations for SQL VA now GA

The SQL vulnerability assessment recommendations created as part of the transition from grouped to individual recommendations are now generally available. Each SQL vulnerability assessment rule is surfaced as its own recommendation, reported directly on the affected SQL database resource.

For more details, please refer to this documentation .

Blogs of the month

In July, our team published the following blog posts we would like to share:

1. Built to Protect: The Architecture Behind Codename MDASH

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring NTT Data. NTT Data, a top global IT services provider, leverages Azure, OpenAI and Microsoft Defender to launch their AI agents, adopting secure by design principles, to help enhance, competitiveness organization change and data usage. Defender for AI, and Defender CSPM, as part of the Defender family, address the emerging risks and threats like prompt injection and data poisoning that come with generative AI.

Join our community!

We offer several customer connection programs within our private communities. By signing up, you can help us shape our products through activities such as reviewing product roadmaps, participating in co-design, previewing features, and staying up-to-date with announcements. Sign up at aka.ms/JoinCCP.

We greatly value your input on the types of content that enhance your understanding of our security products. Your insights are crucial in guiding the development of our future public content. We aim to deliver material that not only educates but also resonates with your daily security challenges. Whether it’s through in-depth live webinars, real-world case studies, comprehensive best practice guides through blogs, or the latest product updates, we want to ensure our content meets your needs. Please submit your feedback on which of these formats do you find most beneficial and are there any specific topics you’re interested in https://aka.ms/PublicContentFeedback.

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Built to Protect: The Architecture Behind Codename MDASH

JasonWeber — Thu, 30 Jul 2026 18:45:00 GMT

Information Table

Defender Foundations	Regional Operation	AI & Data Containment	Responsible Governance
Built as a production Microsoft Security service, not an isolated research system.	Operates alongside Microsoft Defender in the clouds and regions customers already use.	Designed to keep source, findings, and security data inside controlled boundaries.	Security, privacy, compliance, responsible AI, and operational readiness.

A new class of AI security needs a new level of trust

When Microsoft introduced Codename MDASH, we shared a major step forward in AI-powered vulnerability discovery: a multi-model, agentic scanning system that helps customers discover, validate, and reason about exploitable vulnerabilities across software applications. MDASH brings together specialized agents, multiple models, domain-specific analysis, debate, and proof construction to move beyond theoretical alerts and toward findings that customers can remediate and act on.

That capability matters because the software landscape is changing quickly. AI is accelerating how code is written, how systems are analyzed, and how vulnerabilities are discovered. The same advances that help defenders find critical weaknesses earlier can also lower the barrier for attackers and make sophisticated vulnerability research more accessible. In that environment, customers need more than powerful AI. They need powerful AI delivered inside a trusted security architecture.

That is the design behind MDASH. The product is not simply the model and harness. The product is the comprehensive security system that surrounds them: the controls, isolation boundaries, operational practices, governance, and compliance posture that allow customers to benefit from frontier AI and advanced vulnerability discovery without compromising control, and leveraging the discoveries inside Microsoft Defender.

Built as a production Microsoft Defender service

MDASH was built from the beginning as a production Microsoft Security service. It was not designed as a standalone experiment, a separate research environment, or a disconnected security tool. It was designed to operate with the same security, governance, privacy, and operational foundations customers expect from Microsoft Defender XDR and Microsoft Sentinel.

That distinction is important. Security products operate on some of the most sensitive information an organization has: source code, vulnerability findings, exploitability analysis, threat intelligence, identity signals, runtime exposure, security incidents, and remediation workflows. Customers should not have to move that data into a new trust model simply to benefit from AI. MDASH is designed to bring AI-powered vulnerability discovery into the trusted Microsoft Defender ecosystem instead.

By operating as part of Microsoft Security, MDASH benefits from Defender class operational discipline including identity and access control, service-to-service authorization, logging and auditability, security review gates, compliance alignment, privacy review, responsible AI review, and production operations. The goal is for customers to experience MDASH as an extension of the Microsoft security platform they already trust, not as a separate AI system they need to evaluate from first principles.

Operating globally where Microsoft Defender operates

Security decisions today are increasingly evaluated alongside data governance, regulatory, and operational requirements. Customers want to know where their data is stored, which services process it, who can access it, and how operational access is governed. These requirements are especially important for AI security systems because the data being analyzed may include proprietary source code, high-severity vulnerabilities, unreleased security findings, and sensitive threat context.

MDASH was designed with that reality in mind. It operates alongside Microsoft Defender in the clouds and regions where Defender operates, allowing customers to benefit from regional deployment models, data residency commitments, sovereign cloud investments, customer governance capabilities, and Microsoft’s broader compliance commitments. The architecture is designed so that vulnerability discovery does not become a reason for customers to move sensitive security data outside the boundaries they rely on today. MDASH integrates with Microsoft Foundry for AI inference. Data processed through Foundry remains subject to the applicable Foundry data handling and compliance commitments.

When customers use MDASH to analyze their code, the resulting security context is kept within the customer’s broader Defender security data. Findings, repository metadata, scan artifacts, vulnerability analysis, and security intelligence are treated as part of the customer’s Defender security context. That enables a unified experience while preserving the controls customers require.

Designed so data stays secure

The most important architectural principle behind MDASH is containment. AI systems that work with security data must be treated differently from general-purpose productivity systems. A vulnerability report can be a roadmap for an attacker. Source code can contain intellectual property and secrets. Threat intelligence can reveal what defenders know and how they detect adversaries. Customer security posture data can expose where an organization is weak.

MDASH was built around the principle that the AI should operate like a highly privileged security researcher inside a controlled Microsoft Security environment: powerful enough to do useful work, but isolated, monitored, constrained, and governed so that customer data cannot escape the trusted boundary.

Customer repositories are processed in isolated sandbox environments with dedicated execution boundaries. Scans are separated to prevent persistence, cross-tenant access, or interference between workloads. Agents are provisioned for the job, execute within constrained conditions, and are cleaned up when the work is complete. The architecture is designed to reduce the lifetime of sensitive data and require a minimum scope to perform the analysis.

Intelligence belongs to the organization

Security data is valuable, but so is the intelligence generated while analyzing it. MDASH was built around the principle that AI should help organizations leverage intelligence without requiring them to surrender it. The goal is to ensure that organizations can benefit from advanced AI capabilities without introducing new risks to their intellectual property, operational knowledge, or security practices.

MDASH is designed so that context remains local to the customer's tenant. Intelligence generated during scanning and investigation is not treated as exhaust to be harvested, but as an asset that belongs to the organization. This architectural approach helps organizations adopt AI while maintaining ownership of their security expertise, preserving competitive advantage, and ensuring that the value created through their interactions remains inside the trusted boundary where it was generated.

Secure isolation as a first-class control

Network behavior is one of the most important risk areas for any AI harness. Many open-source and experimental harnesses assume broad network access. Agents may call external websites, package registries, public APIs, malware analysis services, paste sites, or search engines as part of their workflow. For defensive security workloads, that model presents risks. It can create paths for source code, findings, prompts, exploit details, or threat intelligence to leave the environment.

MDASH was designed differently. Critical services are placed behind private networking boundaries. Communications occur through controlled service paths. Ingress and egress are restricted, monitored, authorized, and validated. Service-to-service communication is explicit. External communication is controlled.

Similarly, the environment is closed to new code and dependencies. The AI cannot download tools, install packages, import attacker frameworks, or otherwise expand at runtime. By preventing the introduction of untrusted software, we eliminate one of the most common patterns seen in AI escape and control-bypass research, where a model gains access to new tooling that enables actions beyond its intended boundaries.

This matters for both sides of the trust boundary. Customers need confidence that their source code, vulnerability findings, and security data are not exfiltrated to unauthorized destinations. Microsoft also needs confidence that its own threat intelligence, security research, and detection context can be used to improve analysis without leaking outside the protected environment. Isolation is a core product promise.

Tenant isolation, identity, and authorization

MDASH is designed for multi-tenant enterprise use, and tenant isolation is one of the most heavily scrutinized parts of the architecture. The platform is built around the principle that one customer’s code, findings, scan history, telemetry, or generated security intelligence must never become visible to another customer.

That principle is enforced through multiple layers including identity validation, tenant-aware authorization, role-based permissions, service-to-service authentication, storage isolation, queue isolation, telemetry separation, and audit logging. No single control is expected to carry the entire security model. Instead, the architecture layers controls so that customer data remains separated across the API, processing, storage, telemetry, and operational planes.

For customers, the practical outcome is straightforward. MDASH can operate on highly sensitive source code and security findings while preserving the same separation, access discipline, and audit expectations customers require from Microsoft Defender.

Encryption, retention, and data protection

Customer source code repositories and findings are protected through encryption in transit and at rest. Secrets are handled through enterprise secret management systems. Access to customer data is governed through authorization controls and operational processes. The platform is designed to keep sensitive data scoped to the operation being performed and retained only as long as necessary to provide the service.

Data minimization is especially important for AI security systems. The goal is not to accumulate customer code or retain vulnerability artifacts indefinitely. The goal is to perform the analysis, generate the security value, connect the finding to Defender context, and preserve only what is needed for the customer’s security workflow, auditability, and remediation experience.

This is also why MDASH is designed around a clear separation between customer data and model improvement. Customers need confidence that their proprietary code, vulnerabilities, and security findings are not being used in ways they did not authorize. Trust requires clear boundaries.

Responsible AI, security review, and operational governance

Responsible AI is not a separate layer added at the end of a security product. For MDASH, it is part of the engineering model. The system is powerful precisely because it can reason about exploitable vulnerabilities; that same power requires careful governance, human oversight, transparency, and operational controls.

MDASH has been developed with extensive review across security, privacy, compliance, Responsible AI, architecture, authorization, tenant isolation, penetration testing, and operational readiness. These reviews are not ceremonial. They are how Microsoft ensures that advanced AI capabilities are introduced with the discipline customers expect from enterprise security products.

The objective is not only to build an AI system that can find vulnerabilities. The objective is to build a trustworthy security service that customers can deploy in regulated, sensitive, and globally distributed environments. That is the standard Microsoft believes this category requires.

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 02 Jul 2026 18:11:31 GMT

What's new in Defender for Cloud?

Microsoft Defender for Open-Source Relational Databases is now generally available for Amazon Web Services Relational Database Service (AWS RDS) instances. Receive database threat protection and sensitive data discovery insights for supported open-source relational databases, including Aurora PostgreSQL, Aurora MySQL, PostgreSQL, MySQL, and MariaDB on AWS RDS.

For more information, see our public documentation.

Expanded multicloud security coverage now GA

Microsoft Defender for Cloud's expanded multicloud security coverage is now generally available. This release significantly broadens posture assessment for AWS and GCP environments, adding support for about 90 new resource types and over 200 new security recommendations across data, identity and access, networking, compute, and container categories.

For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blogs of the month

In June, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Watch the latest Defender for Cloud in the Field YouTube episode here:

GitHub Community

Check out Defender for Cloud GitHub lab module 25. It walks through the integration between Defender for Cloud and XDR to provide a comprehensive CDR solution.

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Hassan Allam Holding. Hassan Allam Holding is an Egyptian private-sector company with operations spanning engineering, construction, and infrastructure investment and was facing operational complexity. To overcome, they leveraged an end-to-end Microsoft Security ecosystem with Defender XDR, which integrates with Defender for Cloud and other products to centralize detection and signals across endpoint, identity, email and cloud workloads. As a result, alert noise reduce by up to 90%, and Hassan Allam Holding is able to respond faster with far less complexity.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Now generally available: Serverless posture coverage in Microsoft Defender CSPM

donnalee — Wed, 01 Jul 2026 16:00:48 GMT

Serverless workloads are a foundation of modern application development, powering everything from low-code and no-code solutions to AI applications and agentic workflows. Development teams use functions, app services, containers, APIs, and event-driven infrastructure to move quickly, scale on demand, and reduce operational overhead. As AI applications and autonomous workflows increasingly rely on distributed services, background tasks, retrieval pipelines, and event-driven components, serverless architectures have become a natural fit.

At the same time, they introduce new visibility and posture management challenges. While cloud providers manage the underlying infrastructure, organizations remain responsible for securing their applications, including code, container images, dependencies, configurations, identities, permissions, and access paths.

Today, we're announcing the general availability of Serverless Container posture in Microsoft Defender Cloud Security Posture Management (Defender CSPM). Building on the recent general availability of Serverless Compute posture in Defender CSPM, these capabilities extend agentless posture coverage across supported serverless containers, applications, and functions in Azure and AWS.

With this expanded serverless posture coverage, security teams can:

Discover serverless workloads as first-class assets in a unified cloud inventory

Assess workload-specific vulnerabilities, insecure dependencies, and risky configurations

Surface exposure, identity, permission, and configuration context that helps prioritize contextual attack paths to broader applications

Prioritize risk using security graph context and attack path analysis

Act on severity-ranked recommendations in Defender for Cloud

Serverless posture coverage across containers, apps, and functions

Defender CSPM extends posture management across supported serverless workloads in Azure and AWS.

Category	Covered workloads
Serverless applications and functions	Azure Functions, Azure Web Apps, AWS Lambda
Serverless containers	Azure Container Apps, Azure Container Instances, AWS ECS on Fargate

These resources are automatically discovered and surfaced in Defender cloud inventory, helping security teams maintain visibility across dynamic, event-driven application environments.

Across supported serverless workloads, multiple layers of posture assessment are provided:

Inventory: Serverless compute and container workloads are automatically discovered and mapped with key properties, helping teams understand what is running across their environment.

Misconfiguration assessment: identify risky settings such as internet exposure, missing HTTPS, and other configuration issues that can increase exposure.

Vulnerability management: Vulnerabilities are detected across supported serverless workloads and tracked over time, helping teams understand where exposed workloads may also contain known CVEs.

Attack path analysis: Serverless resources are connected into the Security Graph, so teams can understand how a compromised function or container could reach sensitive assets.

Actionable recommendations: Findings are surfaced as resource-level recommendations, making it easier to assign ownership, remediate, and track progress.

Secure Score impact: Serverless findings contribute to the broader Secure Score, so risk reduction is reflected in the organization’s overall posture.

These findings are incorporated into Security Graph and attack path analysis, helping security teams understand risk in context and prioritize remediation based on how serverless workloads connect to other resources across the cloud environment.

In practice

Exposed function with access to sensitive data: A serverless function may look like a simple HTTP endpoint, but if it is internet-facing, running with broad identity permissions, and connected to sensitive storage, it can become part of a real attack path. Defender CSPM helps connect these signals across exposure, vulnerabilities, identity, and data access so teams can prioritize the workload based on actual risk, not just isolated findings.

Serverless container running a vulnerable image: A serverless container running on Azure Container Apps, Azure Container Instances, or Amazon ECS on AWS Fargate may be fully managed at the infrastructure layer, but the customer still owns the image, application code, identity, configuration, and exposure. If that workload is internet-facing, built from an image with a critical CVE, and connected to Key Vault, storage, or other sensitive services, Defender CSPM helps teams discover it, assess the risk, and prioritize remediation in context.

One consistent Defender experience

Defender CSPM now natively includes serverless posture coverage. Discovered functions, web apps, and serverless containers appear in the unified cloud inventory, are evaluated through security recommendations, integrate into attack path analysis, and are queryable through Cloud Security Explorer.

This consistency matters because serverless workloads rarely operate in isolation. A function might call an API, read from a queue, authenticate with a managed identity, and write to storage. A serverless container might expose an endpoint, pull an image from a registry, process events, and connect to secrets or databases.

Defender CSPM helps security teams evaluate these workloads with surrounding context, including exposure, vulnerabilities, identity permissions, configuration risk, and relationships to other resources. That context helps teams move from isolated findings to prioritized remediation.

Built for modern and AI-ready applications

As organizations build AI-powered applications, agentic workflows, and distributed cloud services, serverless infrastructure continues to play a growing role in delivering scalability and operational efficiency.

Defender CSPM helps security teams gain visibility into supported serverless containers, applications, and functions, assess vulnerabilities and misconfigurations, and prioritize remediation using Security Graph context and attack path analysis. By bringing serverless workloads into inventory, recommendations, Cloud Security Explorer, and attack path analysis experiences, Defender CSPM helps organizations better understand and reduce risk across their cloud environments.

Explore the documentation for serverless protection and posture for serverless container workloads, and discover the latest innovations in Microsoft Defender for Cloud in the release notes.

Microsoft Defender for Cloud expands multicloud coverage across AWS and Google Cloud

donnalee — Tue, 30 Jun 2026 17:36:56 GMT

Organizations are building and running applications across multiple cloud platforms and hybrid environments to move faster, improve resilience, and choose the services that best fit each workload. But that flexibility also changes how teams need to manage exposure. A risk may start with an internet-facing resource, an over-permissive identity, a misconfigured managed service, a vulnerable container image, or a serverless workload with access to sensitive data. When those signals are spread across multiple cloud providers and tools, it becomes harder to understand how exposure is created and which actions will reduce risk fastest.

Today, Microsoft is expanding multicloud coverage in Microsoft Defender for Cloud with general availability of approximately 90 new AWS and Google Cloud resource types and more than 200 recommendations. Building on recent enhancements in CIEM, identity security, containers, and serverless workloads, this expansion helps customers evaluate more of their cloud estate through a unified security experience.

With broader coverage across cloud-native applications, data platforms, identity services, networking components, and managed services, security teams can move beyond isolated findings and gain more context across resources, configurations, identities, exposure signals, and prioritization.

What’s new: broader AWS and Google Cloud coverage

Security teams cannot reduce exposure they cannot see. The expanded coverage brings more AWS and Google Cloud resources into the Defender for Cloud experience, helping customers assess a wider set of modern cloud services through a unified security lens, reducing blind spots where teams increasingly build and operate: serverless applications, containers and build systems, identity and entitlement controls, data and analytics services, AI and ML, networking, messaging, storage, and other managed cloud services.

App, platform, and serverless services, including Cloud Run and EventBridge, to help teams identify exposure in cloud-native applications and event-driven workloads.

Containers, registries, and build systems, including Artifact Registry and CodePipeline, to connect software supply chain posture with workload risk.

Identity, data, and managed services, including Cognito and BigQuery, to help teams understand how access, data, and platform configurations can increase exposure.

Multicloud compliance and data protection controls, improving visibility into encryption, logging, backup, auditability, and resilience scenarios.

This broader view helps customers understand their real exposure surface and act on recommendations tied to the scenarios that matter most. Find the full list of recommendations here.

See exposure in context

Exposure is rarely created by a single finding. Consider a security team managing applications across AWS and Google Cloud. A publicly accessible BigQuery dataset, a cloud-native application running in Cloud Run, and an over-permissioned identity may each generate separate findings. Viewed independently, these issues can appear as routine posture alerts; together, they reveal a higher-risk exposure scenario that could lead to unauthorized access to sensitive data. More AWS and Google Cloud resources can now be assessed in the same security experience, helping teams move beyond isolated findings and toward a clearer understanding of potential exposure and remediation priority.

Why this matters

For most security teams, the bigger challenge isn't generating more findings, it's prioritizing the ones that matter most. By bringing more AWS and Google Cloud resources into inventory, evaluating them with recommendations, and correlating them with identity context, exposure signals, regulatory compliance results, Secure Score insights, and business criticality, Defender for Cloud helps teams focus on the exposures most likely to impact their organization, without adding another fragmented tool to the stack. As coverage expands, teams can answer practical questions across a broader part of their environment:

Which AWS and Google Cloud services are now visible in my cloud inventory?

Which newly evaluated resources have recommendations that should be reviewed?

Which findings are tied to exposed, high-value, or security-sensitive resources?

Where should my team prioritize remediation based on exposure, not just finding volume?

Building on recent multicloud investments

This release builds on a series of multicloud investments in Defender for Cloud over the past several months that bring deeper, more consistent protection across multicloud environments.

CIEM and identity: Identity is one of the most common entry points for cloud exposure. Defender for Cloud evaluates overprovisioned identities, risky permissions, weak authentication, and privilege-escalation paths. Modernized CIEM logic now assesses identity risk based on actual entitlement usage rather than sign-in activity, using a 90-day lookback. Customers benefit from improved accuracy using log ingestion from AWS CloudTrail and Google Cloud Logging, and drive actionable recommendations. Learn more about permissions management.

Containers and serverless: In containers and serverless, Microsoft expanded multicloud posture coverage across serverless compute, serverless containers, and modern Kubernetes environments. This expansion brings more cloud-native workloads into a unified code-to-runtime security model with vulnerability assessment, misconfiguration analysis, container-level recommendations, and a richer exposure context. Last month we introduced general availability of serverless compute posture coverage for AWS Lambda, Azure Functions, and Azure Web Apps, and the public preview of serverless container posture coverage for Azure Container Apps, Azure Container Instances, and Amazon ECS on AWS Fargate. Learn more about the latest in container security, and find documentation about serverless protection and serverless containers posture protection.

Together, these investments give security teams a more complete view of exposure across Azure, AWS, and Google Cloud.

Built into the Microsoft Security experience

The expanded AWS and Google Cloud coverage strengthens the foundation for multicloud exposure management in Defender for Cloud. Customers can use the same experience they already rely on to understand inventory, posture, serverless and container risk, CIEM and identity context, compliance, Secure Score, and risk prioritization across more of their cloud estate.

Because exposure is shaped by relationships across resources, identities, entitlements, workloads, configurations, controls, and reachable services, a more complete multicloud view helps security teams understand risk and act with greater confidence. For customers standardizing on Microsoft Security, this means broader multicloud exposure management in one place – without adding another fragmented tool to the stack.

Get started

Customers can begin reviewing the expanded coverage by exploring Cloud Inventory, filtering by cloud provider and resource category, reviewing newly introduced recommendations, and monitoring Secure Score changes as broader assessment becomes available.

We recommend that security teams:

Use Cloud Inventory to understand which additional AWS and Google Cloud resource types are now represented in Defender for Cloud.

Review new recommendations across key workload, identity, compliance, data protection, and networking.

Reassess top exposure scenarios across clouds, including serverless, containers, identity, data, and managed services.

Prioritize remediation based on exposure, criticality, and business context, not only recommendation volume.

Learn more

With expanded AWS and Google Cloud coverage, Microsoft Defender for Cloud helps security teams improve multicloud visibility, assess more resources, and prioritize exposure across their cloud estate.

To learn more, visit the Microsoft Defender for Cloud documentation, review the latest release notes, and follow the Microsoft Defender for Cloud Tech Community blog for updates on cloud security and posture management.

Closing the loop on container security: From code to runtime in the AI era

mahersko — Tue, 16 Jun 2026 23:15:21 GMT

Containers are the backbone of modern cloud-native apps — and increasingly, the infrastructure powering AI, from AI assistants to a new wave of intelligent agents. They also blur the line between build, deploy, and runtime: a single code change can become a running workload in minutes. A misconfiguration committed in the morning can be deployed in minutes and exploited before noon. At that speed, container security can no longer be a point-in-time check, it has to work as one continuous loop.

The numbers back this up. For the first time, 31% of breaches now begin with an attacker exploiting a software vulnerability — overtaking stolen credentials as the most common way in — and 15% of attack techniques are now accelerated by generative AI, with adversaries using it to find gaps and write malware faster at every stage.

Source: Verizon 2026 Data Breach Investigations Report (incidents Nov 2024–Oct 2025).

Over the last few quarters, Microsoft Defender for Cloud has been evolving to offer you this continuous security, end to end. Explore container security’s new capabilities across posture, shift-left, runtime, multicloud coverage, and operations. Collectively they form a more comprehensive approach to container security — one that offers security right during developing a code to a running pod across Azure, AWS, and GCP.

There is a second reason why container security matters more in 2026: containers are increasingly where AI runs. Many AI workloads — from model-serving APIs to retrieval systems and intelligent agents — now live as pods on AKS, EKS, and GKE (the managed Kubernetes services from Azure, AWS, and Google), often connected to some of an organization’s most sensitive models and data. As those crown jewels move into the cluster, the same posture, code‑to‑runtime, and runtime protections described in this post extend to AI workloads. The contest is increasingly AI against AI: attackers use it to find and reach the cluster faster, while defenders use it to push back — surfacing the risks that matter most and turning runtime findings into AI‑assisted code fixes.

One platform, code to runtime

A container finding is not treated as an isolated issue; it is connected to the identity it runs under, the registry and code repository it came from, and the cluster where it is running - all unified under one Microsoft Defender platform.

Container posture and shift-left security are now redesigned for least vulnerabilities in production

Conventional container security posture offered challenges to scale: a single grouped recommendation could stack thousands of findings under one bucket, making ownership, exemptions, and risk scoring too coarse to act on. That experience is now evolved. We have rebuilt the experience so that each finding is its own recommendation — per software, per image, per container. If two CVEs in the same image belong to two different teams, they can now be triaged, exempted, and reported separately. The grouped recommendations are deprecated and will be removed on July 30, 2026, We suggest updating any automation, export rules, and ServiceNow integrations to target the new per-finding recommendations before that date.

That per-finding precision becomes even more powerful once you connect each finding to its source code and to the runtime resources it impacts. Defender for Cloud — part of Microsoft Defender suite — connects this code-to-runtime chain end-to-end. For example, an image built through Azure DevOps or GitHub, pushed to ACR, ECR, Google Artifact Registry, Docker Hub, or JFrog, and pulled by AKS, EKS, or GKE is one continuous evidence chain — traceable from a running container back to the pull request (PR) and line of code that introduced the risk. With GitHub Advanced Security integrated (GA), secrets, code, and dependency findings join the same attack story. The developer-first Defender for Cloud CLI runs the same scanner locally or in any CI/CD pipeline, with consistent exit codes for gating.

The Code-to-Runtime “Development phases” diagram: one continuous Code → Build → Ship → Runtime evidence chain, with a one-click path to open a GitHub issue.

In this diagram, you can see how we have embedded container security at every stage of the software development lifecycle (SDLC), not just the endpoints. At Code, GitHub Advanced Security and the Defender for Cloud CLI catch secrets, vulnerable dependencies, and insecure code before commit. At Build, the same scanner runs as a CI/CD gate — in GitHub Actions, Azure DevOps, Jenkins, or Bitbucket — failing the pipeline on critical findings. At Ship, registry scanning and Gated Deployment block risky or misconfigured images at the cluster door. And at Runtime, the sensor enforces anti-malware and binary-drift policy on the live workload. No stage is left as a blind spot, and a finding can be traced forward to the running pod or backward to the developer who introduced it.

Visibility without enforcement only creates backlog. Gated Deployment — a Kubernetes admission controller — uses the same vulnerability signal, you trust, to block risky images at the cluster level. It supports phased rollout (audit, then deny), targets rules by cluster, namespace, pod, image, or label, and runs across AKS (including AKS Automatic), EKS, and GKE. A newer extension gates on Kubernetes misconfigurations too. Posture practitioners also get KSPM at container granularity — Kubernetes security posture management, available through both Defender for Containers and Defender CSPM — and, on Azure, a new actionable recommendation, Upgrade Azure Kubernetes Service Version (preview), that helps you remediate vulnerabilities in AKS-managed system pods.

Misconfiguration gating rules in Defender for Cloud — block risky deployment before they reach production.

Coverage that matches containers’ evolution

Historically, many container security programs concentrated on managed Kubernetes clusters in AKS, EKS, and GKE. The 2026 reality is broader: a growing share of production runs on serverless container platforms that abstract the cluster away, many sensitive workloads sit behind private, network-isolated clusters, and platform teams increasingly standardize on hardened or distroless base images. The surfaces that were blind spots are now part of the same posture graph as everything else.

Serverless compute posture is now generally available across AWS Lambda, Azure Functions, and Web Apps, while Serverless containers posture (preview) takes the same idea to Azure Container Apps, ACI, and AWS Fargate. Together, they bring more of today’s cloud-native production footprint into the same posture graph.

Coverage also improves where platform teams are standardizing on locked-down environments. The long-standing gap around private EKS and GKE clusters is closed, bringing some of the hardest-to-reach environments into the same security model. Scanning now works on hardened images from Docker Hardened or Minimus, and runtime protection supports BottleRocket on EKS — with the full feature set also available in Azure Government, which matters for teams running regulated workloads.

Runtime threat protection that prevents, not just detects

Posture closes the door on attackers; runtime threat protection guards the room if they still succeed. The key shift is that the Defender for Containers sensor now adds prevention on top of detection. The goal is simple: stop malicious code before it runs. Anti-malware detection and prevention (GA) scans container workloads and Kubernetes nodes and, based on the policies you define, blocks malicious execution instead of only alerting. Those alerts then flow into Microsoft Defender XDR’s unified incident model.

The second is binary drift detection and prevention (preview). Containers are meant to be immutable. When a process starts from a binary that was not part of the original image, that is drift — and one of the highest-signal indicators of compromise in cloud-native workloads. Defender detects drifts and, with policy enabled, can now also block the drifted process before it executes.

Anti-malware and Drift policies can be scoped by cloud, cluster, namespace, image, or label, with allow-lists for legitimate cases.

Anti-malware policies can alert, block, or ignore — scoped to clusters, namespaces, pods, labels, or images.

Rounding out runtime protection, DNS-based threat detection (GA) catches command-and-control beaconing, DGA traffic, and exfiltration over DNS.

A unified approach to container security

Step back, and the bigger picture is simple. The same platform that secured your VMs and identities now extends across AKS, EKS, GKE, private clusters, serverless containers, and serverless compute. The same Code-to-Runtime chain that once tied Infrastructure as Code (IaC) findings to running infrastructure now connects Dockerfile commits — through CI/CD and any major registry — to the running pod. Admission control turns posture findings into prevention at deploy time, and runtime protection actively blocks. That is a continuous container security loop living inside Microsoft Defender — not a checklist bolted onto Kubernetes. And it rebalances the fight: as attackers use AI to find and exploit gaps faster, the durable answer is security teams using AI of their own — protecting and triaging at machine speed.

If you’ve already enabled container security with Microsoft, the clearest next step is to strengthen the core lifecycle stages first:

Code + build: connect GitHub Advanced Security and integrate the Defender for Cloud CLI into your pipelines so findings are caught early and CI/CD gates can fail builds before an image is pushed.
Ship: stand up Gated Deployment in audit mode on a non-production cluster, tune it, then flip to deny; extend it to Kubernetes misconfigurations.
Run: enable the Defender for Containers sensor, extend it to private EKS and GKE clusters, then tune anti-malware and binary-drift rules in Block mode — starting with your crown-jewel namespaces.
Extend protection: turn on serverless compute posture for Lambda, Functions, and Web Apps, and enable serverless container posture for Container Apps, ACI, or Fargate.

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 04 Jun 2026 18:30:12 GMT

What's new in Defender for Cloud?

Defender for Cloud is now integrated into the Defender portal to bring together cloud security posture management and threat protection in a single experience. Read more about it here.

Cloud security reporting in the Defender portal is now in public preview

Customers can now create, customize, and share security insights across the organization through Defender portal’s integrated cloud security reporting capabilities. With these reporting capabilities, customers can view built-in reports like CNAPP Executive Summary, create custom reports, export to PDF and more. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blog(s) of the month

In May, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Check out the two short videos on Defender Portal integration and Start Secure Stay Secure with Defender for Cloud

GitHub Community

Check out this PS script and CLI to help you enable Defender for API at scale:

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Loyens & Loeff, a law and tax firm, that operates in a high complex environment, sought to modernize the digital workplace with Microsoft 365 Copilot, Defender for Cloud and Purview.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

The end of patching era for containers: Microsoft Defender for Cloud expands hardened image support

Yulia_Zhurbinsky — Tue, 02 Jun 2026 22:53:19 GMT

Why hardened images are becoming the new baseline for container image security

Container security is evolving beyond vulnerability scanning alone. Across the ecosystem - spanning container platforms, registries, and software supply chain tooling - customers are increasingly adopting hardened container images - images that are minimal by design, transparent in composition, and continuously maintained to reduce inherited risk at the base layer.

This shift is happening against a backdrop of increasingly fast-moving attacks. AI-assisted techniques - such as those demonstrated by Mythos-class tooling - continue to compress the time between vulnerability discovery and exploitation. In this environment, reducing exposure to exploitable vulnerabilities and attack surfaces in container images before deployment is becoming just as critical as detecting vulnerabilities after the fact.

Traditional container images are optimized for flexibility and reuse, not for security - meaning they are not designed to minimize included components, reduce attack surface, or limit inherited vulnerabilities by default. As a result, many base images include large package sets and transitive dependencies that significantly increase attack surface and vulnerability noise.

Hardened images take a different approach:

Minimal by construction, including only what’s required to run the workload

Reduced attack surface, limiting exploitable components

Strong transparency, with SBOMs and provenance metadata

Continuous maintenance, so vulnerabilities are addressed through rebuilding rather than downstream patching

For customers, this represents a shift from reactive CVE triage to preventative risk reduction at the image layer.

In practice, this changes how container image risk is managed - from prioritizing and patching vulnerabilities in place to replacing images with updated, rebuilt versions, making remediation more predictable and easier to scale across environments.

As hardened images become more widely adopted, organizations still need to continuously assess these images for vulnerabilities and compliance, since minimal or frequently rebuilt images can still introduce new risks over time or differ from expected configurations - making continuous image scanning and monitoring essential.

Microsoft Defender for Cloud’s approach: support choice, centralize visibility

Today, Microsoft Defender for Cloud already supports vulnerability assessment for hardened image providers such as Chainguard, alongside traditional Linux distributions. We recently expanded this coverage further with additional hardened image types, giving customers more flexibility to adopt secure-by-default images while continuing to scan these images and manage findings in a centralized Microsoft Defender for Cloud experience.

Microsoft Defender for Cloud does not prescribe a single hardened image solution. Instead, it focuses on enabling customer choice while providing consistent, centralized vulnerability assessment and posture management.

This capability builds on the container vulnerability assessment foundation powered by Microsoft Defender for Endpoint and Microsoft Defender Vulnerability Management (MDVM), bringing together high-fidelity vulnerability insights across the container lifecycle with support for modern, hardened image models.

From now on, Microsoft Defender for Cloud’s vulnerability assessment supports hardened image ecosystems including:

Chainguard images, rebuilt from source and designed to minimize inherited vulnerabilities

Minimus images, which are minimal and continuously rebuilt to ship with zero known CVEs at publish time

Docker Hardened Images (DHI), secure, minimal, production-ready base images maintained by Docker (recently added)

Photon OS-based images and other minimal operating system distributions

Across all of these, Microsoft Defender for Cloud’s experience remains consistent:

Images are scanned through the existing container vulnerability assessment pipeline

Findings surface in the same Azure and Defender portals

Policy evaluation, alerting, and compliance reporting stay centralized

Security teams do not need to onboard new scanners, manage separate dashboards, or maintain parallel remediation workflows. Hardened image adoption fits directly into existing Microsoft Defender for Cloud posture management.

What this means for customers

As hardened image adoption accelerates, Microsoft Defender for Cloud enables customers to adopt secure‑by‑default foundations without fragmenting their security posture.

The benefits are tangible:

Reduced vulnerability noise from inherited base‑image packages

Earlier risk reduction at the image layer

Consistent vulnerability assessment across hardened image providers

Centralized security posture, compliance, and reporting

Whether customers choose Chainguard, Minimus, Docker Hardened Images, Photon OS–based images, or a combination, Microsoft Defender for Cloud provides a single control plane for understanding and managing container image risk - without forcing a change in operational model.

How this works across hardened image providers

Microsoft Defender for Cloud supports multiple hardened image providers, enabling organizations to adopt secure‑by‑default container images while maintaining a consistent approach to vulnerability assessment and posture management.

While each provider takes a different approach to minimizing risk at the image layer, Microsoft Defender for Cloud ensures that all images are scanned through the same vulnerability assessment pipeline, with findings surfaced centrally for security teams to monitor, prioritize, and remediate.

Examples:

Minimus

Minimal, continuously rebuilt container images designed to ship with zero known CVEs at publish time. Microsoft Defender for Cloud enables native scanning of Minimus images stored in Azure Container Registry, allowing security teams to assess vulnerabilities and maintain centralized visibility without introducing new workflows.

Docker Hardened Images (DHI)

Production‑ready, minimal base images designed as drop‑in replacements for standard container images. By supporting DHI, Microsoft Defender for Cloud allows customers to adopt these hardened images while continuing to rely on the same vulnerability scanning, governance, and reporting capabilities.

Looking ahead

Hardened images are no longer niche - they are becoming a foundational element of modern container security. As attacker automation and AI‑assisted attack techniques continue to shorten response windows, reducing exposure at build and image layers becomes increasingly important.

Microsoft Defender for Cloud will continue expanding support for hardened and minimal image ecosystems, ensuring customers can evolve their image strategies without sacrificing visibility, control, or operational simplicity.

Security should start with what you build on - not with what you fix later.

Learn more: Scanning support for Docker Hardened container images

Start Secure, Stay Secure: How Microsoft is Closing the Gap from Code to Runtime

JasonWeber — Tue, 02 Jun 2026 21:22:01 GMT

Modern software applications composed of hundreds of artifacts, multiple programing languages, and cloud infrastructure provide an extensive attack surface that only continues to expand in the era of AI. According to Microsoft Threat Intelligence and industry research, threat actors are also increasingly leveraging AI-assisted techniques to accelerate vulnerability discovery and exploitation (Source: Digital Defense Report 2025). Rule-based scanning and manual review alone may not keep pace with the speed and scale of these emerging threats.

As AI-generated code grows exponentially, organizations need tools designed to apply security researcher-inspired techniques at scale, keeping pace with new development processes and a rising number of AI-powered threats. That is the challenge we set out to solve.

At Build 2026, we are taking two steps forward: the expanded preview of Codename MDASH, a multi-model agentic scanning system designed to find and validate exploitable vulnerabilities, and the general availability of the Microsoft Defender for Cloud and GitHub Code Security native integration, which connects runtime risk to code and bridges the gap between security and development teams in a single workflow.

Together, these announcements represent a shift in how organizations should address software security considerations across the development lifecycle, natively integrating into their existing tooling and work processes.

The Problem: Alert Fatigue, Disconnected Tools, and a Widening Gap

Industry data consistently shows that critical and high-severity vulnerabilities take an average of more than 100 days to remediate. Research suggests applications face attacks as frequently as once every three minutes (Source: Digital Defense Report 2025).

Security teams are overwhelmed with alerts they cannot easily prioritize and assign. Developers spend time investigating issues that may never be exploited in production. Both teams often rely on separate, non-integrated tools, making collaboration slower and more difficult. The result is a growing gap between how fast organizations ship code and how fast they can secure it.

The answer is not more alerts, but higher actionable findings, smarter triage, and workflows designed to support more efficient agentic remediation, fostering improved collaboration between security teams and developers.

Codename MDASH: Agentic Vulnerability Discovery (Expanded Preview)

Codename MDASH introduces a new approach to vulnerability discovery and validation. Built by Microsoft's Autonomous Code Security team, which includes members of the DARPA AI Cyber Challenge-winning Team Atlanta, codename MDASH orchestrates more than 100 specialized AI agents across an ensemble of frontier and distilled models to discover, debate, and validate exploitable security findings end to end.

Unlike single-model approaches, codename MDASH works as a coordinated system. Different agents scan code for potential vulnerabilities. A separate set of agents debate whether each finding is real and exploitable. A final set constructs proof-of-concept attacks to confirm the bugs exist. The goal is to deliver validated findings, like the test results listed below, intended to help teams focus on security issues that are more likely to be exploitable, rather than theoretical warnings.

Results from internal testing and the public CyberGym benchmark (developed by UC Berkeley researchers, covering 1,507 real-world vulnerability reproduction tasks across 188 open-source projects, as of May 2026):

16 New Vulnerabilities Discovered and Patched across the Windows networking and authentication stack, including four critical remote code execution flaws, all patched in the May 2026 Patch Tuesday release. (Source: MSRC CVE disclosures, May 12, 2026.)
MDASH identified all 21 planted vulnerabilities in a controlled test, with no false positives observed in that test. Results in broader production environments may vary. (Source: Microsoft Security Blog)
Near-Total Recall on Historical MSRC Cases 96% recall against five years of confirmed MSRC cases in clfs.sys and 100% recall in tcpip.sys. These are retrospective recall benchmarks on internal code with a finite case count; they indicate the system would have been useful had it existed at the time, but do not by themselves predict future performance. (Source: Microsoft Security Blog)
Codename MDASH recently jumped ~10% in less than three weeks to a new CyberGym industry benchmark score of 96.55%.

o CyberGym scores are self-reported by participating organizations; the benchmark code is public, but no independent party has verified any of the scores. Benchmark results do not necessarily reflect real-world performance across all environments. (Source: CyberGym public leaderboard, cybergym.ai)

What makes the architecture durable is its model-agnostic design. When a new model becomes available, the targeting, debating, deduplication, and proof stages do not need to be rewritten. That means every improvement in the underlying AI automatically makes your existing scans smarter, without requiring teams to rebuild context, retune plugins, or revalidate proving agents. The work you put in today keeps paying off tomorrow.

Codename MDASH will be in expanded preview at Build 2026. Please reach out to your Microsoft Account rep for more information.

Microsoft Defender for Cloud+GitHub Code Security: Now Generally Available

Codename MDASH brings a new class of multi-model agentic discovery to high-value targets. The Microsoft Defender for Cloud and GitHub Code Security native integration brings runtime context to vulnerability detections that developers already see in their pull requests, so both teams can prioritize what's exploitable and remediate inside the same workflow. This integration, now generally available, connects runtime context to code, so developer and security teams can prioritize and fix what matters.

Here is the core problem it solves: a vulnerability flagged in your codebase might look critical in isolation, but is it running in production? Is it internet-facing? Is it touching sensitive data? Those three questions should drive everything. Until now, getting those answers typically meant jumping between tools, chasing context, and hoping someone on the other team had the right information.

The integration changes that in three ways:

Real-time visibility across the app lifecycle so developer and security teams can collaborate in the tools they already use. Security teams can track the status of vulnerabilities detected by GitHub Code Security directly in Defender for Cloud. When remediation is needed, a security campaign alerts GitHub repository owners, and developers can open a GitHub issue straight from Defender for Cloud to track progress from fix to close.
Critical alert prioritization By connecting runtime context to code, developer teams will be able to prioritize exploitable issues. Security teams will be able to understand the traceability of the artifact from code to runtime and trace runtime threats directly to the code in GitHub. As a result, the most critical alerts will be fixed first.
Remediation time reduction AI-suggested fixes with Copilot Autofix and GitHub Copilot cloud agent will automatically be generated, making it faster for developers to help accelerate remediation.

Together, Defender and GitHub Code Security give security and engineering teams a shared, runtime-prioritized list of vulnerabilities, so the alerts developers see in their pull requests are the ones the security team has already confirmed are deployed, exposed, and worth fixing. Copilot Autofix turns those prioritized findings into review-ready pull requests, with developers in control of what merges. We believe this combination of runtime-to-code correlation and agentic AI remediation within a single integrated workflow is a meaningful differentiator. Check out our new onboarding videos to help you get started today.

How It All Fits Together: Code to Runtime

Codename MDASH and the Defender and GitHub Code Security integration are two parts of the same vision: enforcing security across the entire software lifecycle, from the first line of code to the running workload. By helping organizations find and fix vulnerabilities faster, development teams can help reduce time spent on security remediation and more time building new products.

At the code level, codename MDASH adds a new layer of multi-model agentic discovery focused on high-value targets like logic flaws, race conditions, and AI-specific risks such as prompt injection and insecure model endpoints. It complements the deep semantic analysis that GitHub Code Security already performs on every pull request with CodeQL. It validates findings using multiple AI models and aims to deliver proven results rather than theoretical warnings.

At the runtime level, Defender provides the context that turns a finding into an actionable priority: is this deployed, is it exposed, and does it matter right now? When a fix is needed, Copilot can assist with remediation, with the developer retaining control over what gets merged.

The developer stays in GitHub. The security team stays in Defender. Both can see how code problems become real security risks, and both can act on them with reduced context switching and fewer handoff delays.

Get Started

Microsoft Defender for Cloud + GitHub Advanced Security is now generally available. Set up the integration in the Defender for Cloud portal and connect your GitHub organization. [learn.microsoft.com]
Check out our new onboarding videos here: https://aka.ms/DefenderGHCSOnboardingVideos
Codename MDASH expanded preview launches at Build 2026.
Read the full technical deep dive: Defense at AI speed: Microsoft's new multi-model agentic security system tops leading industry benchmark.
Read the full Microsoft Security Build update: https://aka.ms/BUILD_SecurityBlog

With AI-powered vulnerability discovery, runtime-to-code context, and AI-assisted remediation built into the developer workflow, these tools are designed to help teams move faster while maintaining a strong security posture

Sources:

Microsoft Digital Defense Report 2025, MSRC Patch Tuesday trend data, industry publications on AI-assisted exploit development. Digital Defense Report 2025: https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2025
Microsoft Security Response Center (MSRC), "Security Update Guide — May 2026 Release Notes," May 12, 2026. https://msrc.microsoft.com/update-guide/releaseNote/2026-May
Microsoft Security Blog, "Defense at AI Speed: Microsoft's New Multi-Model Agentic Security System Tops Leading Industry Benchmark," May 12, 2026. https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/
GitHub and Microsoft internal analysis of enterprise security backlogs. See the Microsoft Defender for Cloud blog (aka.ms/SecureCodetoCloudBlog) for methodology.

Now Generally Available: Microsoft Defender for open source relational databases on AWS RDS

lisetteranga — Mon, 01 Jun 2026 17:11:16 GMT

Securing multicloud databases to help reduce risks

Open‑source (OSS) relational databases are becoming increasingly critical and increasingly targeted in organization of all sizes. As organizations adopt multicloud architectures, these databases often run across Azure and Amazon Web Services (AWS), while security tools remain fragmented. The result is inconsistent visibility into sensitive data, disconnected alerts, and limited insight into how database exposure translates into real risk.

Today, Microsoft announces the general availability (GA) of Microsoft Defender for open‑source relational databases with support for Amazon Relational Database Service (AWS RDS). Customers can gain visibility into potentially sensitive data, identify indicators of database threats, and support risk prioritization across Azure and AWS through a unified experience in Microsoft Defender for Cloud, with capabilities that continue to expand across environments.

This GA release highlights Microsoft’s existing protection for open‑source relational databases in Azure and extends the same database‑focused security signals, risk context, and investigation capabilities to AWS RDS: helping organizations strengthen database security the way modern applications are actually deployed.

What’s new with GA support for AWS RDS

Defender for open-source relational databases now provides GA support for security capabilities designed for enterprise cloud environments, including:

Amazon Aurora for PostgreSQL
Amazon Aurora for MySQL
Amazon RDS for PostgreSQL
Amazon RDS for MySQL
Amazon RDS for MariaDB

These capabilities are integrated directly into Microsoft Defender for Cloud, providing consistent visibility and protection across Azure and AWS environments.

Core security capabilities for multicloud databases

Defender for Cloud delivers database‑specific security signals that help teams move beyond isolated alerts to risk‑based prioritization. This strengthens Defender for Cloud’s visibility into databases security by extending sensitive data discovery insights and threat protection specifically to supported AWS resources. As part of this delivery, we’ve also added recommendations that help validate AWS RDS resources’ enablement, discovery, scanning and protection status.

Advanced threat protection at the database layer

Defender for Cloud detects suspicious access patterns and brute force attempts that indicate active database threats. Alerts are enriched with cloud and workload context to help security teams quickly determine which issues require immediate attention.

Built‑in sensitive data discovery

Automated, recurring and agentless scans help identify data that may be sensitive, such as payment details or credentials without requiring additional configuration in supported AWS resources. This visibility helps teams understand where high-risk data resides and focus protection efforts where exposure matters most.

Attack path analysis with cloud context

Rather than viewing alerts in isolation, Defender provides visibility into potential attack paths, showing how exposed databases, weak authentication, and sensitive data can combine into real attack scenarios. This capability, provided by also enabling Defender CSPM, enables teams to prioritize remediation that breaks the attack chain to not only their Azure resources but also AWS RDS databases.

Unified investigation with Microsoft Defender portal

Database alerts integrate with Microsoft Defender portal, allowing security operations teams to correlate database incidents with signals from identities, endpoints, and workloads to support investigation and response workflows. This plan allows for supported AWS RDS signals to be added and correlated as well.

Why this matters now

Together, these capabilities help organizations move beyond isolated database alerts toward risk‑based prioritization, which becomes especially critical as open‑source databases increasingly store high‑value and regulated data in multicloud architectures.

Customer outcomes: prioritized database risk across clouds

With GA support for AWS RDS, organizations can move from fragmented database security to prioritized risk management across Azure and AWS:

Detect real database threats by identifying risky access patterns tied directly to exposed databases.
Understand where sensitive data lives through built‑in discovery that highlights high‑risk data stores automatically.
See how attacks actually unfold using attack path analysis that connects exposure, misconfiguration, and data sensitivity and connecting those to actual alerts generated on the resource.
Customer can respond faster with database alerts integrated into Microsoft Defender XDR for unified investigation across environments and correlation into incidents and attack stories across various resources and plans.

Together, these outcomes help security teams move from reactive database monitoring to proactive risk reduction in multicloud architecture.

Database security as part of a unified CNAPP strategy

This GA milestone is part of Microsoft’s broader Cloud‑Native Application Protection Platform (CNAPP) approach, which brings together posture management, workload protection, and threat protection across the cloud lifecycle.

By integrating database security into CNAPP, Defender for Cloud ensures databases are not isolated controls, but a critical part of a unified view across applications, identities, workloads, and data to support risk reduction while maintaining operational efficiency.

Get started today

GA support for AWS RDS is available now.

Billing for this plan starts on June 1, 2026, and charges will appear on the July 2026 bill.

Enable Microsoft Defender for open‑source relational databases in the Azure portal to begin applying additional protections for open-source databases across Azure and AWS with unified visibility and risk‑based security.

Learn more → Cloud Security Solutions | Microsoft Security

Resources:

Learn more about Microsoft Defender for Cloud
Read the Defender for open‑source relational databases documentation
Explore sensitive data discovery
Review available trial options
Share your experience with Microsoft Defender for Cloud on Gartner Peer Insights

Public preview: Expanded coverage and unified management for SQL VA Express Configuration

Catalin Esanu — Tue, 19 May 2026 21:11:13 GMT

SQL Vulnerability Assessment (SQL VA) is a core capability in Defender for SQL that helps customers identify possible misconfigurations, excessive permissions, and other deviations from security best practices through continuous scanning of their databases. Traditionally, enabling SQL VA on SQL PaaS resources required customers to provision and maintain a dedicated Azure Storage account to hold scan results and baselines. In addition, managing SQL VA across resource types required different API endpoints, which made it harder to script consistent enablement and baseline management across a mixed SQL estate. For customers managing large SQL estates, this added operational overhead to onboarding and ongoing management. This friction may lead to inconsistent enablement across environments and leave gaps in vulnerability visibility.

To simplify this experience, Microsoft introduced Express Configuration, which uses Microsoft-managed storage and does not require a customer-provisioned storage account. Express Configuration is generally available for Azure SQL Database and is the recommended enablement mode for SQL VA, where supported.

This public preview extends Express Configuration to Azure SQL Managed Instance and Azure Synapse Analytics workspaces, and introduces a new preview API version that brings SQL VA management under a unified model across Azure SQL Database, SQL Managed Instance, Synapse workspaces, and SQL on machines (Azure VMs and Arc-enabled SQL Servers). Customers can now enable SQL VA on SQL Managed Instance and Synapse workspaces without provisioning a dedicated storage account and can manage SQL VA across all supported resource types through a single API.

Together, these changes broaden Express Configuration coverage across Azure SQL PaaS services and consolidate SQL VA operations under a single API, helping standardize how SQL VA is enabled and managed and reduce operational overhead across a customer's SQL estate.

What’s new in this release

Express Configuration support for additional Azure SQL PaaS services: Azure SQL Managed Instance (public preview) and Azure Synapse Analytics workspaces (dedicated SQL pools, public preview); Express Configuration for Azure SQL Database remains generally available.
Express Configuration is the default when enabling Defender for SQL on a resource from the UI.
New preview API version for unified SQL VA management across Azure SQL Database, SQL Managed Instance, Azure Synapse Analytics workspaces (Express Configuration only), and SQL on machines (Azure Virtual Machines and Arc-enabled SQL Servers).

Why use Express Configuration

Express Configuration simplifies how SQL Vulnerability Assessment is enabled and managed for Azure SQL Managed Instance and Azure Synapse Analytics workspaces, without changing the security coverage or rule set provided by SQL VA.

No customer-managed storage required. Express Configuration uses Microsoft-managed storage, so customers don’t need to provision or maintain storage accounts for scan results and baselines.
Automatic weekly scans and on-demand scans through the UI, unified API, or scripts.
Baseline management at scale, including setting baselines per finding or in bulk. Baseline changes take effect without waiting for the next scan to complete.

Unified management across SQL platforms

The latest preview API version enables a unified model for configuration, scanning, and governance for SQL Vulnerability Assessment across all supported SQL deployments:

Manage SQL VA across Azure SQL Database, SQL Managed Instance, and Azure Synapse Analytics workspaces.
Manage SQL VA across SQL on machines, including Azure Virtual Machines and Arc-enabled SQL Servers.
Use a consistent model for configuration, scans, results retrieval, and baseline management across supported resource types.

Limitations and prerequisites Permissions

Task	Required roles
View SQL vulnerability assessment results in Microsoft Defender for Cloud recommendations	Security Admin or Security Reader
Change SQL vulnerability assessment settings	Security Admin or SQL Security Manager
Access resource-level scan results or automated email links	Security Admin or SQL Security Manager

Classic Configuration conflict: If Classic Configuration is already enabled on a resource, enabling Express Configuration through the API will fail with an error. To migrate an existing Classic Configuration to Express Configuration, use the updated migration script.
UI enablement supports clearing Classic Configuration settings and re-enabling with Express Configuration.
SQL Managed Instance prerequisite: A system-assigned managed identity is required for Express Configuration to work on SQL Managed Instance.
Preview enablement scope: During public preview subscription-level enablement does not automatically apply Express Configuration to SQL Managed Instance or Synapse workspaces during public preview.
Reverting to Classic Configuration: After migrating to Express Configuration, reverting to Classic Configuration is possible programmatically but not through the UI.

Get started

Try it through the portal: Enable Express Configuration on a SQL Managed Instance or Synapse workspace through the Defender for Cloud portal, run an on-demand scan, and review findings in Defender for Cloud recommendations.
Automate your first steps: Use the SQL VA Express Configuration quickstart script to enable Express Configuration, discover databases, run scans, and manage baselines through the unified API.
Migrate from Classic Configuration: If you have Classic Configuration enabled on existing resources, use the migration script to move to Express Configuration.

Better together with Azure WAF + Microsoft Defender for Storage + Defender for Azure SQL Databases

Yura_Lee — Wed, 06 May 2026 17:22:23 GMT

Authored by: Fernanda_Vela , saikishor, Yura_Lee

Reviewed by: YuriDiogenes, Mohit_Kumar, Amir_Dahan, eitanbremler , Kitt_Weatherman

Introduction

Often, customers ask why additional workload protection is needed when a web application firewall is already in place. Azure Web Application Firewall (WAF) serves as a critical control at the application edge, inspecting inbound HTTP/S traffic and blocking common web-based exploits before they reach backend services. However, modern attack paths are no longer limited to the web entry point. Attackers increasingly target components that bypass HTTP/S inspection altogether such as direct access to storage and SQL through SDKs, native integration tools, private endpoints, or compromised identities and third-party integrations.

This is where Microsoft Defender for Cloud complements WAF. While WAF focuses on securing the application boundary, Defender for Cloud extends protection into the resource layer by providing Cloud-Native Application Protection Platform (CNAPP) capabilities, including security posture management and workload protection. Using resource-native signals, it helps identify misconfigurations and detect suspicious control-plane and data-plane activity that would otherwise remain invisible to perimeter controls.

The Azure Networking Security blog post “Zero Trust with Azure Firewall, Azure DDoS Protection, and Azure WAF: A practical approach” highlights WAF’s role in inspecting inbound HTTP/S traffic, detecting malicious request patterns (such as OWASP Top 10 vulnerabilities), and reducing direct exposure of backend endpoints by enforcing a controlled application entry point.

Building on that foundation, this blog focuses on a “better together” approach that combines WAF with Microsoft Defender for Cloud protecting storage and database. Through practical scenarios and posture insights, we will underline how these controls together:

Reduces attack surface at the application entry point
Continuously improves security posture through configuration and exposure analysis
Detects and responds to threats targeting storage accounts and SQL databases beyond the web perimeter

By the end of this post, you will understand how Defender for Cloud’s Storage and SQL protections extend the visibility provided by WAF, enabling protection not only at the edge, but also across the underlying data services. Together, these controls form a cohesive model that addresses both external attack vectors and internal or indirect access paths.

Note: This is not a deep configuration guide for rule tuning, nor a replacement for official product documentation. It is intended to help architects and security teams align responsibilities and understand how these services reinforce each other.

Architecture:

The architecture below shows the traffic flow and where each service fits in the lab used in this blog to simulate the attacks. Azure Application Gateway with WAF is the internet-facing entry point, inspecting inbound HTTP/S traffic before it reaches the backend. Behind it, Azure Firewall provides both network- and application-layer inspection for inbound and outbound flows. In the backend subnet, multiple VMs host the workload.

For our demonstration, we focus on a single host running:

OWASP Juice Shop (port 3000),
An upload API that writes to Azure Storage (port 8080)
An API that connects to Azure SQL Database (port 5000).

This setup allows us to simulate realistic attack paths originating both from the internet and from within the network.

Figure 1: Architecture that shows resources with Application Gateway with WAF, Azure Firewall Premium and inbound traffic

Note: The patterns in this blog apply to both Azure WAF platforms: Application Gateway WAF and Azure Front Door WAF. The lab uses Application Gateway WAF for the demonstration.

Now, let’s head to the next section where we dive deep into these services to understand their capabilities with some attacks, alerts and insights.

Azure Web Application Firewall at the Edge

As we may have understood by now, Azure WAF is the first layer of protection, inspecting external web traffic for malicious patterns. Each incoming request is evaluated against its rulesets to either allow, block or log this traffic by using its managed and custom rulesets. Now, what are these rulesets?

Azure WAF uses managed rule sets like the Default Rule Set (DRS) (version 2.2 as of this writing), which incorporate OWASP Top 10 protections and Microsoft threat intelligence to block common attacks (SQL injection, XSS, remote file inclusion, etc.) in real time. Additional managed sets include a Bot Protection rule set (to guard against malicious bots scraping content) and HTTP DDoS rule set (to detect Layer 7 DDoS patterns). Beyond the built-ins, you can define custom WAF rules for application-specific needs—blocking or allowing traffic based on attributes like geolocation, IP ranges, or specific URL paths.

Now let’s talk about an example scenario. In our lab, Azure WAF is protecting multiple backend services on different paths and ports. When an external attacker tries to exploit the Juice Shop app with a crafted XSSattack, Azure WAF immediately detects the malicious pattern and blocks the request at the gateway as seen below.

Figure 2: An XSS attack on the juiceshop website, immediately results in a 403 Forbidden as WAF catches this attack in the application layer.

However, WAF’s inspection is inherently limited to traffic it can see, primarily, the HTTP/S flows it fronts. Let’s say our attacker changes tactics: instead of trying to force malicious code through the web interface, they obtain a stolen storage key or credentials through phishing and attempt to access the Azure Storage account directly via APIs. This request never goes through WAF, so WAF cannot assess or block it. In such a case, Microsoft Defender for Storage’s threat detection monitors for such suspicious activity, for example by raising an alert about the unusual direct access or flagging a malware file uploaded to a blob container. Likewise, if our attacker exploited a weakness in application code to run malicious SQL commands on the database (whether through potentially harmful application or a suspicious service account), Defender for SQL monitors for and alerts anomalous query patterns or suspicious logins. This illustrates why WAF and Defender for Cloud are complementary: WAF stops web attacks at the door, while Defender for Cloud watches for threats that get inside or come through alternate doors.

Figure 3: Single-host lab architecture with Azure Application Gateway (WAF) and resource‑level protection

Figure 3 illustrates the key distinction: WAF inspects and protects the application entry point, while Defender for Cloud provides visibility into the resources themselves. Together, they cover both the path into the application and the behavior within the environment—forming a complete protection model across layers. Because not all access to storage and databases may flow through the application gateway, you also need resource-level posture and threat detection to see and stop activity that never appears in WAF logs.

Cloud Security Posture Management with Defender for Cloud

With the edge covered, the next challenge is reducing risk that originates from misconfiguration and resource exposure. Most successful attacks originate from exposed services and misconfigurations rather than direct application-layer exploits.

Microsoft Defender for Cloud’s storage and database protection provide security posture insights that help identify and prioritize these security gaps at the resource level. Defender for Cloud has visibility insights that capture the resources’ misconfigurations on the control and data plane via the Recommendations view in the Azure portal, as shown in the example below:

Figure 4: Juice Shop’s storage account and SQL server recommendations

Figure 4 is a list of recommendations organized by risk level for this particular environment. The security team should harden the “defendertestsai” storage asset by preventing shared access keys, and the “juiceshop” SQL database by provisioning an Entra administrator. Each recommendation will also provide guidance to remediate these findings.

The “Data & AI Dashboard” in Defender for Cloud, with Defender CSPM, will also provide security posture insight into storage, database and AI resources by surfacing their risks, alerts and sensitive data discovery all in one dashboard.

Figure 5: Juice Shop’s Sensitive data discovery and Data threat detection dashboard in Defender for Cloud’s “Data&AI section”.

Under Data closer look, in Figure 5, you can see in this example, starting from the left, sensitive information found in scanned resources, level alerts for databases and storage resources based on severity, templatized queries from the Cloud Security Explorer, and a graph displaying all internet exposed data resources below. These powerful insights on data resources all come from Defender for Cloud, designed to help customers harden their environment by priority through visibility across their entire data ecosystem based on risk level.

Figure 6: Juice Shop’s attack path “Internet exposed Azure VM with high severity vulnerabilities allows lateral movement to Critical Storage used by Azure AI Foundry”.

Attack paths are potential avenues in which an attacker can infiltrate and compromise data. In Figure 6 above, we see insight into not only the storage account itself, but the context around it: an internet exposed storage account is connected to other assets like a virtual machine and a managed identity that has permissions to manipulate data.

These Defender for Cloud security posture insights complement WAF and complete the defense-in-depth security approach: harden the data services so that even if an attacker reaches them the blast radius is smaller, and the likelihood of compromise is reduced.

Defender for Cloud’s advanced threat protection

Even in well-secured environments, attackers often interact directly with storage accounts or databases through identities, APIs, or trusted internal paths. Reducing exposure is critical but not sufficient. Detection is required once an attacker begins interacting with data Defender for Cloud’s advanced threat protection for Storage and SQL surfaces resource-level security alerts such as suspicious access patterns, anomalous queries, and malware detections—often with richer context than perimeter telemetry alone.

Let’s use a malware alert for a storage account in the Defender portal as an example:

Figure 7: Juice Shop’s storage account security alert “Malicious blob uploaded to storage account”.

Malware scanning is a common requirement for teams that process user uploads or must meet security benchmarks. In this lab, Juice Shop allows users to upload files (for example, feedback attachments), and the upload API writes those files to Azure Blob Storage.

Azure WAF inspects the HTTP request that delivers the upload headers, parameters, payload patterns and blocks web-layer attacks like XSS or SQLi. Scanning blob contents after they land is a different job, performed at the resource layer by Defender for Storage. With Defender for Storage malware scanning enabled, each uploaded blob is scanned; if the verdict is malware, Defender for Cloud raises an alert such as “Malicious blob uploaded to storage account” as shown in figure 7. Then, with Defender for Storage’s automated malware remediation, the malicious blog is set to soft-delete for quarantine and further analysis.

SQL databases are high-value targets for data access, privilege escalation, and exploitation of vulnerable applications. Database protection in Defender for Cloud has the visibility to provide customers with control plane and data plane level insight to alert on suspicious activity such as anomalous logons, unusual client applications, and injection-like query patterns.

For example, here’s a potential SQL injection alert for a database in the Defender portal:

Figure 8: Juice Shop’s database security alert on a potential SQL injection.

These alerts typically include investigation context such as the client application, client principal name, and the statement or pattern in question, along with severity to help you prioritize, as shown in Figure 8. From there, analysts can use recommended response actions (for example, to contain risky access paths or harden the database) to reduce the chance of repeat activity.

In practice, Defender for Cloud threat detection gives SOC teams prioritized, resource-specific alerts with the context needed to investigate quickly and take action at the storage and database layers.

Conclusion

Azure Application Gateway with WAF is a necessary control to reduce application-layer risk at the edge. But defense in depth requires the assumption that some threats will reach or target data services directly. By layering Microsoft Defender for Storage and Microsoft Defender for SQL on top of Azure WAF, you add continuous posture insights to reduce preventable exposure, plus threat protection that detects suspicious activity at the resource layer. Operated together, these services provide stronger prevention, better detection coverage, and clearer response paths than single control alone.

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Mon, 04 May 2026 16:47:10 GMT

What's new in Defender for Cloud?

Container runtime anti-malware detection and blocking and DNS Detection for Kubernetes is now GA in Defender for Containers for AKS, EKS, and GKE. Learn more about these announcements here and here.

Defender for Storage integration in Azure Portal Storage Center now Generally Available

Customers can now view Defender for Storage threat protection and security posture coverage directly in Storage Center, next to their storage resources to understand which storage accounts are protected, where malware scanning, activity monitoring and sensitive data discovery are enabled and identify security gaps in Azure Blog Storage and Azure File storage. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blogs of the month

In April, our team published the following blog posts we would like to share:

Securing multicloud (Azure, AWS & GCP) with Microsoft Defender for Cloud: Connector best practices

Defender for Cloud in the field

Check out the two short videos on Defender Portal integration and Start Secure Stay Secure with Defender for Cloud

GitHub Community

Check out the AI Red Teaming Workshop below:

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Photon Education, a Poland-based edtech company that uses Defender for Cloud to protect their App Services and databases immediately.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Securing multicloud (Azure, AWS & GCP) with Microsoft Defender for Cloud: Connector best practices

ckyalo — Fri, 10 Apr 2026 18:03:39 GMT

Many organizations run workloads across multiple cloud providers and need to maintain a strong security posture while ensuring interoperability. Microsoft Defender for Cloud is a cloud-native application protection platform (CNAPP) solution that helps secure these environments by providing unified visibility and protection for resources in AWS and GCP alongside Azure.

Planning for multicloud security with Microsoft Defender for Cloud

As customers adopt Microsoft Defender for Cloud in multicloud environments, Microsoft provides several resources to support planning, deployment, and scalable onboarding:

Planning Guides: Multicloud Protection Planning Guide that walks through key design considerations for securing multicloud with Microsoft Defender for Cloud.
Deployment Guides: Connect your Azure subscriptions - Microsoft Defender for Cloud.

With the right planning and adoption strategy, onboarding to Microsoft Defender for Cloud can be smooth and predictable. However, support cases show that some common challenges can still arise during or after onboarding AWS or GCP environments. Below, we walk through frequent multicloud scenarios, their symptoms, and recommended troubleshooting steps.

Common multicloud connector problems and how to resolve them

1. Problem: Removed cloud account still appears in Microsoft Defender for Cloud

The AWS/GCP account is deleted or removed from your organization, but in Microsoft Defender for Cloud it still appears under connected environments. Additionally, security recommendations for resources in the deleted account may still show up in recommendations page.

Cause

Microsoft Defender for Cloud does not automatically delete a cloud connector when the external account is removed. The security connector in Azure is a separate object that remains unless explicitly removed. Microsoft Defender for Cloud isn’t aware that the AWS/GCP side was decommissioned as there’s no automatic callback to Azure when an AWS account is closed. Therefore, the connector and its last known data linger until manually removed.

Solution

Delete the connector to clean up the stale entry. Use one of the following methods.

Option 1: Use the Azure portal

Sign in to the Azure portal.
Go to Microsoft Defender for Cloud > Environment settings.
Select the AWS account or GCP project that no longer exists.
Select Delete to remove the connector.

Option 2: REST API

Delete the connector by using the REST API: Security Connectors - Delete - REST API (Azure Defender for Cloud).

Note: If a multicloud organization connector was set up and the organization was later decommissioned or some accounts were removed, there would be several connectors to clean up. Start by deleting the organization’s management account connector, then remove any remaining child connectors. Removing connectors in this order helps prevent leftover dependencies.

Additional guidance see: What you need to know when deleting and re-creating the security connector(s) in Defender for Cloud.

2. Problem: Identity provider is missing or partially configured

After running the AWS CloudFormation template, the connector setup fails. Microsoft Defender for Cloud shows the AWS environment in an error state because the identity link between Azure and AWS is not established.

On the AWS side, the CloudFormation stack exists, but the required OIDC identity provider or the IAM role trust policy that allows Microsoft Defender for Cloud to assume the role via web identity federation is missing or misconfigured.

Cause

The AWS CloudFormation template doesn’t match the correct Azure subscription or tenant. This can happen if:

You were signed in to the wrong Azure directory when generating the template.
You deployed the template to a different AWS account than intended.

In both cases, the Azure and AWS IDs won’t align, and the connector setup will fail.

Solution

Verify your Azure directory and subscription.
- In the Azure portal, go to Directories + subscriptions and make sure the correct directory and subscription are selected before you set up the connector.

Clean up the incorrect configuration
- In AWS, delete the CloudFormation stack and any IAM roles or identity providers it created.
- In Microsoft Defender for Cloud, remove the failed connector from Environment settings.

Re-create the connector.
- Follow the steps in Connect your Azure subscriptions - Microsoft Defender for Cloud to generate and deploy a new CloudFormation template using the correct Azure and AWS accounts.

Verify the connection.
- After the connection succeeds, the AWS environment shows Healthy in Microsoft Defender for Cloud. Resources and recommendations begin appearing within about an hour.

3. Problem: Duplicate security connector prevents onboarding

When an AWS or GCP connector is added in Microsoft Defender for Cloud, onboarding fails with an error that indicates another connector with the same hierarchyId already exists. In the Azure portal, the environment shows Failed, and no resources appear in Microsoft Defender for Cloud.

Cause

Microsoft Defender for Cloud allows only one connector per cloud account within the same Microsoft Entra ID tenant. The hierarchyId uniquely identifies the cloud account (for example, an AWS account ID or a GCP project ID). If the account was previously onboarded in another Azure subscription within the same tenant, you can’t onboard it again until the existing connector is removed.

Solution
Find and remove the existing connector and then retry onboarding.

Step 1: Identify the existing connector

Sign in to the Azure portal.
Go to Microsoft Defender for Cloud > Environment settings.
Check each subscription in the same tenant for a pre-existing AWS account or GCP project connector.

If you have access, you can also query Azure Resource Graph to locate existing connectors:

| resources | where type == "microsoft.security/securityconnectors" | project name, location, properties.hierarchyIdentifier, tenantId, subscriptionId

Step 2: Remove the duplicate connector
Delete the connector that uses the same hierarchyId. Follow the steps outlined in the previous troubleshooting scenario for deleting security connectors.

Step 3: Retry onboarding After the connector is removed, add the AWS or GCP connector again in the target subscription. If the error persists, verify that all duplicate connectors were deleted and allow a short time for changes to propagate.

Conclusion

Microsoft Defender for Cloud supports a strong multicloud security strategy, but cloud security is an ongoing effort. Onboarding multicloud environments is only the first step. After onboarding, regularly review security recommendations, alerts, and compliance posture across all connected clouds. With the right configuration, Microsoft Defender for Cloud provides a single source of truth to maintain visibility and control as threats continue to evolve.

Further Resources:

Microsoft Defender for Cloud – Multicloud Security Planning Guide – Start here to design your strategy for AWS/GCP integration, with guidance on prerequisites and best practices.
Connect your AWS account - Microsoft Defender for Cloud.
Connect your GCP project - Microsoft Defender for Cloud.
Troubleshoot connectors guide - Microsoft Defender for Cloud.

We hope this guide helps you successfully implement end-to-end ingestion of Microsoft Intune logs into Microsoft Sentinel. If you have any questions, feel free to leave a comment below or reach out to us on X @MSFTSecSuppTeam.

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Thu, 02 Apr 2026 20:43:28 GMT

What's new in Defender for Cloud?

Kubernetes gated deployment is now generally available for AKS automatic clusters. Use help to deploy the Defender for Containers sensor to use this feature. More information can be found here.
Grouped recommendations are converted into individual ones to list each finding separately. While grouped recommendations are still available, new individual recommendations are now marked as preview and are not yet part of the Secure Score. This new format will allow for better prioritization, actionable context and better governance and tracking. For more details, please refer to this documentation.

Check out other updates from last month here!

Check out monthly news for the rest of the MTP suite here!

Blogs of the month

In March, our team published the following blog posts we would like to share:

Defender for Cloud in the field

Revisit the malware automated remediation announcement since this feature is now in GA!

GitHub Community

Check out the new Module 28 in the MDC Lab: Defending Container Runtime from Malware with Microsoft Defender for Containers

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring ManpowerGroup, a global workforce solutions leader, deployed Microsoft 365 E5, and Microsoft Security to modernize and future-proof their cyber security platform. ManpowerGroup leverages Entra ID, Defender for Endpoint, Defender for Identity, Defender for O365, Defender for Cloud, Microsoft Security Copilot and Purview to transform itself as an AI Frontier Firm.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe

Defending the AI Era: New Microsoft Capabilities to Protect AI

danielacardon — Fri, 20 Mar 2026 15:45:00 GMT

As enterprises rapidly adopt AI to drive productivity, automate decisions, and power intelligent agents, a new attack surface is emerging—one that traditional security controls were never designed to protect. AI models, training pipelines, plugins, and autonomous agents now sit directly in the path of sensitive data, business logic, and critical workflows. Organizations must protect the AI supply chain from model development and deployment to runtime behavior, tool access, and downstream actions.

At the same time, AI agents operating with broad privileges require runtime monitoring to ensure every tool invocation and action is safe. By combining proactive model scanning across the AI lifecycle with runtime enforcement that monitors and blocks risky agent behavior, security teams gain the visibility and control needed to prevent data exfiltration, misuse of automation, and silent manipulation of outcomes at machine speed.

Microsoft Defender helps organizations protect AI investments end-to-end by proactively identifying risks, detecting AI-specific attacks, and enabling investigation and response efforts. New innovations in Defender continue to build upon this value with new threat protection and visibility capabilities for agents through Agent 365 and AI model scanning.

Protect AI agents in Agent 365 from emerging threats

As AI agents become embedded in core business workflows, they introduce a new class of operational risk that traditional security controls were never designed to manage. AI agents don’t just process data—they take actions, invoke tools, and make decisions, often with broad access to sensitive systems and information. Without continuous visibility and protection of agent activity at runtime, organizations risk silent data exfiltration, misuse of automation, and manipulated outcomes that can directly impact business integrity, compliance, and trust.

Real-time protection integrates Microsoft Defender directly into Agent 365’s tools gateway (ATG) to evaluate every agent tool invocation before it executes.

The new capabilities provide critical runtime scrutiny to catch unsafe or manipulated actions that traditional build-time checks cannot. It focuses on high confidence threats such as attempts to extract system instructions, access or leak sensitive data, misuse internal only tools, or route information to untrusted destinations

If an action is determined to be risky, Defender blocks it immediately, before tool invocation, preventing any data access or leak, and harmful action. When there is a block of a risky action, a comprehensive, SOC-ready alert is generated that explains what was stopped, why it was considered risky, and which agent, user, and tool were involved.

Identify risks across the AI model lifecycle

When we talk about securing AI, we need to start with the model itself. AI models go through a lifecycle from data sourcing and training, through packaging and deployment, all the way to production. At each stage, there are security risks that traditional application security doesn't address. Understanding where those risks live is the first step toward building the right controls.

Before any training begins, teams are pulling in pretrained models from registries like Hugging Face, consuming third-party datasets, and importing ML frameworks into their pipelines. A compromised pretrained model can carry embedded malware or backdoors that activate only under specific conditions. If models are consumed from external sources without scanning them, they are trusting unknown actors with access to our environment.

AI model scanning in Microsoft Defender now provides scanning for models stored in Azure ML registries and workspaces covering malware, unsafe operators, and backdoors across common model formats.

For security teams, recurring scanning results in security recommendations tied to the specific model resource enable quick remediation. Additionally, high-confidence malware detections now generate Defender alerts that flow directly into SOC workflows via Defender XDR.

For developers, a new CLI integration enables in-pipeline on-demand scanning of model artifacts during the build process identifies risks down the single line of code. Additionally, gating capabilities in CI/CD pipelines help prevent unsafe models from ever reaching a registry. If a model hasn't been scanned, it shouldn't be pushed.

Visibility across the lifecycle ties it all together. The AI model lifecycle requires controls at every stage: supply chain integrity verification, artifact validation during development, automated scanning before deployment, runtime threat detection in production, and discovery and cleanup at end of life. The organizations that treat this as a continuous discipline not a one-time checkpoint are the ones building the foundation to scale AI securely.

New innovations in Microsoft Defender to strengthen multi-cloud, containers, and AI model security

parulseth — Fri, 20 Mar 2026 15:30:00 GMT

Cloud security today is no longer just about misconfigurations; it’s about keeping pace with cloud-native change, prioritizing risk before it becomes an incident, and securing AI as a new supply chain for applications. In modern environments, infrastructure and applications are rebuilt and redeployed constantly through CI/CD, containers, and managed services, which means the security posture can quickly change. That speed increases the chance that small gaps—overly permissive identities, risky configuration drift, or unvetted AI models—turn into real attack paths unless teams have continuous visibility and guardrails that prevent regression.

At the same time, security professionals need more than long lists of findings; they need risk context that connects issues to likelihood of exploitation and business impact so they can fix what matters first. And as organizations embed generative AI, the model itself becomes an artifact that must be governed like any other dependency—acquired, stored, scanned, validated, and monitored—because a tampered or unsafe model can introduce backdoors, leak sensitive data, or produce manipulated outputs at scale. In short, cloud security now spans across posture, runtime, and supply chain—for both cloud resources and the AI-powered applications.

Today, we are closing that gap with multi-layered security: expanding our multi-cloud visibility to new AWS and GCP services, enabling near real-time container runtime protection to eliminate binary drift, and introducing AI model scanning. By embedding security directly into the execution layer of both containers and AI, Microsoft Defender for Cloud ensures that as your organization scales, your defense adapts automatically.

Strengthen security posture through broader coverage, visibility, and prioritized real risk

Microsoft Defender continues to expand how customers see and secure their multi-cloud environments by adding broader coverage and deeper visibility across Amazon Web Services (AWS) and Google Cloud Platform (GCP). With support across compute, databases, storage, analytics, AI and machine learning, identity, networking, and DevOps, customers can now discover and inventory a much wider set of cloud assets through a single, unified experience. This expanded agentless coverage automatically delivers security recommendations and compliance insights for newly discovered resources, enabling continuous risk assessment and faster remediation of misconfigurations. Coverage for these additional AWS and GCP resources will be available in public preview in March.

As visibility increases, Defender for Cloud also ensures that prioritization remains clear and actionable. Cloud Secure Score—our AI‑driven, dynamic, risk‑based scoring mechanism—evaluates each resource individually based on likelihood of exploitation and potential business impact. This gives security teams clear insight into how and why their score evolves over time, helping them focus on the most critical risks first. Cloud Secure Score will be generally available in the Defender portal and publicly available in the Azure portal by the end of April.

Defender for Cloud is also extending protection to specialized workloads, including upcoming vulnerability assessment support for Azure Databricks compute clusters, which provides visibility and actionable recommendations for vulnerabilities introduced through custom libraries. Vulnerability assessment for Azure Databricks will be available in Defender CSPM by the end of April.

Detect and block unauthorized changes in running containers

As organizations gain clearer visibility into risk across their cloud estate, protecting workloads at runtime becomes a critical layer of defense.

Containers are designed to be immutable, but in practice attackers often exploit runtime gaps by introducing unauthorized binaries or malicious executables after deployment—changes that traditional controls may not detect in time. To address this risk, we are announcing binary drift detection and prevention, along with anti-malware detection and prevention for containers.

These capabilities identify when a running container deviates from its original image and automatically prevents unauthorized or malicious processes from executing. With policy-driven controls, security teams can distinguish legitimate operational activity from suspicious behavior. This allows security teams to protect the integrity of their containerized applications and reduce the window for runtime compromise. The result is stronger, proactive protection that helps organizations confidently run container workloads across modern Kubernetes environments. Binary drift detection is now generally available, and binary drift prevention and anti-malware detection and prevention in public preview.

Identify risks to your AI supply chain

As generative AI becomes embedded in applications—from support chatbots and copilots to automated decisioning—unsecured AI models introduce a new and often invisible risk surface. A compromised or unvetted model can leak sensitive data, execute unsafe logic, or generate manipulated outputs that undermine trust, compliance, and brand integrity. Unlike traditional software flaws, these risks can propagate at machine speed, turning a single vulnerable model into a systemic business issue. Securing AI models before they are deployed—and continuously as they evolve—is critical for organizations delivering AI‑powered experiences.

We’re thrilled to share the public preview of AI model scanning in Microsoft Defender, starting April, that delivers comprehensive protection for models stored in Azure Machine Learning registries and workspaces, identifying malware, unsafe operators, and embedded backdoors across common model formats. Continuous scanning generates actionable security recommendations tied to each model resource, while high-confidence malware detections trigger Defender alerts that flow directly into SOC workflows through Defender XDR.

For developers, a new CLI enables on-demand, in-pipeline scanning of model artifacts during the build process, surfacing risk down to individual files and enforcing security gates in CI/CD pipelines so that models that haven’t been scanned aren’t deployed.

Visibility across the AI development cycle brings these controls together—from supply chain integrity and artifact validation to pre-deployment scanning. Organizations that treat AI security as a continuous discipline, not a onetime checkpoint, build the foundation required to scale AI securely.

AI model scanning will be available in public preview starting April 1^st at no additional cost as part of Defender for AI Services plan. Licensing requirements might change when the feature becomes generally available. If that happens, the feature will be disabled, and you’ll be notified should you wish to re-enable it under the new license.

Additional Resources

Learn more about Microsoft Defender for Cloud, here
Find cloud security recent innovations, here
Defender for AI blog
Attend cloud security theatre sessions on container security and AI models at RSA on March 24^th and March 25^th

Modern Database Protection: From Visibility to Threat Detection with Microsoft Defender for Cloud

Yura_Lee — Wed, 11 Mar 2026 17:51:24 GMT

Databases sit at the heart of modern businesses. They support everyday apps, reports and AI tools. For example, any time you engage a site that requires a username and password, there is a database at the back end that stores your login information. As organizations adopt multi-cloud and hybrid architectures, databases are generated all the time, creating database sprawl. As a result, tracking and managing every database, catching misconfigurations and vulnerabilities, knowing where sensitive information lives, all becomes increasingly difficult leaving a huge security gap. And because companies store their most valuable data, like your login information, credit card and social security numbers, in databases, databases are the main target for threat actors.

Securing databases is no longer optional, yet getting started can feel daunting. Database security needs to address the gaps mentioned above – help organizations see their databases to help them monitor for misconfigurations and vulnerabilities, sensitive information and any suspicious activities that occur within the database that are indicative of an attack. Further, database security must meet customers where they are – in multi-cloud and hybrid environments. This five part blog series will introduce and explore database-specific security needs and how Defender for Cloud addresses the gaps through its deep visibility into your database estate, detection of misconfiguration, vulnerabilities and sensitive information, threat protection with alerts and Integrated security platform to manage it all.

This blog, part one, will begin with an overview of today’s database infrastructure security needs. Then we will introduce Microsoft Defender for Cloud’s unique database protection capabilities to help address this gap.

Modern Database Architectures and Their Security Implications

Modern databases can be deployed in two main ways: on your own infrastructure or as a cloud service. In an on-premises or IaaS (Infrastructure as a Service) setup, you manage the underlying server or virtual machine. For example, running a SQL Server on a self-managed Windows server—whether in your data center or on a cloud VM in Azure or AWS—is an IaaS deployment (Microsoft Defender for Cloud refers to these as “SQL servers on machines”) that require server maintenance. The other approach is PaaS (Platform as a Service), where a cloud provider manages the host server for you. In a PaaS scenario, you simply use a hosted database service (such as Azure SQL Database, Azure SQL Managed Instance, Azure Database for PostgreSQL, or Amazon RDS) without worrying about the operating system or server maintenance. In either case, you need to secure both the database host (the server or VM) and the database itself (the data and database engine).

It’s also important to distinguish between a database’s control plane and data plane. The control plane includes the external settings that govern your database environment—like network firewall rules or who can access the system. The data plane involves information and queries inside the database. An attacker might exploit a weak firewall setting on the control plane or use stolen credentials to run malicious queries on the data plane. To fully protect a database, you need visibility into both planes to catch suspicious behavior.

Effective database protection must span both IaaS and PaaS environments and monitor both the control plane and data plane because they are common targets for threat actors. Security teams can then detect suspicious activity such as SQL injections, brute-force attempts, and lateral movement through your environment.

A Unified Approach to Database Protection Built for Multicloud

Modern database environments are fragmented across deployment models, database ownership, and teams. Databases run across IaaS and PaaS, span control and data planes, and in multiple clouds, yet protection is often pieced together from disconnected point solutions

Microsoft Defender for Cloud is a cloud native application protection platform (CNAPP) solution that provides a unified, cloud-native approach to database protection—bringing together discovery, posture management, and threat detection across SQL (Iaas and Paas), open-source relational databases (OSS), and Cosmos DB databases. Defender for Cloud’s database protection uses both agent-based and agentless solutions to protect database resources on-premises, hybrid, multi-cloud and Azure. A lightweight agent-based solution is used for SQL servers on Azure virtual machines or virtual machines hosted outside Azure and allows for deeper inspection, while an agentless approach for managed databases stored in Azure or AWS RDS resources provide protection with seamless integration.

Additionally, Defender for Cloud brings in other signals from the cloud environment, surfacing a secure score for security posture, an asset inventory, regulatory compliance, governance capabilities, and a cloud security graph that allows for proactive risk exploration.

The value of database security in Defender for Cloud starts with pre and post breach visibility. Vulnerability assessment and data security posture management helps security admins understand their database security posture and, by following Defender for Cloud’s recommendations, security admins can harden their environment proactively. Vulnerability assessments scans surface remediation steps for configurations that do not follow industry’s best practices. These recommendations may include enabling encryption when data is at rest where applicable or database server should restrict public access ranges.

Data security posture management in Defender for Cloud automatically helps security admins prioritize the riskiest databases by discovering sensitive data and surfacing related exposure and risk. When databases are associated with certain risks, Defender for Cloud will provide its findings in three ways: risk-based security recommendations, attack path analysis with Defender CSPM and the data and AI dashboard. The risk level is determined by other context related to the resource like, internet exposure or sensitive information. This way, Security admins will have a solid understanding of their database environment pre-breach and will have a prioritized list of resources to remediate based on risk or posture level.

While we can do our best to harden the environment, breaches can still happen. Timely post-breach response is just as important. Threat detection capabilities within Defender for Cloud will identify anomalous activity in near real time so SOC analytes can take action to contain the attack immediately. Defender for Cloud monitors both the control and the data plane for any anomalous activity that indicates a threat, from brute force attack detections to access and query anomalies.

To provide a unified security experience, Defender for Cloud natively integrates with the Microsoft Defender Portal. The Defender portal brings signals from Defender for Cloud to provide a single cloud-agnostic security experience, equipping security teams with tools like secure score for security posture, attack paths, and incidents and alerts. When anomalous activities occur in the environment, time is of the essence. Security teams must have context and tools to investigate a database resource, both in the control plan and the data plane, to remediate and mitigate future attacks quickly. Defender for Cloud and the Defender portal brings together a security ecosystem that allows SOC analysts to investigate, correlate activities and incidents with alerts, contain and respond accordingly.

Take Action: Close the Database Blind Spot Today

Modern database environments demand more than isolated controls or point solutions. As databases span hybrid and multiple clouds, security teams need a unified approach that delivers visibility, context, and actionable protection where the data lives.

Microsoft Defender for Cloud provides organizations the visibility into all of your databases in a centralized Defender portal using its unique control and data plane findings so that security teams can identify misconfigurations. prioritize them based on cloud-context risk-based recommendations or proactively identify other attack scenarios using the attack path analysis while SOC analysts can investigate alerts and act quickly.

Follow this story for part two. We’ll go into Defender for Cloud’s unique visibility into database resources to find misconfiguration gaps, sensitive information exposure, and contextual risks that may exist in your environment.

Resources:

Get started with Defender for Databases.

Learn more about SQL vulnerability assessment.

Learn more about Data Security Posture Management

Learn more about Advanced Threat Protection

Reviewers:

YuriDiogenes, lisetteranga, talberdah

Defending Container Runtime from Malware with Microsoft Defender for Containers

Vasavi_Pasula — Wed, 04 Mar 2026 12:49:58 GMT

In cloud-native environments, malware protection is no longer traditional antivirus — it is runtime workload security, ensuring containerized applications remain safe throughout their lifecycle.

Many organizations focus on scanning container images before deployment. While image scanning is important, this does not stop runtime attacks. Image scanning protects before deployment, but malware detection protects during execution.

Malware can enter cloud environments through container images, compromised CI/CD pipelines, exposed services, or misuse of legitimate administrative tools, making runtime malware detection an essential security control rather than an optional enhancement. Runtime Malware detection and Prevention acts as the last line of defence when preventive controls fail.

If malware executes successfully inside a container, it may attempt Privilege escalation, Container escape and Host compromise.

Antimalware in Defender for Containers

Defender for Containers antimalware, powered by Microsoft Defender Antivirus cloud protection, near-real-time malware detection directly into container environments. The antimalware feature is available via Helm with sensor version 0.10.2 for AKS, GKE, and EKS. Defender for Containers Sensor

Defender for Containers Antimalware provides:

Runtime monitoring of container activity

Malware detection on Container Workloads

Malware detection for Kubernetes nodes

Alerts integrated into Defender XDR

Anti-malware detection and blocking - Microsoft Defender for Cloud | Microsoft Learn

Container antimalware protection in Defender for Containers is powered by three main components:

1) Defender Sensor - version 0.10.2 installed via Helm or arc-extension

The Defender sensor runs inside the Kubernetes cluster and monitors workload activity in real time.

It provides:

Runtime visibility into container processes

Binary execution monitoring

Behavioral inspection

Alert and Block Malware execution

Multicloud Support (Azure Kubernetes Service, AWS EKS, GCP GKE)

Prerequisites: Ensure the following components of the Defender for containers plan are enabled:

Defender sensor

Security findings

Registry access

Kubernetes API access

To Install Defender Sensor for Antimalware, ensure there are sufficient resources on your Kubernetes Cluster and outbound connectivity. In addition to the core sensor memory and CPU requirements, you need:

Component	Request	Limit
CPU	50m	300m
Memory	128Mi	500Mi

All sensor components use outbound-only connectivity (no inbound access required).

To install Defender for Containers sensor follow the guidance here

To Verify the sensor deployed successfully on all nodes, use the commands as screenshot below:

You should see the collectors pods in Running state with 3/3 containers.

2) Antimalware Policy Engine

Policies define what happens when malware is detected:

Alert only

Block execution

Ignore (allowlisted cases)

Policies can be scoped to Azure subscriptions, AWS Accounts and GCP Projects and also to Specific clusters, Namespaces, Pods, Images, Labels or workloads. This allows organizations to reduce false positives while enforcing strict security where needed.

Host vs Workload Protection — How Sensor Covers Both

Antimalware Rules can be applied to Resource scopes:

Scope	What Is Protected
Workload (Container)	Processes inside containers
Host (Node)	Kubernetes node OS and runtime

Default rules include:

Default antimalware workload rule

Default antimalware host rule

This matters because attackers often escape containers and target kubelet, container runtime, and node filesystem. Blocking malware at both workload and host layers prevents cluster takeover.

To configure the Antimalware policy follow the guidance here

To verify the antimalware policy is deployed to the cluster, login to your K8s cluster and use the commands as screenshot below:

3) Cloud Protection (Microsoft Defender Antivirus Cloud)

Defender for Containers Sensor integrates with Microsoft Defender Antivirus cloud protection, which provides Global threat intelligence, Machine learning classification, Reputation scoring, Zero-day detection. When suspicious binaries appear, cloud analysis determines whether they should be allowed or blocked.

To test Malware detection and blocking, upload an EICAR file to a running Container on your cluster.

If policy action = Block Malware, the sensor performs enforcement. Blocking actions include, Killing malicious process and Generates Defender for Cloud alert as below:

The malware is detected and execution is blocked.

Defender for Cloud Alerts are also available in Defender XDR portal.

Security Operations teams can further investigate the infected file by navigating to the Incidents and Alerts section in the Defender portal.

When a container or pod is determined to be compromised, Defender XDR enables Security Operations Team to take response actions. For more details : Investigate and respond to container threats in the Microsoft Defender portal

Binary Drift Detection and Prevention :

Containers are expected to be immutable. Running containers should only execute binaries that came from the original container image. This is extremely important because most container attacks involve Curl/wget downloading malware, Crypto miners dropped post-compromise, Attack tools installed dynamically. For more details refer Binary drift detection and blocking

Defender detects runtime drift, such as

New binaries downloaded after deployment

Files written into container filesystem

Tools installed via reverse shell

Payloads dropped by attackers

To Configure drift detection and prevention policy follow the guidance here . When a drift is detected on a container workload, Defender for Container sensor detects drift and prevents it from being drifted.

To test drift prevention, deploy a container and introduce a drift in the running container. The drift will be detected by the sensor and prevents drift, and alert is generated as shown in the screenshot below:

References:

Anti-malware detection and blocking

Install Defender for Containers sensor using Helm

Binary drift detection and blocking

Investigate and respond to container threats in the Microsoft Defender portal

Reviewed by:

Eyal Gur, Principal Product Manager, Microsoft Defender for Cloud

Microsoft Defender for Cloud Customer Newsletter

Yura_Lee — Tue, 03 Mar 2026 15:30:22 GMT

Check out monthly news for the rest of the MTP suite here!

What's new in Defender for Cloud?

Now in public preview, Defender for Cloud provides threat protection for AI agents built with Foundry, as part of the Defender for AI Services plan. Learn more about this in our documentation.
Defender for Cloud’s Defender for SQL on machines plan provides a simulated alert feature to help validate deployment and test prepared security team for detection, response and automation workflows. For more details, please refer to this documentation.

Check out other updates from last month here.

Blogs of the month

In February, our team published the following blog post we would like to share:

Extending Defender's AI Threat Protection to Microsoft Foundry Agents

Defender for Cloud in the field

Revisit the announcement on the new Secure Score model and the enhancements available in the Defender Portal.

New Secure Score model and Defender portal enhancements

GitHub Community

Module 12 in Defender for Cloud’s lab has been updated to include alert simulation!

Database protection lab - module 12

Customer journey

Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring ContraForce. ContraForce, a cybersecurity startup, built its platform on Microsoft’s robust security and AI ecosystem. Contraforce, while participating in Microsoft for Startup Pegasus program, addressed the issue of traditional, complex, and siloed security stacks by leveraging Microsoft Sentinel, Defender XDR, Entra ID and Microsoft Foundry. ContraForce was able to deliver enterprise-grade protection at scale, without the enterprise-level overhead. As a result, measured key outcomes like 90%+ incident automation, 93% reduced cost per incident, and 60x faster incident response.

Join our community!

Note: If you want to stay current with Defender for Cloud and receive updates in your inbox, please consider subscribing to our monthly newsletter: https://aka.ms/MDCNewsSubscribe