Cloud Security

Misconfigurations, permission risks, and vulnerabilities in one product (formerly CSM)

Cloud Security is a product that provides configuration auditing of cloud infrastructure, identity permission risk assessment, and vulnerability detection on a single platform. The product has been renamed Cloud Security; its former name is Cloud Security Management (CSM), and the card names on the pricing page remain CSM Pro / CSM Enterprise as of September 2026 (source: Cloud Security). Misconfigurations tracks the configuration hygiene and compliance posture of production environments and automates the collection of audit evidence. Identity Risks continuously surfaces permission risks in AWS IAM, Azure, and GCP. Vulnerabilities detects and prioritizes vulnerabilities in container images, host images, and running hosts. Finding traces of attacks in logs is the domain of Cloud SIEM; this product is the side that looks at how dangerous the configuration and contents are.

What you see without the Agent, and what changes when you add it

The official setup procedure is to enable Agentless Scanning first and then deploy the Datadog Agent to important hosts. Agentless Scanning covers AWS, Azure, and GCP most broadly and scans all hosts and running containers. Adding the Agent brings vulnerability prioritization based on runtime context and real-time updates, and the vulnerability update frequency changes from Agentless's 12 hours to real time (as of September 2026; source: Setting Up Cloud Security). Put the other way around, the Agent alone does not fill in Identity Risks and host benchmarks, and Agentless alone does not attach runtime context. Splitting it as Agent-side for hosts that already have the Agent and Agentless where they do not matches the official recommendation.

How misconfigurations and vulnerabilities differ

A misconfiguration is a state of cloud or infrastructure configuration that is undesirable when measured against a detection rule; rules scan the configuration state and find resources that do not meet the standard (as of September 2026; source: Cloud Security). A vulnerability is a known weakness (CVE) in a package contained in a host, container image, or serverless function, and it can exist even when the configuration is correct. Identity Risks finds users and roles with a large gap between granted permissions and permissions actually used, and Datadog officially explains that ingesting AWS CloudTrail logs improves its accuracy (source: Setting Up Cloud Security). The value of the distinction shows up in who is responsible. Misconfigurations tend to be the platform team's job, fixed by configuration changes, while vulnerabilities tend to be the development side's job, fixed by rebuilding images and updating packages; even when they sit in the same list, different people fix them.

What is the Security Posture Score a percentage of?

Misconfigurations has an indicator called the security posture score, which represents the percentage of the environment that satisfies all enabled out-of-the-box cloud configuration rules and infrastructure configuration rules (as of September 2026; source: Cloud Security). There are two ways to raise the score: fix the misconfiguration itself, or mute that misconfiguration (source: Datadog Glossary). This is the fork in operations: use muting as a record of an exception meaning "this configuration is intentional," because if you silence findings for the sake of the score without recording a reason, you will be unable to explain yourself at audit time. The weekly digest is subscribed to per user and delivers a summary of the important issues found in the last 7 days. The value of this indicator is being able to talk not in terms of how many items were fixed but in terms of "what percentage of the whole environment meets the standard."

Do not sort by CVSS alone - re-prioritize with runtime context

In a list sorted simply by descending CVSS, packages that are not running in production occupy the top. The official documentation introduces its own severity, the Datadog Severity Score, and explains that it layers the presence of sensitive data, environment criticality, exposure to attack, the existence of exploit code, and threat intelligence on top of the base CVSS to bring the exploitable ones to the front (as of September 2026; source: Cloud Security Vulnerabilities). Container images can be traced layer by layer, and if you attach OCI image annotations at build time, you can trace from a CVE to the Dockerfile and the relevant commit. The Infrastructure Packages Catalog lets you search the inventory of all packages (SBOM) to estimate the blast radius of a new CVE. Vulnerabilities in application libraries are handled by Software Composition Analysis on the Code Security side.

What is the difference between CSM Pro and CSM Enterprise on the pricing table?

On the pricing page as of September 2026, CSM Pro and CSM Enterprise are both shown as a monthly amount per host, with a unit price listed for each contract form: annual commitment, monthly commitment, and on-demand (source: Datadog Pricing). Enterprise adds file integrity monitoring, Workload Protection (Linux / Windows / Kubernetes / Docker / AWS Fargate), and a larger container allotment to all the features of Pro. The dividing line is whether you look as far as runtime behavior: configuration and vulnerabilities only, Pro; detecting threats from process and file behavior, Enterprise. Check the actual per-host and per-container unit prices on the public pricing table of the pricing page. The difference between Pro and Enterprise on the monitoring side is covered in a separate article, and the overall picture of pricing in the pricing guide.

This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

What additional cost arises on hosts that already have the monitoring Agent?

On hosts that have the Agent for Infrastructure Monitoring, you can enable it from the same Agent through the path Datadog officially lists as "use the unified Datadog Agent you have already deployed" (as of September 2026; source: Cloud Security Vulnerabilities). The add-on is the CSM unit price, and a billable host, per the definition in the pricing page FAQ, is a physical or virtual OS instance monitored by Datadog (server / VM / Kubernetes node, and so on) (source: Datadog Pricing). The monthly add-on is determined by "number of billable hosts x the unit price of the chosen plan," so if you enable it on every host that has the Agent, that full count is added as is. The opening move on cost is to enable it Agent-side only on important hosts and cover the rest with Agentless. The AWS integration role is left to Integrations, deployment on Kubernetes to Container Monitoring, and viewing permissions to RBAC.

How to decide the order of enablement

The official procedure is written in this order: enable Agentless Scanning, deploy the Agent to important hosts, then enable additional features (container image scanning in CI/CD, AWS CloudTrail logs, resource scanning via cloud integrations) (as of September 2026; source: Setting Up Cloud Security). Recast as an operational pattern, the order that reduces rework is: in week 1, take the initial Findings and posture score with Agentless only; in week 2, enable the features on hosts that have the Agent to obtain prioritization with runtime context; and after that, add scanning to CI. Findings are gathered in the Security Inbox sorted by severity, and remediation runs through cases and Workflow Automation. There is one reason to keep the order: without the Agentless baseline, you cannot measure the effect of adding the Agent.