Agentless scanning for virtual machines in the cloud – technical deep dive
Over the past three years, a notable shift has unfolded in the realm of cloud security. Increasingly, security vendors are introducing agentless scanning solutions to enhance the protection of their customers. These solutions empower users with visibility into their security posture and the ability to detect threats — all achieved without the need to install any additional software, commonly referred to as an agent, onto their workloads.
Defender for cloud's Agentless secret scanning for virtual machines is now generally available!
Cloud cybersecurity is of paramount importance in today's digital landscape, as organizations increasingly rely on cloud services to store and manage sensitive data, applications, and infrastructure. Attacks on cloud infrastructure pose severe risks to organizations such as data theft, ransomware attacks, crypto mining attacks, and service disruption. During a cyber-attack, after gaining initial access to the target network, the attacker begins to move deeper into the network in search of sensitive data and other high-value assets. This stage, called lateral movement, is critical, as it enables threat actors to explore and expand their presence within a target network, increasing the potential for further compromise of critical systems. One of the most common techniques used by hackers to move laterally in a network is credential theft. This technique involves the exploitation of exposed secrets such as passwords, keys, tokens, and connection strings to gain access to additional assets in the network. Secrets are often found on files, stored on the disks of virtual machines (VMs) or containers running on various cloud platforms. The exposed secrets challenge: Having exposed secrets can happen due to the following reasons: Lack of awareness: Some organizations may not be aware of the risks and consequences of exposing secrets in their cloud environment. They may not have a clear policy or guidance on how to handle and protect secrets in their code and configuration files. Lack of discovery tools: due to missing tools or processes to detect and remediate secrets leaks. Complexity and speed: Modern software development is complex and fast-paced, relying on multiple cloud platforms, open-source software, and third-party code. Developers may use secrets to access and integrate various resources and services in their cloud environment. They may also store secrets in their source code repositories for convenience and reuse. It can lead to accidental exposure of secrets in public or private repositories, or during data transfer or processing. Trade-off between security and usability: Some organizations may choose to keep secrets exposed in their cloud environment for usability reasons, to avoid the complexity and latency of encrypting and decrypting data at rest and in transit. This can compromise the security and privacy of their data and credentials. Defender for cloud's Agentless secret scanning for virtual machines: The agentless secret scanning is designed to assist in mitigating the risk of lateral movement. It broadens the coverage of cloud assets, enabling quick detection, prioritization, and remediation of exposed secrets. Utilizing cloud APIs, it captures snapshots of your disks and conducts an out-of-band analysis, ensuring no impact on your virtual machines' performance. In addition, it identifies a variety of secrets across Azure, AWS, and GCP and provides practical suggestions for the following mitigations: Elimination of unnecessary secrets. Apply the Principle of Least Privilege. Strengthening the security of your secrets by employing secret management systems such as Azure Key Vault when possible. Usage of short-lived secrets, such as substituting Azure Storage connection strings with SAS tokens that possess shorter validity periods. Onboarding: Knowing that assets’ coverage plays crucial roles, we created a straightforward, easy onboarding experience – just one click, and all assets under the specified subscription is covered by our agentless scanning capability Agentless scanning configuration within the Defender for Servers settings Detection and prioritization: Microsoft’s secrets detection engine can identify a wide range of secret types, such as tokens, passwords, keys, or credentials, that are stored in different file types within the OS file system. After collecting the necessary file and secrets’ metadata from the disk, it sends them to the Defender for cloud portal. Prioritizing secrets can be a daunting task. You may wonder which secrets are the riskiest and require immediate attention. To evaluate the severity and urgency of each secret we detected, we provide: Rich metadata for every secret we detect such as the file’s last access time, token expiration date, an indication if the target resource that the secret provides access to exists and more. We also combine the secrets’ metadata with the assets cloud context, helping you to start with assets that are exposed to the internet and contain secrets that may compromise other sensitive assets. We are happy to announce that the secrets scanning findings will be also incorporated into our new DCSPM risk-based approach to prioritize recommendation and enhance attack path analysis. We have developed multiple views to assist you in pinpointing the most commonly found secrets or assets containing secrets. This enables a prioritized approach towards the elimination of exposed secrets. Security Recommendations: Enhanced recommendation experience aggregated by secret type The security recommendations for secrets offer a consolidated view of the detected secrets, including details such as the file location of the secrets, the last access time, an indicator if the target resource that the secret provides access to exists, and more. Attack Path: In this attack scenario, our scanner identified an AWS access key on the disk of an GCP VM instance. It was then able to pinpoint the AWS S3 bucket that the key could authenticate to. Leveraging the capabilities of Microsoft Defender CSPM, the attack path revealed that the initial GCP VM instance has a critical vulnerability and is exposed to the internet. This comprehensive context equips you with the necessary information for effective risk assessment and prioritization. Cloud Security Explorer: Use the cloud security explorer to search for plaintext secrets Secret’s tab (inventory): Use the secret's tab to view all secrets detected for a specified virtual machine We are thrilled to announce that the Agentless secret scanning for virtual machines is now GA for Defender CSPM and Defender for Servers P2 plans. To start using this new feature, ensure that agentless scanning under the environment settings is enabled for the relevant subscriptions. For customers who have already enabled the agentless scanning, there’s no further action needed. To learn more regarding the prerequisites, detection, capabilities and more, please refer the following documentation.
Elevate Your Container Posture: From Agentless Discovery to Risk Prioritization
As Kubernetes (K8s) continue to power modern containerized applications, the complexity of managing and securing these environments grows exponentially. The challenges in monitoring K8s environments stem not only from their dynamic nature but also from their unique structure—each K8s cluster operates as its own ecosystem, complete with its own control plane for authorization, networking, and resource management. This makes it fundamentally different from traditional cloud environments, where security practitioners often have established expertise and tools for managing the cloud control plane. The specialized nature of Kubernetes (K8s) environments limits the visibility and control available to many security teams, resulting in blind spots that increase the risk of misconfigurations, compliance gaps, and potential attack paths gaining comprehensive visibility into the posture state of K8s workloads is essential for addressing these gaps and ensuring a secure, resilient infrastructure. Key benefits By further expanding agentless container posture approach, Defender for Cloud delivers the following key benefits: Enhanced risk management: improved prioritization through additional security insights, networking information, K8s RBAC, and image evaluation status, ensuring more critical issues can addressed first. Proactive security posture: gain comprehensive insights and prevent lateral movement within Kubernetes clusters, helping to identify and mitigate threats before they cause harm. Comprehensive compliance and governance: achieve full transparency into software usage and Kubernetes RBAC configurations to meet compliance requirements and adhere to industry standards. Release features overview: Enhanced K8s workload modeling To ensure customers can better focus on security findings, and avoid reviewing stale information, Defender for Cloud now models K8s workloads in the security graph based on their configuration (K8s specification) rather than runtime assets. This improvement avoids refresh-rate discrepancies, providing a more accurate and streamlined view of your K8s workloads, with single security findings for all identical containers within the same workload. New Security Insights for Containers and Pods Security teams that use the security explorer to proactively identify security risks in their multicloud environments, now get even better visibility with additional security insights for containers and pods, including privileged containers, sensitive mounts, and more. For example, security practitioners can use the security explorer to find all containers vulnerable to remote code execution, which are also exposed to the internet and uses sensitive host mounts, to eliminate the misconfigurations and vulnerabilities before a potential attacker abuse them to attack the container remotely and break-out into the host through the sensitive host mount. Extended K8s Networking Information To enable customers to query the security graph based on additional characters of K8s networking and better understand exposure details for K8s workloads, Defender for Cloud now offers extended data collection for both K8s ingresses and services. This feature also includes new properties such as service port and service selectors. The following figure shows all new networking criteria that customers can now use to query for K8s networking configuration: The following figure show detailed exposure information on a K8s workload exposed to the internet: Enhanced image discovery Customers can now gain complete visibility to all images used in customer environments using the security explorer, including images from all supported registries, and any image running in K8s, regardless of whether the image is scanned for vulnerabilities, with extended information per image. Here are a few examples for important use cases that customers can detect and respond to action on through a single query in the security explorer: Detect usage of images from unmonitored registries: Figure 4: images deployed directly from an unscanned docker registry Check the presence of specific image in the environment Figure 5: search for an image with a specific digest Trace all images not evaluated for vulnerabilities Figure 6: all images not assessed for vulnerabilities K8s RBAC in the security graph The addition of K8s RBAC into the security graph serves two main purposes: Security practitioners gain easy visibility into K8s service accounts, their permissions, and their bindings with K8s workloads, without prior expertise, and hunt for service accounts that do not meet security best practices. In the following example, a service account that has full cluster permissions: Figure 7: example of service account cluster admin permissions on cluster level The security graph contextual analysis uses the K8s RBAC to identify lateral movement internally within K8s, from K8s to other cloud resources and from the cloud to K8s. The following example shows an attack path starting from a container exposed to the internet with a vulnerability that can be remotely exploited. It also has access to a managed identity allowing the attacker to move all the way to a critical storage account: Figure 8: attack path from a vulnerable exposed container to a critical storage account Comprehensive Software Inventory for Containers A detailed software inventory is now available for all container images and containers scanned for vulnerabilities, serving security practitioners and compliance teams in many ways: Full visibility to all software packages used in container images and containers: Figure 9: Full software list for images and containers Query specific software usage across all environments, making it easier to identify risks or ensure compliance. A common example of this use case includes a vulnerable software version with a zero-day vulnerability. For example, following the OpenSSL zero-day vulnerability publication, a security admin can use the following queries to find all instances of container images within the organization using OpenSSL version 3.0, even before a CVE was published: Figure 10: search for a specific vulnerable open ssl version Critical Asset Protection for K8s Critical asset protection has been enhanced to cover additional container use cases: Defender for cloud customers can now define rules to mark workloads as critical based on their namespace and K8s labels. The following figure shows how customers can define rules that would automatically tag critical workloads based on their K8s labels: Figure 11: customer defined rules for asset criticality based on K8s labels Predefined rules allow K8s clusters to be flagged as critical, ensuring prioritized focus during risk assessments. Example for one of the predefined rules that automatically tags K8s clusters as critical: Figure 12: Example for predefined K8s cluster criticality rules As with other asset protection features in Defender for Cloud, these updates seamlessly integrate into the risk prioritization, attack path analysis, and security explorer workflows. The following example shows a critical attack path where the attack target is critical K8s cluster: Figure 13: Critical attack path where the target is a critical K8s cluster K8s CIS benchmark Customers that would like to audit their K8s clusters for regulatory compliance using K8s CIS or enforce security controls that are part of the K8s CIS standard, now benefit from updated K8s CIS standards with broader security controls, with K8s CIS 1.5.0 for AKS, and EKS and K8s CIS 1.6.0 for GKE. To start using the new standards and controls, enable the desired K8s CIS standard through regulatory compliance dashboard, or via security policies: Figure 14: Enabling K8s CIS 1.6.0 for GKE Compliance status can then be monitored via the regulatory compliance dashboard for the relevant K8s CIS standard: Figure 15: Viewing K8s CIS 1.5.0 compliance status Get Started Today 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. With these updates, we’re committed to helping you maintain a robust, secure, and scalable cloud-native environment. Learn More If you haven’t already, check out our previous blog post that introduced this journey: New Innovations in Container Security with Unified Visibility and Investigations. This new release continues to build on the foundation outlined in that post. With “Elevate your container posture: from agentless discovery to risk prioritization”, we’ve delivered capabilities that allow you to further strengthen your container security practices, while reducing operational complexities.Closing the loop on container security: From code to runtime in the AI era
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. 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. 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.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)Unlocking API visibility: Defender for Cloud Expands API security to Function Apps and Logic Apps
APIs are the front door to modern cloud applications and increasingly, a top target for attackers. According to the May 2024 Gartner® Market Guide for API Protection: “Current data indicates that the average API breach leads to at least 10 times more leaked data than the average security breach.” This makes comprehensive API visibility and governance a critical priority for security teams and cloud-first enterprises. We’re excited to announce that Microsoft Defender for Cloud now supports API discovery and security posture management for APIs hosted in Azure App Services, including Function Apps and Logic Apps. In addition to securing APIs published behind Azure API Management (APIM), Defender for Cloud can now automatically discover and provide posture insights for APIs running within serverless functions and Logic App workflows. Enhancing API security coverage across Azure This new capability builds on existing support for APIs behind Azure API Management by extending discovery and posture management to APIs hosted directly in compute environments like Azure Functions and Logic Apps, areas that often lack centralized visibility. By covering these previously unmonitored endpoints, security teams gain a unified view of their entire API landscape, eliminating blind spots outside of the API gateway. Key capabilities API discovery and inventory Automatically detect and catalog APIs hosted in Function Apps and Logic Apps, providing a unified inventory of APIs across your Azure environment. Shadow API identification Uncover undocumented or unmanaged APIs that lack visibility and governance—often the most vulnerable entry points for attackers. Security posture assessment Continuously assess APIs for misconfigurations and weaknesses. Identify unused or unencrypted APIs that could increase risk exposure. Cloud Security Explorer integration Investigate API posture and prioritize risks using contextual insights from Defender for Cloud’s Cloud Security Explorer. Why API discovery and security are critical for CNAPP For security leaders and architects, understanding and reducing the cloud attack surface is paramount. APIs, especially those deployed outside of centralized gateways, can become dangerous blind spots if they’re not discovered and governed. Modern cloud-native applications rely heavily on APIs, so a Cloud-Native Application Protection Platform (CNAPP) must include API visibility and posture management to be truly effective. By integrating API discovery and security into the Defender for Cloud CNAPP platform, this new capability helps organizations: Illuminate hidden risks by discovering APIs that were previously unmanaged or unknown. Reduce the attack surface by identifying and decommissioning unused or dormant APIs. Strengthen governance by extending API visibility beyond traditional API gateways. Advance to holistic CNAPP coverage by securing APIs alongside infrastructure, workloads, identities, and data. Availability and getting started This new API security capability is available in public preview to all Microsoft Defender for Cloud Security Posture Management (CSPM) customers at no additional cost. If you’re already using Defender for Cloud’s CSPM features, you can start taking advantage of API discovery and posture management right away. To get started, simply enable the API Security Posture Management extension in your Defender for Cloud CSPM settings. When enabled, Defender for Cloud scans Function App and Logic App APIs in your subscriptions, presenting relevant findings such as security recommendations and posture insights in the Defender for Cloud portal. Helpful resources Enable the API security posture extension Learn more in the Defender for Cloud documentationGeneral Availability of on-demand scanning in Defender for Storage
When malware protection was initially introduced in Microsoft Defender for Storage, security administrators gained the ability to safeguard their storage accounts against malicious attacks during blob uploads. This means that any time a blob is uploaded—whether from a web application, server, or user—into an Azure Blob storage account, malware scanning powered by Microsoft Defender Antivirus examines the content for any malicious elements within the blob, including images, documents, zip files and more. 🎉In addition to on-upload malware protection, on-demand malware protection is now generally available in Defender for Storage. This article will focus on the recent general availability release of on-demand scanning, its benefits, and how security administrators can begin utilizing this feature today. 🐞What is on-demand scanning? Unlike on-upload scanning, which is a security feature that automatically scan blobs for malware when they are uploaded or modified in cloud storage environments, on-demand scanning enables security administrators to manually initiate scans of entire storage accounts for malware. This scanning method is particularly beneficial for targeted security inspections, incident response, creating security baselines for specific storage accounts and compliance with regulatory requirements. Scanning all existing blobs in a storage account can be performed via the API and Azure portal user interface. Let's explore some use case scenarios and reasons why an organization might need on-demand scanning. Contoso IT Department has received a budget to enhance the security of their organization following the acquisition of Company Z. Company Z possesses numerous storage accounts containing dormant data that have not undergone malware scanning. To integrate these data blobs into the parent organization, it is essential that they first be scanned for malware. Contoso Health Department is mandated by state law to conduct a scheduled quarterly audit of the storage accounts. This audit ensures data integrity and provides documented assurance of security controls for compliance. It involves verifying that important cloud-hosted documents are secure and free from malware. Contoso Legal Corporation experienced a recent breach where the attacker accessed several storage accounts. Post-breach, Contoso Legal Corporation must assure their stakeholders that the storage accounts are free of malware. 💪Benefits of on-demand scanning On-demand scanning offers numerous advantages that security administrators can leverage to safeguard their cloud storage. This section details some of the primary benefits associated with on-demand scanning. Native scan experience: Malware scanning within Defender for Storage is an agentless solution that requires no additional infrastructure. Security administrators can enable malware protection easily and observe its benefits immediately. Respond to security events: Immediately scan storage accounts when security alerts or suspicious activities are detected. Security audits and maintenance: Performing on-demand scans is crucial during security audits or routine system maintenance to ensure that all potential issues are identified and addressed. Latest malware signatures: On-demand scanning ensures that the most recent malware signatures are utilized. Blobs that may have previously evaded detection by previous malware scans can be identified during a manual scan. 🫰On-demand scanning cost estimation Organizations frequently possess extensive amounts of data and require scanning for malware due to various security considerations. A lack of understanding regarding the precise cost of this operation can hinder security leaders from effectively safeguarding their organization. To address this issue, Defender for Storage offers an integrated cost estimation tool within the Azure portal user interface for on-demand scanning. This new UI will display the size of the blob storage and provide estimated costs for scans based on the volume of data. Access to this crucial information facilitates budgeting processes. 🤔On-upload or on-demand scanning In the current configuration of malware protection within Defender for Storage, it is required to have on-upload malware scanning enabled to use the on-demand functionality. On-demand scanning is offered as an additional option. On-upload scanning ensures that incoming blobs are free from malware, while on-demand scanning provides malware baselines and verifies blob health using the latest malware signatures. On-upload and on-demand scanning have distinct triggers. On-upload scanning is automatically performed when new blobs are uploaded to a blob-based storage account, whereas on-demand scanning is manually triggered by a user or an API call. On-demand scanning can also be initiated by workflow automation, such as using a logic app within Azure for scheduled scans. 👟Start scanning your blobs with on-demand scanning Prerequisites Malware protection in Defender for Storage is exclusively available in the per-storage account plan. If your organization is still using the classic Defender for Storage plan, we highly recommend upgrading to take advantage of the full range of security benefits and the latest features. To get started with this agentless solution, please look at the prerequisites in our public documentation here. Test on-demand Malware Scanning Within the Microsoft Defender for Cloud Ninja Training available on GitHub, security administrators can utilize Exercise 12: Test On-demand Malware Scanning in Module 19. The exercise includes detailed instructions and screenshots for testing on-demand malware scanning. This test can be performed using the Azure Portal User Interface or API. Best Practices To maximize the effectiveness of on-demand malware scanning in Microsoft Defender for Storage, please take a look at the best practices that are outlined in our public documentation here. 📖 Conclusion In this article we have explored the newly available on-demand scanning feature in Defender for Storage, which complements existing on-upload scanning capabilities by allowing security administrators to manually initiate malware scans for storage accounts. This feature is particularly useful for targeted security checks, incident response, creating security baseline for storage accounts and compliance audits. Additionally, Defender for Storage includes a built-in cost estimation tool to help organizations budget for on-demand scanning based on their data volume. ⚙️Additional Resources Defender for Storage Malware Protection Overview On-demand malware protection in Defender for Storage On-upload malware protection in Defender for Storage We want to hear from you! Please take a moment to fill out this survey to provide direct feedback to the Defender for Storage engineering team.
Unleashing the Power of Microsoft Defender for Cloud – Unique Capabilities for Robust Protection
So you have implemented a non-native Cloud Security Posture Management solution but there are security gaps that you might not have considered. How Defender for Cloud is uniquely positioned to secure your cloud attack surface.
