Microsoft Defender for Cloud Cost Estimation Dashboard
This blog was updated on April 16 th , 2023 to reflect the latest version of the Cost Estimation workbook. Microsoft Defender for Cloud provides advanced threat detection capabilities across your cloud workloads. This includes comprehensive coverage plans for compute, PaaS and data resources in your environment. Before enabling Defender for Cloud across subscriptions, customers are often interested in having a cost estimation to make sure the cost aligns with the team’s budget. We previously released the Microsoft Defender for Storage Price Estimation Workbook, which was widely and positively received by customers. Based on customer feedback, we have extended this offering by creating one comprehensive workbook that covers most Microsoft Defender for Cloud plans. This includes Defender for Containers, App Service, Servers, Storage, Cloud Security Posture Management and Databases. The Cost Estimation workbook is out-of-the box and can be found in the Defender for Cloud portal. After reading this blog and using the workbook, be sure to leave your feedback to be considered for future enhancements. Please remember these numbers are only estimated based on retail prices and do not provide actual billing data. For reference on how these prices are calculated, visit the Pricing—Microsoft Defender | Microsoft Azure. Overview The cost estimation workbook provides a consolidated price estimation for Microsoft Defender for Cloud plans based on the resource telemetry in your organization’s environment. The workbook allows you to select which subscriptions you would like to estimate the price for as well as the Defender Plans. In a single pane of glass, organizations can see the estimated cost per plan on each subscription as well as the grand total for all the selected subscriptions and plans. To see which plans are currently being used on the subscription, consider using the coverage workbook. Defender Cloud Security Posture Management (CSPM) Defender CSPM protects all resources across your subscriptions, but billing only applies to Compute, Databases and Storage accounts. Billable workloads include VMs, Storage accounts, open-source relational databases and SQL PaaS & Servers on machines. See here for more information regarding pricing. On the backend, the workbook checks to see how many billable resources were detected and if any of the above plans are enabled on the subscription. It then takes the number of billable resources and multiplies it by the Defender CSPM price. Defender for App Service The estimation for Defender for App Services is based on the retail price of $14.60 USD per App Service per month. Check out the Defender for App Service Price Estimation Dashboard for a more detailed view on estimated pricing with information such as CPU time and a list of App Services detected. Defender for Containers The estimation for Defender for Containers is calculated based on the average number of worker nodes in the cluster during the past 30 days. For a more detailed view on containers pricing such as average vCores detected and the number of image scans included, consider also viewing the stand-alone Defender for Containers Cost Estimation Workbook. Defender for Databases Pricing for Defender for Databases includes Defender for SQL Databases and Defender for open-source relational databases (OSS DBs). This includes PostgreSQL, MySQL and MariaDB. All estimations are based on the retail price of $15 USD per resource per month. On the backend, the workbook runs a query to find all SQL databases and OSS DBs in the selected subscriptions and multiplies the total amount by 15 to get the estimated monthly cost. Defender for Key Vault Defender for Key Vault cost estimation is not included in the out of the box workbook, however, a stand-alone workbook is available in the Defender for Cloud GitHub. The Defender for Key Vault dashboard considers all Key Vaults with or without Defender for Key Vault enabled on the selected subscriptions. The calculations are based on the retail price of $0.02 USD per 10k transactions. The “Estimated Cost (7 days)” column takes the total Key Vault transactions of the last 7 days, divides them by 10K and multiples them by 0.02. In “Estimated Monthly Price”, the results of “Estimated Cost (7 days)” are multiplied by 4.35 to get the monthly estimate. Defender for Servers Defender for Servers includes two plan options, Plan 1 and Plan 2. The workbook gives you the option to toggle between the two plans to see the difference in how they would effect pricing. Plan 1 is currently charged at $5 per month where as Plan 2 is currently charged at $15. Defender for Storage The Defender for Storage workbook allows you to estimate the cost of the two pricing plans: the legacy per-transaction plan and the new per-storage plan. The workbook looks at historical file and blob transaction data on supported storage types such as Blob Storage, Azure Files, and Azure Data Lake Storage Gen 2. We have released a new version of this workbook, and you can find it here: Microsoft-Defender-for-Cloud/Workbooks/Microsoft Defender for Storage Price Estimation and learn more about the storage workbook in Microsoft Defender for Storage – Price Estimation blog post. Limitations Azure Monitor Metrics data backends have limits and the number of requests to fetch data might time out. To solve this, narrow your scope by reducing the selected subscriptions and Defender plans. The workbook currently only includes Azure resources. Acknowledgements Special thanks to everyone who contributed to different versions of this workbook: Fernanda Vela, Helder Pinto, Lili Davoudian, Sarah Kriwet, Safeena Begum Lepakshi, Tom Janetscheck, Amit Biton, Ahmed Masalha, Keren Damari, Nir Sela, Mark Kendrick, Yaniv Shasha, Mauricio Zaragoza, Kafeel Tahir, Mary Lieb, Chris Tucci, Brian Roosevelt References: What is Microsoft Defender for Cloud? - Microsoft Defender for Cloud | Microsoft Learn Pricing—Microsoft Defender | Microsoft Azure Workbooks gallery in Microsoft Defender for Cloud | Microsoft Docs Pricing Calculator | Microsoft Azure Microsoft Defender for Key Vault Price Estimation Workbook Microsoft Defender for App Services Price Estimation Workbook Microsoft Defender for Containers Cost Estimation Workbook Coverage WorkbookUnveiling 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.Enhance your CI/CD deployment by using Vulnerability Assessments from Microsoft Defender for ACR
By embedding Microsoft Defender for container registries assessments into your CI/CD pipeline, you can address this need and have a more secure automation and deployment processes in enterprise environments. This blog will take you through a few simple steps to take your CI/CD pipeline to the next security level.
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.AKS Security Dashboard
In today’s digital landscape, the speed of development and security must go hand in hand. Applications are being developed and deployed faster than ever before. Containerized application developers and platform teams enjoy the flexibility and scale that Kubernetes has brought to the software development world. Open-source code and tools have transformed the industry - but with speed comes increased risk and a growing attack surface. However, in vast parts of the software industry, developers and platform engineering teams find it challenging to prioritize security. They are required to deliver features quickly and security practices can sometimes be seen as obstacles that slow down the development process. Lack of knowledge or awareness of the latest security threats and best practices make it challenging to build secure applications. The new Azure Kubernetes Service (AKS) security dashboard aims to alleviate these pains by providing comprehensive visibility and automated remediation capabilities for security issues, empowering platform engineering teams to secure their Kubernetes environment more effectively and easily. Consolidating security and operational data in one place directly within the AKS portal allows engineers to benefit from a unified view of their Kubernetes environment. Enabling more efficient detection, and remediation of security issues, with minimal disruption to their workflows. Eventually reducing the risk of oversight security issues and improving remediation cycles. To leverage the AKS security dashboard, navigate to the Microsoft Defender for Cloud section in the AKS Azure portal. If your cluster is already onboarded to Defender for Containers or Defender CSPM, security recommendations will appear on the dashboard. If not, it may take up to 24 hours after onboarding before Defender for Cloud scans your cluster and delivers insights. Security issues identified in the cluster, surfaced in the dashboard are prioritized to risk. Risk level is dynamically calculated by an automatic attack path engine operating behind the scenes. This engine assesses the exploitability of security issues by considering multiple factors, such as cluster RBAC (Role Based Access Control), known exploitability in the wild, internet exposure, and more. Learn more about how Defender for Cloud calculates risk. Security issues surfaced in the dashboard are divided into different tabs: Runtime environment vulnerability assessment: The dynamic and complex nature of Kubernetes environments means that vulnerabilities can arise from multiple sources, with different ownership for the fix. For vulnerabilities originating from the containerized application code, Defender for Cloud will point out every vulnerable container running in the cluster. For each vulnerable container Defender for cloud will surface remediation guidelines that include the list of vulnerable software packages and specify the version that contains the fix. The scanning of container images powered by Microsoft Defender Vulnerability Management (MDVM) includes scanning of both OS packages and language specific packages see the full list of the supported OS and their versions. For vulnerabilities originating from the AKS infrastructure, Defender for cloud will include a list of all identified CVEs (common vulnerabilities and exposures) and recommend next steps for remediation. Remediation may include upgrading the Node pool image version or the AKS version itself. Since new vulnerabilities are discovered daily, even if a scanning tool is deployed as part of the CI/CD process, runtime scan can’t be overlooked. Defender for cloud makes sure Kubernetes workloads are scanned daily compared to an up-to-date vulnerability list. Security misconfigurations: Security misconfigurations are also highlighted in the AKS security dashboard, empowering developers and platform teams to execute fixes that can significantly minimize the attack surface. In some cases, changing a single line of code in a container's YAML file, without affecting application functionality, can eliminate a significant attack vector. Each security misconfiguration highlighted in the AKS security dashboard includes manual remediation steps, and where applicable, an automated fix button is also available. For containers misconfigurations, a quick link to a built-in Azure policy is included for easily preventing future faulty deployments of that kind. This approach empowers DevOps & platform engineering teams to use the “Secure by Default” method for application development. To conclude - automated remediation and prevention can be a game changer in keeping the cluster secure- a proactive approach that can help prevent security breaches before they can cause damage, ensuring that the cluster remains secure and compliant with industry standards. Ultimately, automated remediation empowers security teams to focus on more strategic tasks, knowing that their Kubernetes environment is continuously monitored and protected. Assigning owners to security issues Since cluster administration and containers security issues remediation is not always the responsibility of a single team or person, it is recommended to use the “assign owner” button in the security dashboard to notify the correct owner about the issue need to be handled. It is also possible to filter the view using the built-in filters and assign multiple issues to the same person quickly. 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 for a full subscription coverage, or enable on a single cluster using the dashboard settings section. 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.
