Agentless code scanning for GitHub and Azure DevOps (preview)
š Start free preview ā¶ļø Watch a video on agentless code scanning Most security teams want to shift left. But for many developers, "shift left" sounds like "shift pain". Coordination. YAML edits with extra pipeline steps. Build slowdowns. More friction while they're trying to go fast. šŖ Pipeline friction YAML edits with extra steps ā±ļø Build slowdowns More friction, less speed š§© Complex coordination Too many moving parts That's the tension we wanted to solve. With agentless code scanning in Defender for Cloud, you get broad visibility into code and infrastructure risks across GitHub and Azure DevOps - without touching your CI/CD pipelines or installing anything. āØ Just connect your environment. We handle the rest. Already in preview, here's what's new Agentless code scanning was released in November 2024, and we're expanding the preview with capabilities to make it more actionable, customizable, and scalable: ā GitHub & Azure DevOps Connect your GitHub org and scan every repository automatically šÆ Scoping controls Choose exactly which orgs, projects, and repos to scan š Scanner selection Enable code scanning, IaC scanning, or both š§° UI and REST API Manage at scale, programmatically or in-portal or Cloud portal š Available for free during the preview under Defender CSPM How agentless code scanning works Agentless code scanning runs entirely outside your pipelines. Once a connector has been created, Defender for Cloud automatically discovers your repositories, pulls the latest code, scans for security issues, and publishes findings as security recommendations - every day. Here's the flow: 1 Discover Repositories in GitHub or Azure DevOps are discovered using a built-in connector. 2 Retrieve The latest commit from the default branch is pulled immediately, then re-scanned daily. 3 Analyze Built-in scanners run in our environment: Code Scanning ā looks for insecure patterns, bad crypto, and unsafe functions (e.g., `pickle.loads`, `eval()`) using Bandit and ESLint. Infrastructure as Code (IaC) ā detects misconfigurations in Terraform, Bicep, ARM templates, CloudFormation, Kubernetes manifests, Dockerfiles, and more using Checkov and Template Analyzer. 4 Publish Findings appear as Security recommendations in Defender for Cloud, with full context: file path, line number, rule ID, and guidance to fix. Get started in under a minute 1 In Defender for Cloud, go to Environment settings ā DevOps Security 2 Add a connector: Azure DevOps ā requires Azure Security Admin and ADO Project Collection Admin GitHub ā requires Azure Security Admin and GitHub Org Owner to install the Microsoft Security DevOps app 3 Choose your scanning scope and scanners 4 Click Save ā and we'll run the first scan immediately s than a minute No pipeline configuration. No agent installed. No developer effort. Do I still need in-pipeline scanning? Short answer: yes - if you want depth and speed in the development workflow. Agentless scanning gives you fast, wide coverage. But Defender for Cloud also supports in-pipeline scanning using Microsoft Security DevOps (MSDO) command line application for Azure DevOps or GitHub Action. Each method has its own strengths. Here's how to think about when to use which - and why many teams choose both: When to use... āļø Agentless Scanning šļø In-Pipeline Scanning Visibility Quickly assess all repos at org-level Scans and enforce every PR and commit Setup Requires only a connector Requires pipeline (YAML) edits Dev experience No impact on build time Inline feedback inside PRs and builds Granularity Repo-level control with code and IaC scanners Fine-tuned control per tool or branch Depth Default branch scans, no build context Full build artifact, container, and dependency scanning š” Best practice: start broad with agentless. Go deeper with in-pipeline scans where "break the build" makes sense. Already using GitHub Advanced Security (GHAS)? GitHub Advanced Security (GHAS) includes built-in scanning for secrets, CodeQL, and open-source dependencies - directly in GitHub and Azure DevOps. You don't need to choose. Defender for Cloud complements GHAS by: Surfaces GHAS findings inside Defender for Cloud's Security recommendations Adds broader context across code, infrastructure, and identity Requires no extra setup - findings flow in through the connector You get centralized visibility, even if your teams are split across tools. One console. Full picture. Core scenarios you can tackle today š”ļø Catch IaC misconfigurations early Scan for critical misconfigurations in Terraform, ARM, Bicep, Dockerfiles, and Kubernetes manifests. Flag issues like public storage access or open network rules before they're deployed. šÆ Bring code risk into context All findings appear in the same portal you use for VM and container security. No more jumping between tools - triage issues by risk, drill into the affected repository and file, and route them to the right owner. š Focus on what matters Customize which scanners run and where. Continuously scan production repositories. Skip forks. Run scoped PoCs. Keep pace as repositories grow - new ones are auto-discovered. What you'll see - and where All detected security issues show up as security recommendations in the recommendations and DevOps Security blades in Defender for Cloud. Every recommendation includes: ā Affected repository, branch, file path, and line number š ļø The scanner that found it š” Clear guidance to fix What's next We're not stopping here. These are already in development: š Secret scanning Identify leaked credentials alongside code and IaC findings š¦ Dependency scanning Open-source dependency scanning (SCA) šæ Multi-branch support Scan protected and non-default branches Follow updates in our Tech Community and release notes. Try it now - and help us shape what comes next Connect GitHub or Azure DevOps to Defender for Cloud (free during preview) and enable agentless code scanning View your discovered DevOps resources in the Inventory or DevOps Security blades Enable scanning and review recommendations Microsoft Defender for Cloud ā Recommendations Shift left without slowing down. Start scanning smarter with agentless code scanning today. Helpful resources to learn more Learn more in the Defender for Cloud in the Field episode on agentless code scanning Overview of Microsoft Defender for Cloud DevOps security Agentless code scanning - configuration, capabilities, and limitations Set up in-pipeline scanning in: Azure DevOps GitHub action Other CI/CD pipeline tools (Jenkins, BitBucket Pipelines, Google Cloud Build, Bamboo, CircleCI, and more)Your cluster, your rules: Helm support for container security with Microsoft Defender for Cloud
Container security within Microsoft Defender for Cloud has helped security teams protect their Kubernetes workloads with deep visibility, real-time threat detection, and cloud-native runtime protection. Up until now itās been delivered via Azure Kubernetes Service (AKS) add-on or Arc for Kubernetes extension, providing a streamlined, fully managed experience, deeply integrated with Azure. But for some teams, especially those operating in complex, multi-cloud environments or with specific operational requirements, this could introduce constraints around customization and deployment. To address this, weāve introduced Helm support, making it easier to deploy the sensor for container security and enabling greater agility, customization, and seamless integration with modern DevOps workflows. Customers can now choose whether to use Helm to deploy the sensor or to use the previous method to deploy it as an AKS add-on or an Arc for Kubernetes extension for clusters outside of Azure. But why does this matter? Letās take a step back. The backstory: Why we need more flexibility Since we first introduced our sensor back in 2021, deploying it meant using the built-in AKS add-on or provisioning it through Arc for other environments. This is one of our enablers for the āauto-provisioning" feature, which automatically installs and updates our sensor on managed clusters. This approach made setup simple and tightly integrated but also introduced some friction. Wait for the AKS release cycle to roll out new features. Harder to achieve custom deployment models, like GitOps or advanced CI/CD integrations. Limited support existed for configuring the sensor in non-standard environments. This was fine for many teams, but in larger organizations with multiple teams, strict change management, and complex multi-cluster environments, the lack of deployment flexibility of the sensor could slow down operations or create friction with established workflows. Deploying via Helm: Why is it a big deal? Helm is the de facto package manager for Kubernetes, trusted by DevOps teams to install, configure, and manage workloads in a consistent, declarative way. Weāre now supporting Helm as a standalone deployment option - giving you direct access to the helm chart without the abstraction provided by the AKS add-on or Arc for Kubernetes extension. This means you can now deploy and manage the sensor like any other Helm-managed workload with full control over when, how, and where it's deployed, all while aligning naturally with GitOps, CI/CD pipelines, and your existing infrastructure-as-code practices. Helm supports multi-cloud with less overhead Traditionally, deploying Defender for Cloud on non-AKS clusters like EKS and GKE required onboarding those clusters to Azure Arc for Kubernetes. Arc provides a powerful way to centrally manage and govern clusters that live outside Azure, which is ideal for organizations looking to apply Azure-native policies, inventory, or insights across hybrid environments. But what if all you want is Defender for Cloudās runtime security with minimal operational overhead? Thatās where Helm comes in. With Helm, you can now deploy the sensor without requiring Arc onboarding, which means: Smaller footprint on your clusters No access required for your Kubernetes API server Simpler setup focused purely on security This approach is ideal for teams that want to integrate Defender for Cloud into existing EKS or GKE environments while staying aligned with GitOps or CI/CD practices ā and without pulling in broader Azure governance tooling. Arc still plays an important role in hybrid Kubernetes management. But if your goal is to quickly secure workloads across clusters with minimal configuration, Helm gives you a lightweight, purpose-built path forward. What you can do with Helm-based deployment Opt-in to adopt new Private, Public Preview or General Availability (GA) features as soon as theyāre published. Great for early adopters and fast-moving teams. Gain more control over upgrades by integrating into CI/CD and GitOps. Whether you're using ArgoCD, Flux, or GitHub Actions, Helm makes it easy to embed Defender for Cloud into your pipelines. This means consistent deployments across clusters and security that scales with your application delivery. Override values using your own YAML files, so you can fine-tune how the sensor behaves based on RBAC rules, logging preferences, or network settings. Experiment safely by deploying Defender for Cloud in a dev cluster. Validate new features, tear it down, and repeat the cycle. Helm simplifies experimentation, making it easier to test without risking your production environment. The (not so) fine print While Helm unlocks flexibility, there are still a few things to keep in mind: Helm support is for the sensor component only, not the full Microsoft Defender for Cloud configuration experience. If you are moving to Helm, the āauto-provisioningā feature doesnāt work. Meaning you are responsible for version upgrades and version compatibility, especially when integrating with CI/CD tools that manage Helm releases automatically. Ready to deploy? You can learn more on how to deploy the sensor via Helm to protect your containerized environment with Defender for Cloud
From visibility to action: The power of cloud detection and response
Cloud attacks arenāt just growingātheyāre evolving at a pace that outstrips traditional security measures. Todayās attackers arenāt just knocking at the doorātheyāre sneaking through cracks in the system, exploiting misconfigurations, hijacking identity permissions, and targeting overlooked vulnerabilities. While organizations have invested in preventive measures like vulnerability management and runtime workload protection, these tools alone are no longer enough to stop sophisticated cloud threats. The reality is: security isnāt just about blocking threats from the startāitās about detecting, investigating, and responding to them as they move through the cloud environment. By continuously correlating data across cloud services, cloud detection and response (CDR) solutions empower security operations centers (SOCs) with cloud context, insights, and tools to detect and respond to threats before they escalate. However, to understand CDRās role in the broader cloud security landscape, letās first understand how it evolved from traditional approaches like cloud workload protection (CWP). The natural progression: From protecting workloads to correlating cloud threats In todayās multi-cloud world, securing individual workloads is no longer enoughāorganizations need a broader security strategy. Microsoft Defender for Cloud offers cloud workload protection as part of its broader Cloud-Native Application Protection Platform (CNAPP), securing workloads across Azure, AWS, and Google Cloud Platform. It protects multicloud and on-premises environments, responds to threats quickly, reduces the attack surface, and accelerates investigations. Typically, CWP solutions work in silos, focusing on each workload separately rather than providing a unified view across multiple clouds. While this solution strengthens individual components, it lacks the ability to correlate the data across cloud environments. As cloud threats become more sophisticated, security teams need more than isolated workload protectionāthey need context, correlation, and real-time response. CDR represents the natural evolution of CWP. Instead of treating security as a set of isolated defenses, CDR weaves together disparate security signals to provide richer context, enabling faster and more effective threat mitigation. A shift towards a more unified, real-time detection and response model, CDR ensures that security teams have the visibility and intelligence needed to stay ahead of modern cloud threats. If CWP is like securing individual rooms in a buildingālocking doors, installing alarms, and monitoring each space separatelyāthen CDR is like having a central security system that watches the entire building, detecting suspicious activity across all rooms, and responding in real time. That said, building an effective CDR solution comes with its own challenges. These are the key reasons your cloud security strategy might be falling short: Lack of ContextāÆ SOC teams canāt protect what they canāt see. Limited visibility and understanding into resource ownership, deployment, and criticality makes threat prioritization difficult. Without context, security teams struggle to distinguish minor anomalies from critical incidents. For example, a suspicious process in one container may seem benign alone but, in context, could signal a larger attack. Without this contextual insight, detection and response are delayed, leaving cloud environments vulnerable. Hierarchical ComplexityāÆ Cloud-native environments are highly interconnected, making incident investigation a daunting task. A single container may interact with multiple services across layers of VMs, microservices, and networks, creating a complex attack surface. Tracing an attack through these layers is like finding a needle in a haystackāone compromised component, such as a vulnerable container, can become a steppingstone for deeper intrusions, targeting cloud secrets and identities, storage, or other critical assets. Understanding these interdependencies is crucial for effective threat detection and response. Ephemeral ResourcesāÆ Cloud native workloads tend to be ephemeral, spinning up and disappearing in seconds. Unlike VMs or servers, they leave little trace for post-incident forensics, making attack investigations difficult. If a container is compromised, it may be gone before security teams can analyze it, leaving minimal evidenceāno logs, system calls, or network data to trace the attackās origin. Without proactive monitoring, forensic analysis becomes a race against time. āÆ A unified SOC experience with cloud detection and response The integration of Microsoft Defender for Cloud with Defender XDR empowers SOC teams to tackle modern cloud threats more effectively. Hereās how: 1. Attack Paths One major challenge for CDR is the lack of context. Alerts often appear isolated, limiting security teamsā understanding of their impact or connection to the broader cloud environment. Integrating attack paths into incident graphs can improve CDR effectiveness by mapping potential routes attackers could take to reach high-value assets. This provides essential context and connects malicious runtime activity with cloud infrastructure. In Defender XDR, using its powerful incident technology, alerts are correlated into high-fidelity incidents and attack paths are included in incident graphs to provide a detailed view of potential threats and their progression. For example, if a compromised container appears on an identified attack path leading to a sensitive storage account, including this path in the incident graph provides SOC teams with enhanced context, showing how the threat could escalate. Attack path integrated into incident graph in Defender XDR, showing potential lateral movement from a compromised container. 2. Automatic and Manual Asset Criticality ClassificationāÆ In a cloud native environment, itās challenging to determine which assets are critical and require the most attention, leading to difficulty in prioritizing security efforts. Without clear visibility, SOC teams struggle to identify relevant resources during an incident. With Microsoftās automatic asset criticality, Kubernetes clusters are tagged as critical based on predefined rules, or organizations can create custom rules based on their specific needs. This ensures teams can prioritize critical assets effectively, providing both immediate effectiveness and flexibility in diverse environments. Asset criticality labels are included in incident graphs using the crown shown on the node to help SOC teams identify that the incident includes a critical asset. 3. Built-In Queries for Deeper Investigation āÆ Investigating incidents in a complex cloud-native environment can be overwhelming, with vast amounts of data spread across multiple layers. This complexity makes it difficult to quickly investigate and respond to threats. Defender XDR simplifies this process by providing immediate, actionable insights into attacker activity, cutting investigation time from hours or days to just minutes. Through the āgo huntā action in the incident graph, teams can leverage pre-built queries specifically designed for cloud and containerized threats, available at both the cluster and pod levels. These queries offer real-time visibility into data plane and control plane activity, empowering teams to act swiftly and effectively, without the need for manual, time-consuming data sifting. 4. Cloud-Native Response Actions for ContainersāÆ Attackers can compromise a cloud asset and move laterally across various environments, making rapid response critical to prevent further damage. Microsoft Defender for Cloudās integration with Defender XDR offers real-time, multi-cloud response capabilities, enabling security teams to act immediately to stop the spread of threats. For instance, if a pod is compromised, SOC teams can isolate it to prevent lateral movement by applying network segmentation, cutting off its access to other services. If the pod is malicious,it can be terminated entirely to halt ongoing malicious activity. These actions, designed specifically for Kubernetes environments, allow SOC teams to respond instantly with a single click in the Defender portal, minimizing the impact of an attack while investigation and remediation take place. New innovations for threat detection across workloads, with focused investigation and response capabilities for containersāonly with Microsoft Defender for Cloud. New innovations for threat detection across workloads, with focused investigation and response capabilities for containersāonly with Microsoft Defender for Cloud. 5. Log Collection in Advanced HuntingāÆ Containers are ephemeral and that makes it difficult to capture and analyze logs, hindering the ability to understand security incidents. To address this challenge, we offer advanced hunting that helps ensure critical logsāsuch as KubeAudit, cloud control plane, and process event logsāare captured in real time, including activities of terminated workloads. These logs are stored in the CloudAuditEvents and CloudProcessEvents tables, tracking security events and configuration changes within Kubernetes clusters and container-level processes. This enriched telemetry equips security teams with the tools needed for deeper investigations, advanced threat hunting, and creating custom detection rules, enabling faster detection and resolution of security threats. 6. Guided response with CopilotāÆ Defender for Cloud's integration with Microsoft Security Copilot guides your team through every step of the incident response process. With tailored remediation for cloud native threats, it enhances SOC efficiency by providing clear, actionable steps, ensuring quicker and more effective responses to incidents. This enables teams to resolve security issues with precision, minimizing downtime and reducing the risk of further damage. Use case scenarios In this section, we will follow some of the techniques that we have observed in real-world incidents and explore how Defender for Cloudās integration with Defender XDR can help prevent, detect, investigate, and respond to these incidents. Many container security incidents target resource hijacking. Attackers often exploit misconfigurations or vulnerabilities in public-facing apps ā such as outdated Apache Tomcat instances or weak authentication in tools like Selenium ā to gain initial access. But not all attacks start this way. In a recent supply chain compromise involving a GitHub Action, attackers gained remote code execution in AKS containers. This shows that initial access can also come through trusted developer tools or software components, not just publicly exposed applications. After gaining remote code execution, attackers disabled command history logging by tampering with environment variables like āHISTFILE,ā preventing their actions from being recorded. They then downloaded and executed malicious scripts. Such scripts start by disabling security tools such as SELinux or AppArmor or by uninstalling them. Persistence is achieved by modifying or adding new cron jobs that regularly download and execute malicious scripts. Backdoors are created by replacing system libraries with malicious ones. Once the required configuration changes are made for the malware to work, the malware is downloaded, executed, and the executable file is deleted to avoid forensic analysis. Attackers try to exfiltrate credentials from environment variables, memory, bash history, and configuration files for lateral movement to other cloud resources. Querying the Instance Metadata service endpoint is another common method for moving from cluster to cloud. Defender for Cloud and Defender XDRās integration helps address such incidents both in pre-breach and post-breach stages. In the pre-breach phase, before applications or containers are compromised, security teams can take a proactive approach by analyzing vulnerability assessment reports. These assessments surface known vulnerabilities in containerized applications and underlying OS components, along with recommended upgrades. Additionally, vulnerability assessments of container images stored in container registries ā before they are deployed ā help minimize the attack surface and reduce risk earlier in the development lifecycle. Proactive posture recommendations ā such as deploying container images only from trusted registries or resolving vulnerabilities in container images ā help close security gaps that attackers commonly exploit. When misconfigurations and vulnerabilities are analyzed across cloud entities, attack paths can be generated to visualize how a threat actor might move laterally across services. Addressing these paths early strengthens overall cloud security and reduces the likelihood of a breach. If an incident does occur, Defender for Cloud provides comprehensive real-time detection, surfacing alerts that indicate both malicious activity and attacker intent. These detections combine rule-based logic with anomaly detection to cover a broad set of attack scenarios across resources. In multi-stage attacks ā where adversaries move laterally between services like AKS clusters, Automation Accounts, Storage Accounts, and Function Apps ā customers can use the "go hunt" action to correlate signals across entities, rapidly investigate, and connect seemingly unrelated events. Attackers increasingly use automation to scan for exposed interfaces, reducing the time to breach containersāsometimes in under 30 minutes, as seen in a recent Geoserver incident. This demands rapid SOC response to contain threats while preserving artifacts for analysis. Defender for Cloud enables swift actions like isolating or terminating pods, minimizing impact and lateral movement while allowing for thorough investigation. Conclusion Microsoft Defender for Cloud, integrated with Defender XDR, transforms cloud security by addressing the challenges of modern, dynamic cloud environments. By correlating alerts from multiple workloads across Azure, AWS, and GCP, it provides SOC teams with a unified view of the entire threat landscape. This powerful correlation prevents lateral movement and escalation of threats to high-value assets, offering a deeper, more contextual understanding of attacks. Security teams can seamlessly investigate and track incidents through dynamic graphs that map the full attack journey, from initial breach to potential impact. With real-time detection, automatic alert correlation, and the ability to take immediate, decisive actionsālike isolating compromised containers or halting malicious activityāDefender for Cloudās integration with Defender XDR ensures a proactive, effective response. This integrated approach enhances incident response and empowers organizations to stop threats before they escalate, creating a resilient and agile cloud security posture for the future. Additional resources: Watch this cloud detection and response video to see it in action Try our alerts simulation tool for container security Read about some of our recent container security innovations Check out our latest product releases Explore our āÆcloud security solutions page Learn how you can unlock business value with Defender for Cloud Start a free 30-day trial of Defender for Cloud today
The Risk of Default Configuration: How Out-of-the-Box Helm Charts Can Breach Your Cluster
Authors: Michael Katchinskiy, Security Researcher, Microsoft Defender for Cloud Research Yossi Weizman, Principal Security Research Manager, Microsoft Defender for Cloud Research Have you ever used pre-made deployment templates to quickly spin up applications in Kubernetes environments? While these āplug-and-playā options greatly simplify the setup process, they often prioritize ease of use over security. As a result, a large number of applications end up being deployed in a misconfigured state by default, exposing sensitive data, cloud resources, or even the entire environment to attackers. Cloud-native applications are software systems designed to fully leverage the flexibility and scalability of the cloud. These applications are broken into small services called microservices. Usually, each service is packaged in a container with all its dependences, making it easy to deploy across different environments. Kubernetes then orchestrates these services, automatically handling their deployment, scaling, and health checks. Out-of-the-Box Helm Charts Open-source projects usually contain a section explaining how to deploy their apps āout of the boxā on their code repository. These documents often include default manifests or pre-defined Helm charts that are intended for ease of use rather than hardened security. Among other issues, two significant security concerns arise: (1) exposing services externally without proper network restrictions and (2) lack of adequate built-in authentication or authorization by default. Internet exposure in Kubernetes usually originates in a LoadBalancer service, which exposes K8s workloads via an external IP for direct access, or in Ingress objects, which manage HTTP and HTTPS traffic to internal services. If authentication is not properly configured, both can allow insecure access to the applications, leading to unauthorized access, data exposure, and potential service abuse. Consequently, default configurations that lack proper security controls create a severe security threat. Without carefully reviewing the YAML manifests and Helm charts, organizations may unknowingly deploy services lacking any form of protection, leaving them fully exposed to attackers. This is particularly concerning when the deployed application can query sensitive APIs or allow administrative actions, which is exactly what we will shortly see. Apache Pinot default configuration Apache Pinot is a real-time, distributed OLAP datastore designed for high-speed querying of large-scale datasets with low latency. For Kubernetes installations, Apache Pinotās official documentation refers users to a Helm chart stored in their official Github repository for a quick installation: While Apache Pinot's documentation states that the provided configuration is a reference setup that users may want to modify, they donāt mention that this configuration is severely insecure, leaving the users prone to data theft attacks: The default installation exposes Apache Pinotās main components to the internet by Kubernetes LoadBalancer services without providing any authentication mechanism by default. Specifically, the pinot-broker and pinot-controller services allow unauthenticated access to query the stored data and manage the workload. Below is a screenshot of Pinotās dashboard, exposed by the pinot-controller service in port 9000, allowing full management of the Apache Pinot and access to the stored information. Recently, Microsoft Defender for Cloud identified several incidents in which attackers exploited misconfigured Apache Pinot workloads, allowing them to access the data of Apache Pinot users. Not Just Apache Pinot To determine how widespread this issue is, we conducted a thorough investigation by searching using GitHub Code Search repositories for YAML files containing strings that may indicate on misconfigured workload, such as ātype: LoadBalancerā. We then sorted the results by their popularity and deployed the applications in controlled test environments to assess their default security posture. Our goal was to find out which applications are exposed to the internet by default, more critically, whether they incorporate any authentication or authorization mechanisms. Here's what we found: The majority of applications we evaluated had at least some form of basic password protection, though the strength and reliability of these measures varied significantly. A small but critical group of applications either provided no authentication at all or used a predefined user and password for logging in, making them prime targets for attackers. Sign me up Several applications appeared secure at first glance, but they allowed anyone to create a new account and access the system. This clearly does not provide effective protection when exposed to the internet. This highlights how a ādefault by convenienceā approach can invite risk when security settings are not thoroughly reviewed or properly configured. Meshery is an engineering platform for collaborative design and operation of cloud native infrastructure. By default, when installing Meshery on your Kuberentes cluster via the official Helm installation, the appās interface is exposed via an external IP address. We discovered that anyone who can access the external IP address can sign up with a new user and access the interface which provides extensive visibility into cluster activities and even enable the deployment of new pods. These capabilities grant attackers a direct path to execute arbitrary code and gain control of underlying resources if Meshery is not secured or restricted to internal networks only. Selenium Grid Selenium is a popular tool for automating web browser testing, with millions of downloads of its container image. In the last few months, weāve observed multiple attack campaigns specifically targeting Selenium Grid instances that lack authentication. In addition several security vendors, including Wiz and Cado Security, have reported these attacks. While the official Helm chart for Selenium Grid doesnāt expose it to the internet, there are several widely referenced GitHub projects that do - using a LoadBalancer or a NodePort. In one Selenium deployment example from the official Kubernetes repository, Selenium is set up to use a NodePort. This configuration exposes the service on a specific port across all nodes in your cluster, meaning that the firewall rules set up in your network security group become your primary and often only line of defense. If you'd like to see additional examples, try using GitHub Code Search with this query. Awareness of the risks associated with exposing services has grown over the years, and many developers today understand the dangers of leaving applications wide open. Even so, some applications simply werenāt built for external access and donāt provide any built-in authentication. Their own documentation often warns users not to expose these services publicly. Yet, it still happens, usually for convenience, leaving entire clusters at risk. If you still remain unconvinced, look to the countless unsecured Redis, Elasticsearch, Prometheus, and other instances that are regularly surfaced in Shodan scans and security blog posts. Despite years of warnings, these applications are still being exposed. Conclusion Many in-the-wild exploitations of containerized applications originate in misconfigured workloads, often when using default settings. Relying on ādefault by convenienceā setups pose a significant security risk. To mitigate these risks, it is crucial to: Review before you deploy: Donāt rely on default configurations. Review the configuration files and modify them according to security best practices. This includes enforcing strong authentication mechanism and network isolation. Regularly scan your organization to exposed services: Scan the publicly facing interfaces of your workloads. While some workloads should allow access from external endpoints, in many cases this exposure should be reconsidered. Monitor your containerized applications: Monitor the running containers in your environment for malicious and suspicious activities. This includes monitoring of the running processes, network traffic, and other activities performed by the workload. Also, many container-based attacks involve deployment of backdoor containers in the cluster. Monitor the Kubernetes cluster for unknown workloads and the nodes for unknown pulled images. Strengthening Cluster Security with Microsoft Defender for Cloud Microsoft Defender for Cloud (MDC) helps protect your environment from misconfigurations, including risky service exposure. For example, MDC alerts on the exposure of Kubernetes services which are associated with sensitive interfaces, including Apache Pinot. With Microsoft Defender CSPM, you can get an overview of the exposure of your organizationās cloud environment, including the containerized applications. Using the Cloud Security Explorer, you can get full visibility of the internet exposed workloads in your Kubernetes clusters, enabling you to mitigate potential risks and easily identify misconfiguration. Read more about Containers security with Microsoft Defender for containers here.RSACā¢ 2025: Unveiling new innovations in cloud and AI security
The world is transforming with AI right in front of our eyes ā reshaping how we work, build, and defend. But as AI accelerates innovation, itās also amplifying the threat landscape. The rise of adversarial AI is empowering attackers with more sophisticated, automated, and evasive tactics, while cloud environments continue to be a prime target due to their complexity and scale. From prompt injection and model manipulation in AI apps to misconfigurations and identity misuse in multi-cloud deployments, security teams face a growing list of risks that traditional tools canāt keep up with. As enterprises increasingly build and deploy more AI applications in the cloud, it becomes crucial to secure not just the AI models and platforms, but also the underlying cloud infrastructure, APIs, sensitive data, and application layers. This new era of AI requires integrated, intelligent security that continuously adaptsāprotecting every layer of the modern cloud and AI platform in real time. This is where Microsoft Defender for Cloud comes in. Defender for Cloud is an integrated cloud native application protection platform (CNAPP) that helps unify security across the entire cloud app lifecycle, using industry-leading GenAI and threat intelligence. Providing comprehensive visibility, real-time cloud detection and response, and proactive risk prioritization, it protects your modern cloud and AI applications from code to runtime. Today at RSACā¢ 2025, weāre thrilled to unveil innovations that further bolster our cloud-native and AI security capabilities in Defender for Cloud. Extend support to Google Vertex AI: multi-model, multi-cloud AI posture management In todayās fast-evolving AI landscape, organizations often deploy AI models across multiple cloud providers to optimize cost, enhance performance, and leverage specialized capabilities. This creates new challenges in managing security posture across multi-model, multi-cloud environments. Defender for Cloud already helps manage the security posture of AI workloads on Azure OpenAI Service, Azure Machine Learning, and Amazon Bedrock. Now, weāre expanding those AI security posture management (AI-SPM) capabilities to include Google Vertex AI models and broader support for the Azure AI Foundry model catalog and custom models ā as announced at Microsoft Secure. These updates make it easier for security teams to discover AI assets, find vulnerabilities, analyze attack paths, and reduce risk across multi-cloud AI environments. Support for Google Vertex AI will be in public preview starting May 1, with expanded Azure AI Foundry model support available now. Strengthen AI security with a unified dashboard and real-time threat protection At Microsoft Secure, we also introduced a new data and AI security dashboard, offering a unified view of AI services and datastores, prioritized recommendations, and critical attack paths across multi-cloud environments. Already available in preview, this dashboard simplifies risk management by providing actionable insights that help security teams quickly identify and address the most urgent issues. The new data & AI security dashboard in Microsoft Defender for Cloud provides a comprehensive overview of your data and AI security posture. As AI applications introduce new security risks like prompt injection, sensitive data exposure, and resource abuse, Defender for Cloud has also added new threat protection capabilities for AI services. Based on the OWASP Top 10 for LLMs, these capabilities help detect emerging AI-specific threats including direct and indirect prompt injections, ASCII smuggling, malicious URLs, and other threats in user prompts and AI responses. Integrated with Microsoft Defender XDR, the new suite of detections equips SOC teams with evidence-based alerts and AI-powered insights for faster, more effective incident response. These capabilities will be generally available starting May 1. To learn more about our AI security innovations, see our Microsoft Secure announcement. Unlock next level prioritization for cloud-to-code remediation workflows with expanded AppSec partnerships As we continue to expand our existing partner ecosystem, weāre thrilled to announce our new integration between Defender for Cloud and Mend.io ā a major leap forward in streamlining open source risk management within cloud-native environments. By embedding Mend.ioās intelligent Software Composition Analysis (SCA) and reachability insights directly into Defender for Cloud, organizations can now prioritize and remediate the vulnerabilities that matter mostāwithout ever leaving Defender for Cloud. This integration gives security teams the visibility and context they need to focus on the most critical risks. From seeing SCA findings within the Cloud Security Explorer, to visualizing exploitability within runtime-aware attack paths, teams can confidently trace vulnerabilities from code to runtime. Whether you work in security, DevOps, or development, this collaboration brings a unified, intelligent view of open source risk ā reducing noise, accelerating remediation, and making cloud-native security smarter and more actionable than ever. Advance cloud-native defenses with security guardrails and agentless vulnerability assessment Securing containerized runtime environments requires a proactive approach, ensuring every component ā services, plugins, and networking layers ā is safeguarded against vulnerabilities. If ignored, security gaps in Kubernetes runtime can lead to breaches that disrupt operations and compromise sensitive data. To help security teams mitigate these risks proactively, we are introducing Kubernetes gated deployments in public preview. Think of it as security guardrails that prevent risky and non-compliant images from reaching production, based on your organizational policies. This proactive approach not only safeguards your environment but also instills confidence in the security of your deployments, ensuring that every image reaching production is fortified against vulnerabilities in Azure. Learn more about these new capabilities here. Additionally, weāve enhanced our agentless vulnerability assessment, now in public preview, to provide comprehensive monitoring and remediation for container images, regardless of their registry source. This enables organizations using Azure Kubernetes Service (AKS) to gain deeper visibility into their runtime security posture, identifying risks before they escalate into breaches. By enabling registry-agnostic assessments of all container images deployed to AKS we are expanding our coverage to ensure that every deployment remains secure. With this enhancement, security teams can confidently run containers in the cloud, knowing their environments are continuously monitored and protected. For more details, visit this page. Security teams can audit or block vulnerable container images in Azure. Uncover deeper visibility into API-led attack paths APIs are the gateway to modern cloud and AI applications. If left unchecked, they can expose critical functionality and sensitive data, making them prime targets for attackers exploiting weak authentication, improper access controls, and logic flaws. Today, weāre announcing new capabilities that uncover deeper visibility into API risk factors and API-led attack paths by connecting the dots between APIs and compute resources. These new capabilities help security teams to quickly catch critical API misconfigurations early on to proactively address lateral movement and data exfiltration risks. Additionally, Security Copilot in Defender for Cloud will be generally available starting May 1, helping security teams accelerate remediation with AI-assisted guidance. Learn more Defender for Cloud streamlines security throughout the cloud and AI app lifecycle, enabling faster and safer innovation. To learn more about Defender for Cloud and our latest innovations, you can: Visit our Cloud Security solution page. Join us at RSACā¢ and visit our booth N - 5744. Learn how you can unlock business value with Defender for Cloud. Get a comprehensive guide to cloud security. Start a 30-day free trial.How to demonstrate the new containers features in Microsoft Defender for Cloud
On this blog post we will focus on how to simulate alerts that are part of the AKS advanced threat Detection and how to simulate scanning for a vulnerable container image to an Azure Container Registry (ACR) and present its recommendation in Microsoft Defender for Cloud.Secure containers software supply chain across the SDLC
In todayās digital landscape, containerization is essential for modern application development, but it also expands the attack surface with risks like vulnerabilities in base images, misconfigurations, and malicious code injections. Securing containers across their lifecycle is critical. Microsoft Defender for Cloud delivers end-to-end protection, evaluating threats at every stageāfrom development to runtime. Recent advancements further strengthen container security, making it a vital solution for safeguarding applications throughout the Software development lifecycle (SDLC). Container software development lifecycle The lifecycle of containers involves several stages, during which the container evolves through different software artifacts. Container software supply chain It all starts with a container or docker script file, created or edited by developer in development phase, submitted into the code repository. Script file converts into a container image during the build phase via the CI/CD pipeline, submitted into container registry as part of the ship phase When a container image is deployed into a Kubernetes cluster, it transforms into running, ephemeral container instances, marking the transition to the runtime phase. A container may encounter numerous challenges throughout its transition from development to runtime. Ensuring its security requires maintaining visibility, mitigating risks, and implementing remediation measures at each stage of its journey. Microsoft Defender for Cloud's latest advancements in container security assist in securing your container's journey and safeguarding your containerized environments Command line interface (CLI) tool for container image scanning at build phase, is now in public preview Integrating security into every phase of your software development is crucial. To effectively incorporate container security evaluation early in the container lifecycle, particularly during the development phase, and to seamlessly integrate it into diverse DevSecOps ecosystems, the use of a Command Line Interface (CLI) is essential. This new capability of Microsoft Defender for Cloud provides an alternative method for assessing container image for security findings. This capability, available through a CLI abstract layer, allows for seamless integration into any tool or process, independently of Microsoft Defender for Cloud portal. Key purpose of Microsoft Defender for Cloud CLI: Expanding container security to cover the development phase, code repository phase, and CI/CD phase: o Development phase: Developers can scan container images locally on Windows, Linux, or Mac OS using PowerShell or any scripting terminal. o Code repository phase: Integrate the CLI into code repositories with webhook integrations like GitHub actions to scan and potentially abort pull requests based on findings. o CI/CD phase: Scan container images in the CI/CD pipeline to detect and block vulnerabilities during the build stage. Invoke scanning on-demand for specific container images. Integrate easily into existing DevSecOps processes and tools. For more details watch the demo CLI demo How it works Microsoft Defender for Cloud CLI requires authentication through API tokens. These tokens are managed via the Integrations section in the Microsoft Defender for Cloud Portal, by Security Administrators. Figure 3: API push tokens management The CLI supports Microsoft proprietary and third-party engines like Trivy, enabling vulnerability assessment of container images and generating results in SARIF format. It integrates with Microsoft Defender for Cloud for further analysis and helps incorporate security guardrails early in development. Additionally, it provides visibility of container artifacts' security posture from code to runtime and context essential for security issues remediations such as artifact owner and repo of origin. For more details, setup guides, and use cases, please refer to official documentation. Vulnerabilities assessment of container images in third party registries, now in public preview Container registries are centralized repositories used to store container images for the ship phase, prior deployment to Kubernetes clusters. They play an essential role in the container's software supply chain and accessing container images for vulnerabilities at this phase might be the last chance to prevent vulnerable images from reaching your production runtime environments. Many organizations use a mix of cloud-native (ACR, ECR, GCR, GAR) and 3 rd party container registries. To enhance coverage, Microsoft Defender for Cloud now offers vulnerability assessments for third-party registries like Docker Hub and Jfrog Artifactory. These are popular 3 rd party container registries. You can now integrate them into your Microsoft Defender for Cloud tenant to scan container images for security vulnerabilities, improving your organization's coverage of the container software supply chain. This integration offers key benefits: Automated vulnerability scanning: Automatically scans container images for known vulnerabilities, helping identify and fix security issues early. Continuous monitoring: Ensures that new vulnerabilities are promptly detected and addressed. Compliance management: Assists organizations in maintaining compliance by providing detailed security posture reports on container images and resources. Actionable security recommendations: Provides recommendations based on best practices to improve container security. Figure 4: Docker Hub & Jfrog Artifactory environments Figure 5: Jfrog Artifactory container images in Security Explorer To learn more please refer to official documentation for Docker Hub and Jfrog Artifactory. Azure Kubernetes Service (AKS) security dashboard for cluster admin view, now in public preview, provides granular visibility into container security directly within the AKS portal Microsoft Defender for Cloud aims to provide security insights relevant to each audience in the context of their existing tools & process, helping various roles prioritize security and build secure software applications essential to ensure your containers security across SDLC. To learn more please explore AKS Security Dashboard Conclusion Microsoft Defender for Cloud introduces groundbreaking advancements in container security, providing a robust framework to protect containerized applications. With integrated vulnerability assessment, malware detection, and comprehensive security insights, organizations can strengthen their security posture across the software development lifecycle (SDLC). These enhancements simplify security management, ensure compliance, and offer risk prioritization and visibility tailored to different audiences and roles. Explore the latest innovations in Microsoft Defender for Cloud to safeguard your containerized environments- New Innovations in Container Security with Unified Visibility and Investigations.Unveiling Kubernetes lateral movement and attack paths with Microsoft Defender for Cloud
The cloud security landscape is constantly evolving and securing containerized environments including Kubernetes is a critical piece of the puzzle. Kubernetes environments provide exceptional flexibility and scalability, which are key advantages for modern infrastructure. However, the complex and intricate permissions structure of Kubernetes, combined with the dynamic, ephemeral nature of containers, introduces significant security challenges. Misconfigurations in permissions can easily go unnoticed, creating opportunities for unauthorized access or privilege escalation. The rapid lifecycle of resources in Kubernetes adds to the complexity of this issue, making it harder to maintain visibility and enforce a consistent security posture. Traditional security tools often lack the depth needed to map and analyze Kubernetes permissions effectively, leaving organizations vulnerable to security gaps. In this blog we will explore how Microsoft Defender for Cloud provides visibility to address these challenges with the recent addition of Kubernetes role-based access control (RBAC) into the cloud security graph. We'll analyze potential techniques attackers use to move laterally in Kubernetes environments and demonstrate how Microsoft Defender for Cloud provides visibility to these threats as attack paths. Finally, we will demonstrate how this advanced feature allows customers to identify Kubernetes RBAC bindings that don't follow security best practices with the security explorer capabilities. Enhancing Security with Kubernetes RBAC Integration into the cloud security graph Defender for Cloud uses a cloud security graph to represent the data of your multicloud environment. This graph-based engine analyzes data on your cloud assets and their security posture, providing contextual analysis, attack path insights, and identify security risks with queries in the cloud security explorer. The introduction of Kubernetes RBAC into the cloud security graph addresses the visibility and security challenges posed by Kubernetes' complex permissions structure and dynamic workloads. By ingesting Kubernetes RBAC objects into the graph as nodes and edges, we create a more comprehensive picture of Kubernetes environmentās security posture. The cloud security graph leverages Kubernetes RBAC to map relationships between Kubernetes identities, Kubernetes objects, and cloud identities. This functionality uncovers additional attack paths and equips customers to proactively identify and mitigate threats in their cloud environments. Revealing attackers techniques Visualizing potential lateral movement within a Kubernetes cluster can be challenging. Attackers who establish an initial foothold in the cluster may exploit various techniques to move laterally, accessing sensitive resources within the cluster and even extending to other cloud resources in the victim's environment. Letās examine the techniques attackers use for lateral movement in Kubernetes environments and explore how identifying new attack paths, along with the factors enabling such movement, can support proactive threat remediation. Inner cluster lateral movement In Kubernetes, each pod is attached to a Kubernetes service account that determines the permissions of the pod in the cluster. By default, the service account associated with a pod allows it to interact with the Kubernetes API with minimal permissions, but it is often granted more privileges than required for its specific function. Attackers who compromise a container can exploit the container podās service account RBAC permissions to move laterally within the cluster and access sensitive resources. For instance, if the compromised service account has impersonation privileges, attackers can use them to act as a more privileged service account by leveraging impersonation headers, potentially leading to a full cluster takeover. Cluster to cloud lateral movement In addition to lateral movement inside Kubernetes clusters, attackers could also use additional techniques to move laterally from the managed Kubernetes clusters to the cloud. Using the Instance Metadata Service (IMDS) In managed Kubernetes environments, each worker node is assigned a specific cloud identity or IAM role that gives it the necessary permissions to interact with the cloud provider's API to perform tasks that maintain cluster operations (such as autoscaling). To do this, the worker node can access the Instance Metadata Service (IMDS), which provides important details like configurations, settings, and the identity credentials of the node. The IMDS is accessible through a special IPv4 link-local address (169.254.169.254), allowing the worker node to securely retrieve its credentials and perform its tasks. If attackers gains control of a container in a managed Kubernetes cluster, they may attempt to query the IMDS endpoint to assume the IAM role or identity credentials associated with the worker node hosting the container. These credentials can then be exploited to access cloud resources, such as databases or compute instances outside the cluster. The potential damage caused by such an attack depends on the permissions of the worker node identity. 2. Using the workload identity Workload identity in Azure, Google Cloud, and AWS as IAM Roles for Service Accounts (IRSA) or EKS Pod Identity, allows Kubernetes pods to authenticate to cloud services using cloud-native identity mechanisms without needing to manage long-lived credentials like API keys. In this setup, a pod is associated with a Kubernetes service account that is linked to a cloud identity (e.g., a GCP service account, Managed identity for Azure resources, or AWS IAM role), enabling the pod to access cloud resources securely. While this integration enhances security, if attackers compromise a pod that is using workload identity, they could exploit the cloud identity associated with that pod to access cloud resources. Depending on the permissions granted to the cloud identity or IAM role, the attackers could perform actions like reading sensitive data from cloud storage, interacting with databases, or even modifying infrastructureāpotentially escalating the attack beyond the Kubernetes environment into the cloud platform itself. Cloud to cluster lateral movement In cloud environments, managing access to Kubernetes clusters is critical to maintaining security. Cloud identities who are granted high-level permissions over Kubernetes clusters pose a potential security risk. If these identities have elevated permissionsāsuch as the ability to create or modify resources within the clusterāan attacker who compromises their credentials can leverage these permissions to take full control of the cluster. Once attackers gain access to a privileged cloud account, they could manipulate Kubernetes configurations, create malicious workloads, or access sensitive data. This scenario could lead to a complete cluster takeover. Using Defender for Cloud to prevent lateral movement Defender for Cloud provides organizations with instant visibility into potential attack paths that attackers could exploit to move laterally within their cluster, enabling them to take preventive actions before an attack occurs. In the example shown in figure 1, an attack path is being generated to highlight how a vulnerable container can be exploited by an attacker to move laterally within the cluster and eventually achieve a full cluster takeover. This involves remotely compromising the vulnerable container, leveraging the Kubernetes service account linked to the pod, and impersonating a more privileged service account to gain control over the cluster. In another example, as shown in figure 2, the attack path illustrates how an attacker can exploit a vulnerable container to move laterally from the cluster to cloud resources outside of it by leveraging the pod service account's associated cloud identity. With the visibility provided by these attack paths, security teams can take actions prior to an attack taking place i.e. block external access to the container unless absolutely required, ensure the vulnerability is addressed and verify if the pod service account permissions are indeed required. Kubernetes risk hunting with the cloud security explorer In addition to the attack paths capabilities, Defender for Cloud's contextual security capabilities assist security teams in reducing the risk of Kubernetes RBAC misconfigurations. By executing graph-based queries on the cloud security graph using the cloud security explorer, security teams can proactively identify risks within a multicloud Kubernetes environments. By utilizing the query builder, teams can search for and locate risks associated with Kubernetes identities and workloads, enabling them to preemptively address potential threats. The cloud security explorer provides you with the ability to perform proactive exploration, along with built-in query templates that are dedicated to Kubernetes RBAC risks. Kubernetes query templates Beyond cloud security As the cloud security graph is part of Microsoft enterprise exposure graph, customers can gain further visibility beyond the cloud boundary. By using Microsoft enterprise exposure management, customers will be able to see not only the lateral movement from K8s to the cloud and vice versa, but also how the identities used by the attacker can be further used to move laterally to additional assets in the organization, and how breach of an on-prem asset can lead to lateral movement to Kubernetes assets in the cloud. In the example shown in figure 4, we have an attack path that highlights how a vulnerable device can be exploited by an attacker to move laterally from an on-prem environment to Kubernetes cluster located in the cloud. This process includes remotely compromising the vulnerable device, extracting the browser cookie stored on it, and using that cookie to authenticate as a cloud identity with elevated permissions to access a Kubernetes cluster in the cloud. Conclusion - A brighter future for Kubernetes security The introduction of Kubernetes RBAC into the cloud security graph represents a significant advancement in securing Kubernetesā environments. By providing comprehensive visibility into the complex permissions structure and dynamic workloads of Kubernetes, Microsoft Defender for Cloud enables organizations to proactively identify and mitigate potential security risks. This enhanced visibility not only helps in uncovering new attack paths and lateral movement threats but also supports the enforcement of security best practices within Kubernetes clusters. To start leveraging these new features in Microsoft Defender for Cloud, ensure either Defender for Container or Defender CSPM is enabled in your cloud environments. For additional guidance or support, visit our deployment guide. Learn more If you havenāt already, check out our previous blog post that introduced this journey: Elevate Your Container Posture: From Agentless Discovery to Risk Prioritization.Microsoft Defender for Cloud Customer Newsletter
What's new in Defender for Cloud? Baseline Linux feature has been updated to improve its accuracy and coverage. For more information, please visit this page. Container vulnerability assessment enhancements Containers Vulnerability Assessment scanning, powered by MDVM, has the following updates: Support for PHP, Ruby and Rust programming languages, extended Java Language support including exploded JARs and improved memory usage. For more details, please refer to our announcement. Blogs of the month In January, our team published the following blog posts we would like to share: Considerations for risk identification and prioritization Elevating Runtime Protection Bringing AppSec and CloudSec Together: MDC integrates with Endor Labs Boost security with API Posture Management GitHub Community Activate Defender for Servers on a resource level with this PowerShell script. Visit our GitHub page for more content! Defender for Cloud in the field Watch the latest Defender for Cloud in the Field YouTube episodes here: Onboarding Docker Hub and JFrog Artifactory New AKS Security Dashboard in MDC Visit our YouTube page! Customer journeys Discover how other organizations successfully use Microsoft Defender for Cloud to protect their cloud workloads. This month we are featuring Mia Labs, Inc., a conversational AI virtual assistant startup for auto dealerships. Mia Labs, Inc., leverages OpenAI enriched with Azure AI technologies to help identify sales and service opportunities within the automotive industry. Further, they use Defender for Cloud to provide contextual AI security posture management via CSPM capabilities and protects AI workloads with runtime security alerts. Together, Mia Labs, Inc., was able to detect numerous jailbreak attacks, one of the most common threats to generative AI systems. Security community webinars Join our experts in the upcoming webinars to learn what we are doing to secure your workloads running in Azure and other clouds. Check out our upcoming webinars this month in the link below! I would like to register Watch past webinars 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
