What is a CMDB?
A configuration management database (CMDB) is a centralized repository of IT assets (also known as “configuration items”) and the relationships between them. The key word is relationships.
Asset lists tell you what exists. A CMDB tells you how everything connects: which services depend on which databases, which Lambda functions write to which S3 buckets, and which teams own which workloads. Think of it as a live map of your cloud where every node links to other nodes, and changing one node shows you everything downstream that might break.
The Cloud Security Workflow Handbook
Get the 5-step framework for modern cloud security maturity.
How CMDBs work in cloud environments
A cloud CMDB works by maintaining a live record of every resource, updated continuously via cloud API event streams rather than scheduled batch jobs. Your cloud security posture depends on that data staying accurate.
What is a configuration item (CI) record?
A CI record for a cloud resource describes what it is, where it runs, who owns it, and what it connects to. Cloud-native CI records carry attributes that on-premises records never needed: IaC provenance (which Terraform workspace created this resource, which deployment pipeline last modified it) and an ephemeral lifecycle flag indicating whether the resource has a persistent identity at all.
For a Lambda function handling payment processing, that record might include:
| CI type | Key attributes | Relationships | Owner |
|---|---|---|---|
| Lambda function | ARN, runtime, memory, timeout | Writes to DynamoDB via VPC endpoint in subnet X | Payments team, AWS account 1234 |
| DynamoDB table | Table name, encryption state, region | Read by Lambda, feeds downstream API | Payments team |
| S3 bucket | Bucket name, public access setting, tags | Written to by Lambda | Platform team |
That relationship chain from Lambda to DynamoDB to VPC is what enables blast-radius assessment when something goes wrong. And the ownership field is responsible for remediation routing: When that Lambda triggers a CSPM alert, the ownership record determines which team's ticket queue it lands in.
How has CMDB discovery changed over time?
CMDB discovery has evolved through three distinct generations, each addressing limitations the previous one exposed:
Generation 1: Agent-based discovery installs software directly on each CI target and reports configuration data back on a schedule. This works reliably for persistent infrastructure but breaks for containers and serverless functions where there is no persistent host to install an agent on.
Generation 2: Agentless network scanning uses protocols such as SSH for Linux and Unix hosts, WMI for Windows hosts, and SNMP for network devices to query targets remotely. Enterprise CMDB tools such as ServiceNow Discovery use this model to cover on-premises servers, network infrastructure, and persistent cloud VMs.
Generation 3: Cloud API and event-driven discovery is the architectural answer for cloud-native environments. AWS Config, Azure Resource Graph, and GCP Cloud Asset Inventory expose continuous event streams triggered by resource creation, modification, and deletion. Every resource event triggers a CMDB write rather than a scheduled batch job. ServiceNow, the dominant enterprise CMDB platform, integrates directly with these event streams to keep CI records current.
Exposure management in cybersecurity explained
Exposure management is when companies identify, assess, and mitigate the risk posed by exposed resources, such as networks, applications, data, and other assets.
Read more
CMDB vs. asset management vs. service mapping
In practice, many organizations use IT asset management (ITAM), CMDB, and service mapping capabilities within overlapping platforms rather than as three separate systems. Compliance frameworks reference "asset management" generically without specifying which category. The distinctions below reflect functional differences in what each approach emphasizes, not necessarily separate tools you must buy:
ITAM asks: "What do we own, what does it cost, and when does it expire?" It focuses on lifecycle, financial value, and license compliance.
CMDB asks: "How does this connect to everything else, and what breaks if it changes?" It maps configuration details, dependencies, and relationships.
Service mapping asks: "How do these CIs combine to deliver a business service?" It builds and consumes the CMDB relationship graph to construct a service-level view. In other words, service mapping depends on CMDB data; it’s not a competing approach.
Cyber asset attack surface management (CAASM) asks: "What exposures and attack surface do we have across all sources?" Tools in this category, such as Axonius and JupiterOne, aggregate, normalize, and correlate asset data from multiple sources to create unified exposure visibility across cloud accounts, identity systems, endpoint tools, and vulnerability scanners, extending the CMDB relationship model with risk context. This is the category that bridges CMDB ownership data and security posture analysis, and it maps directly to what Wiz's Security Graph delivers.
For security teams, the CMDB relationship layer is the remediation routing mechanism. Cloud Infrastructure Entitlement Management adds the identity dimension: When configuration records lack clear ownership, identity entitlements determine who can actually touch the resource.
What is Cyber Asset Attack Surface Management (CAASM)?
Cyber asset attack surface management (CAASM) is a security practice that gives teams unified visibility and control over all enterprise assets—cloud, SaaS, on-prem, and beyond. It helps eliminate blind spots and reduce risk by correlating asset data from across your environment and tools. CAASM enables teams to query, prioritize, and act from a single source of truth.
Read moreSecurity benefits of configuration management databases
A well-maintained CMDB delivers four concrete security benefits: remediation routing, change impact analysis, risk enrichment, and audit evidence.
When a CSPM alert fires on a misconfiguration, like a misconfigured S3 bucket, the first question is: Who owns this thing? Without a CI record that maps that bucket to a team, an account, and an IaC source, the alert has no destination. It ages out, and unrouted alerts directly drive MTTR drift and create audit gaps.
Change impact analysis tells you what else is at risk when, for example, a compromised Lambda function is identified during an incident. The CMDB relationship layer shows that the Lambda writes to a DynamoDB table containing PII, which feeds a downstream API, which serves customer-facing traffic. That blast-radius picture comes from the relationship graph, not from any individual CI record.
Security-enriched CI records extend this further. A standard CI record describes what a resource is and how it connects. A security-enriched record adds the vulnerability findings on that resource, its network exposure status, and a summary of its access permissions, turning a configuration snapshot into a risk-context entry. This enrichment layer allows teams to prioritize critical vulnerabilities automatically.
Finally, CMDBs ensure audit readiness by providing point-in-time evidence of control state: what resources existed at a given date, how they were configured, and who was accountable. That evidence applies directly to SOC 2, ISO 27001, FedRAMP, and frameworks like CMMC.
Watch 12-min demo
See exactly how Wiz handles a live threat. This 12-minute walkthrough shows you how our Security Graph correlates runtime alerts with cloud context to identify the root cause, find the resource owner, and provide one-click remediation.
Key challenges with cloud-native CMDB implementation
Cloud-native CMDB implementations must address three specific architectural hurdles:
The ephemeral resource timing failure is the Lambda problem. A Lambda-based transaction task can run for several minutes and then terminate. When CMDB discovery runs only once each night, that workload can appear and disappear between sync cycles. The function is never captured: no CI record, no owner, no security scan target. The mismatch between minute-scale resource lifecycles and hour-or-day-scale sync cadences is a structural incompatibility, not a configuration issue.
The IaC provisioning gap is the Terraform problem. A terraform apply creates an S3 bucket tagged only environment = "prod". No owner, no service context, no CMDB integration point in a typical enterprise setup. Terraform knows exactly what it created; the CMDB does not, because the provisioning event never triggered a CMDB write. This is ownership attribution failure at its root, and it’s exactly why understanding identity gaps in IaC provisioning matters as much as the discovery mechanics themselves.
The CSPM alert routing failure is what the first two failures produce downstream. A CSPM alert fires: S3 bucket with public access enabled, sensitive data present. The CMDB has no matching CI record for this bucket. The security team can’t route the remediation ticket. The alert ages out.
Scale and multi-cloud complexity compounds all three challenges. Enterprise environments contain tens of thousands of resources with daily churn across AWS, Azure, and GCP, each with different API models, resource types, and event stream formats. Scheduled batch sync doesn’t scale structurally at this surface area, and the live map becomes a stale spreadsheet.
Attack surface monitoring: Your first line of cloud defense
Attack surface monitoring involves continuously identifying and tracking internet-reachable assets. In cloud-native environments, where endpoints, identities, and services
Read more
How modern CMDBs solve implementation challenges
Modern CMDB implementations address the cloud-native gaps we discussed above through three capability shifts: event-driven discovery, native security enrichment, and bidirectional integration with security platforms.
Event-driven discovery subscribes to event streams from AWS Config, Azure Resource Graph, and GCP Cloud Asset Inventory, triggering CI record writes on resource creation, change, and deletion. A Lambda function that lives for 12 minutes generates a creation event and a deletion event; both get recorded.
The second shift is treating security data as native to the CI record rather than bolted on afterward. Security-enriched records add vulnerability findings, network exposure status, and access permission summaries as native fields. This is what turns a cloud management database into a risk intelligence layer. When the CI record for your payment processing Lambda already carries its CVE findings and IAM permission scope, every downstream workflow operates with full context from the start.
Your CMDB and your security platform talking to each other closes the loop. The CMDB sends ownership and business context to security tooling; security tooling writes enrichment data back to CI records. As we’ve seen, ServiceNow remains the dominant enterprise CMDB platform in this model, and modern integrations connect it directly to cloud security platforms for continuous enrichment in both directions.
How Wiz integrates with your CMDB for enhanced cloud security
Closing coverage gaps starts with discovery. Wiz connects to your cloud environments agentlessly and discovers assets in minutes across AWS, Azure, GCP, and Kubernetes, without scheduled jobs or missing transient resources. This real-time inventory is then used to drive bidirectional value with your CMDB (like ServiceNow).
Wiz imports ownership metadata and business context to help you accurately attribute assets to the right teams and prioritize remediation. It also writes cloud inventory back to ServiceNow.
To keep your CMDB clean, Wiz maps security context, like vulnerability context and identity and entitlement data, directly to ServiceNow's dedicated Vulnerability Response (VR) and Configuration Compliance (CC) modules, rather than attaching findings to base CI records. This links security context directly to CIs so incident response and change management operate with complete context.
Wiz's open security ecosystem, powered by Wiz Integrations (WIN) and Wiz Unified Vulnerability Management (UVM), unifies data from your existing scanners with CMDB ownership data. This feeds our attack path analysis to map relationships between assets and identify toxic combinations of risks, working alongside exposure management to show you an active picture of your exploitable attack surface.
See how Wiz turns your CMDB into a live risk intelligence layer. Get a demo.
See your cloud security architecture in action
Wiz maps your entire cloud environment and surfaces the attack paths that put your organization at risk.
