Asset Inventory and CMDB Security Guide: Building an Inventory Security Can Rely On

Most security programmes assume an asset inventory that does not exist: the CMDB lists what was registered, not what is running, and every control that depends on it inherits the gap. Vulnerability scanning, patching, EDR coverage, logging, access reviews and incident response all start from the question "what do we have, and who owns it?". This guide explains how to build an inventory that security can rely on, using CIS Controls v8.1 Controls 1 and 2, CISA BOD 23-01, NIST CSF 2.0 ID.AM and NCSC asset management guidance. It covers discovery sources, CAASM, CMDB data quality, cloud resources, non-human identities and certificates as assets, and how to secure the CMDB itself, which is one of the most useful maps an attacker can steal. It is written for security architects, vulnerability management leads, CMDB owners and IT operations teams.

Key takeaways

• Discovery beats registration. An inventory fed only by tickets and procurement drifts within weeks; CISA BOD 23-01 sets automated discovery every 7 days and CIS Safeguard 1.3 runs active discovery daily.
• Correlate many sources into one record. No single tool sees everything: combine network discovery, endpoint agents, cloud APIs, identity providers, DHCP and DNS logs, then reconcile them into one authoritative record with a last-seen date.
• Assets include identities, certificates and cloud resources. Service accounts, API keys, workload identities, TLS certificates, SaaS tenants and AI deployments carry risk and need owners exactly like servers do.
• Measure the inventory, not just the assets. Coverage, freshness, ownership and unknown-asset rates tell you whether the inventory can be trusted for vulnerability management.
• The CMDB is a target. It maps every crown jewel and its integrations often hold privileged discovery credentials; treat it as a Tier 0 adjacent system with least privilege, monitoring and credential rotation.

What a security-grade inventory must answer

An IT asset register built for finance or licensing answers "what did we buy?". A security inventory has to answer operational questions quickly and correctly. NIST CSF 2.0 splits this across several outcomes: hardware (ID.AM-01), software, services and systems (ID.AM-02), network data flows (ID.AM-03), supplier services (ID.AM-04), prioritisation by criticality (ID.AM-05), data (ID.AM-07) and life cycle management (ID.AM-08). NIST SP 800-53 Rev. 5 CM-8 System Component Inventory adds the enhancements most teams need: CM-8(1) updates during installation and removal, CM-8(2) automated maintenance, CM-8(3) automated unauthorised component detection and CM-8(4) accountability information (who is responsible).

For each asset, the inventory should be able to answer:

• Existence and freshness: is it real, and when was it last seen by an independent source?
• Ownership: a named accountable owner (person or team), not "IT". CIS Safeguard 1.1 explicitly expects the owner and department to be recorded.
• Exposure: internet-facing or internal, network zone, cloud account or subscription.
• Software and version: operating system, installed software and versions, support status (CIS Safeguard 2.2 requires that only currently supported software is authorised).
• Criticality and data: business service it supports and the data it stores or processes.
• Security coverage: EDR agent, vulnerability scan (authenticated or not), log forwarding, backup.
• Identities and secrets: service accounts, cloud roles, API keys and certificates bound to it.

Requirements at a glance

BOD 23-01 is binding only on US federal civilian agencies and explicitly excludes ephemeral assets such as containers and third-party managed SaaS, but its 7 and 14 day cadence is a sensible benchmark for any organisation. Its definitions are useful too: asset discovery identifies which network-addressable IP assets exist, while vulnerability enumeration identifies their operating systems, applications, open ports and missing updates, ideally with privileged credentials.

Discovery sources and how to combine them

NCSC guidance recommends combining active sources (agents, network scanning) with passive ones (DNS and DHCP logs, authentication logs), then cross-checking against procurement records, device management, logging platforms, vulnerability management tools and certificate records. Each source has blind spots, so the value comes from correlation.

Do not run active scans against fragile OT networks without engineering approval; NCSC notes active scanning may be unsuitable there. See the OT Asset Visibility Guide. For internet-facing discovery, see the Attack Surface Management Guide.

Cyber asset attack surface management (CAASM)

CAASM tools connect by API to the sources above (EDR, MDM, cloud, IdP, scanners, CMDB) and correlate them into one deduplicated view, then query for gaps such as "servers with no EDR agent" or "internet-facing hosts not scanned in 30 days". The value is the correlation logic and the gap queries, not another list. Before buying, check how the tool deduplicates (MAC, serial number, cloud instance ID, hostname), how it handles conflicting attributes, and whether it can write corrections back to the CMDB. CAASM complements rather than replaces a CMDB: the CMDB holds intended state, ownership and service relationships; CAASM shows observed state. See the Exposure Management and CTEM Guide.

Cloud resources

Cloud providers already keep an inventory; the work is enabling it everywhere and collecting it centrally:

• AWS Config: records resource configurations, relationships and configuration history for the resource types you choose; an aggregator collects configuration and compliance data from multiple accounts and Regions into one account, and advanced queries return current configuration state.
• Azure Resource Graph: KQL queries across subscriptions and management groups, with resource configuration changes kept for 14 days. It returns only what the caller has RBAC read access to, so an inventory identity scoped to one subscription silently produces a partial inventory.
• Google Cloud Asset Inventory: resources, IAM policies (content type IAM_POLICY) and organisation policies, with 35 days of change history, export to BigQuery or Cloud Storage and Pub/Sub feeds for change monitoring. Google notes it is eventually consistent and not designed for real-time querying.

Ephemeral assets (containers, serverless functions, autoscaled instances) are better inventoried as their templates: the image, the function definition, the launch template and the deployment pipeline. See the Cloud Security Guide.

Non-human identities, certificates and AI as assets

Attackers increasingly use credentials rather than exploits, so an inventory that lists hosts but not the identities and secrets on them misses the assets that matter most during an incident. NCSC guidance goes as far as recommending that certificate identities are issued only to registered assets, which ties identity issuance to the inventory.

• Service accounts and workload identities: record each account, its owner, the systems it runs on, its privileges and its credential type. See the Service Account Inventory Template and the NHI Ownership Guide.
• API keys, tokens and secrets: link each secret to the asset and service that uses it, so rotation after a compromise is a query rather than a hunt. See the Secrets Management Guide.
• Certificates and keys: TLS, code signing and machine certificates with expiry, issuer and key algorithm. This is also the starting point for post-quantum migration. See the Cryptographic Inventory and CBOM Guide.
• SaaS and OAuth integrations: tenants, connected apps and their granted scopes, from the IdP and SaaS admin consoles.
• AI deployments: models, AI agents, notebooks and compute clusters, with the API keys and cloud roles they hold. See the AI Register and AI Inventory Template.

The ShadowRay campaign shows why this matters: exposed Ray clusters (CVE-2023-48022, a disputed missing-authentication issue on the dashboard port 8265) gave attackers code execution, and the clusters held OpenAI, Hugging Face and cloud credentials. Organisations that could not list their Ray deployments, or the identities each held, could neither check exposure nor scope rotation. For continuous identity posture across these sources, see the ISPM Guide.

CMDB data quality: making the record trustworthy

A CMDB is only as useful as its data. NCSC recommends one authoritative record that everyone agrees reflects the environment, "last seen" timestamps or confidence scores, and regular investigation of stale records, which may indicate repurposed or unmaintained devices. In practice, quality rests on four properties:

• Completeness: the required attributes are populated (owner, environment, criticality, support group). Define a small mandatory set and enforce it at creation; dozens of optional fields stay empty.
• Correctness: no duplicates, no orphans (configuration items with no relationship to a service), no stale items. Write identification and reconciliation rules that define which source is authoritative for which attribute, for example the EDR agent for installed software, the cloud API for instance state and HR for the owner's employment status.
• Freshness: each item carries the last time an automated source saw it. Items not seen for a defined period (for example 30 days for servers, 14 for cloud resources) go into a review queue, not straight to deletion.
• Ownership: every configuration item maps to an owner who is still employed. Re-attest ownership on leaver events and in periodic campaigns, as for NHIs.

Drift between the CMDB and reality is the default, not a failure. Treat it as a measured backlog: reconcile discovered assets against the CMDB daily, create tickets for unknowns, and review the backlog weekly in line with CIS Safeguard 1.2. Reconcile procurement and cloud billing against the inventory, as NCSC suggests, to find assets that discovery missed.

Securing the CMDB itself

The CMDB lists every server, its owner, its software version, its network zone and the business service it supports. To an attacker it is a ready-made target list, and NCSC advises that asset data is sensitive: restrict access to what people are responsible for, prevent arbitrary bulk queries and monitor access for signs of reconnaissance. MITRE ATT&CK tracks this as T1213 Data from Information Repositories, and an attacker who can read the CMDB skips much of T1046 Network Service Discovery or, in cloud, T1580 Cloud Infrastructure Discovery and T1526 Cloud Service Discovery.

Agentless discovery is the classic trap: to read software inventories from thousands of hosts, the tool needs credentials that log on to all of them. If those are domain admin or a shared root key, the CMDB platform becomes a path to the whole estate. Prefer agents where possible, scope credentials per segment, and include discovery accounts in privileged access reviews. See the ServiceNow Security Guide for platform-specific hardening and the Top 10 Secrets Management Mistakes for credential handling.

Implementation: a phased rollout

1. Define scope and ownership (weeks 1 to 2). Name a single accountable owner for the inventory, as NCSC recommends, agree the asset classes in scope (hardware, software, cloud, SaaS, identities, certificates) and the mandatory attributes.
2. Connect the cheap sources first (weeks 2 to 6). EDR or MDM, cloud provider inventories for every account and subscription, IdP, DHCP and DNS logs. These usually cover most of the estate with little effort.
3. Add active and external discovery (weeks 4 to 8). Scan all internal ranges weekly at minimum (daily for CIS IG2 and above) and the external attack surface. Pilot on one segment first and exclude fragile OT ranges.
4. Correlate and baseline (weeks 6 to 10). Build the correlated view (CAASM or scripted), measure coverage gaps, and agree authoritative sources per attribute. Expect a large initial unknown set.
5. Work the unknowns (ongoing, weekly). Assign owners, quarantine or remove unauthorised assets (CIS 1.2), and feed new assets into vulnerability scanning and EDR deployment.
6. Add identities and certificates (months 3 to 6). Link service accounts, secrets and certificates to assets and owners.
7. Lock down the CMDB. Review roles, export rights, discovery and integration credentials; add monitoring.

Testing and rollback: run new reconciliation rules in report-only mode for two cycles before letting them update or retire configuration items, and keep automated retirement as a soft state (for example "pending retirement") that can be reversed. When a new discovery source causes duplicate storms, disable its write rights and keep it as a read-only feed until the identification rules are fixed.

Decision guidance

• CMDB first or CAASM first: if your CMDB is reasonably maintained and drives ITSM, add CAASM-style correlation to measure and correct it. If it is not trusted at all, start with a correlated observed view to establish truth, then feed the CMDB from it.
• Agent or agentless: agents give richer software data and work off-network but miss unmanaged devices; agentless discovery reaches appliances and unmanaged hosts but needs privileged credentials. Most organisations need both.
• Small organisations: CIS IG1 requires only Safeguards 1.1, 1.2, 2.1, 2.2 and 2.3. An MDM or EDR console, the cloud provider inventory and a monthly reconciliation spreadsheet with owners is a realistic start.
• Large or regulated organisations: aim for the BOD 23-01 cadence (7 day discovery, 14 day enumeration), CIS IG2 and IG3 discovery safeguards and automated feeds to vulnerability management, with CMDB access treated as sensitive.

Detection and measurement

Monitor for new devices seen by DHCP, passive sensors or cloud APIs that are not in the inventory; resources created in unregistered cloud accounts; large or unusual CMDB exports and API queries; and use of discovery credentials from hosts other than the collectors. Useful metrics:

• Unknown asset rate: assets seen by discovery but not in the inventory, and median time to assign an owner.
• Freshness: percentage of inventory items seen by an automated source in the last 7 days (14 for roaming devices).
• Ownership: percentage of assets, service accounts and certificates with a current, employed owner.
• Control coverage: percentage of in-scope assets with EDR, authenticated vulnerability scanning and log forwarding.
• Cloud coverage: percentage of cloud accounts and subscriptions connected to central inventory.
• Unsupported software: count of assets running end-of-support software without a documented exception (CIS 2.2).

Common failure patterns

• The CMDB as the only source: records are created by tickets and never verified, so unmanaged and forgotten systems stay invisible to scanners. CIS Safeguard 7.7 remediation explicitly depends on 1.1 for this reason.
• Internet-facing components nobody tracks: in the ShinyHunters PeopleSoft claim, the group says it exploited a PeopleSoft flaw (the page discusses CVE-2026-35273 in the Environment Management Hub, patched in June 2026, though its use against the FBI is unconfirmed). Knowing which ERP modules are exposed and in use is the first step to patching or removing them.
• Cloud accounts outside the inventory: a team creates an account or subscription that is never connected to central inventory, so nothing in it is scanned or monitored.
• Hosts listed, credentials not: after a compromise, nobody can say which keys and service accounts lived on the system, so rotation is partial.
• Discovery with domain admin: a single highly privileged discovery account turns the CMDB platform into a lateral movement route.
• Stale records deleted automatically: a device that stops reporting is removed rather than investigated, hiding a compromised or repurposed host.

Framework mapping

Practitioner checklist

• Name one accountable owner for the inventory and agree the mandatory attributes, including owner and last-seen date.
• Connect EDR or MDM, every cloud account and subscription, the IdP and DHCP or DNS logs to a correlated view.
• Run active discovery at least every 7 days (daily for CIS IG2 and above) and passive discovery where active scanning is unsafe.
• Review unknown and unauthorised assets weekly and route new assets into vulnerability scanning and EDR deployment.
• Track software versions and end-of-support status, with documented, time-limited exceptions.
• Link service accounts, API keys and certificates to assets and owners.
• Restrict CMDB read and export rights by role, alert on bulk queries and log all API access.
• Replace highly privileged discovery and integration credentials with scoped, vaulted, rotated ones.
• Report coverage, freshness and ownership metrics to senior management monthly.

Standards and references

• CIS: Controls v8.1 Assessment Specification, Control 1 Inventory and Control of Enterprise Assets
• CIS: Controls v8.1 Assessment Specification, Control 2 Inventory and Control of Software Assets
• CISA: BOD 23-01 Improving Asset Visibility and Vulnerability Detection on Federal Networks
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NCSC: Asset management
• CISA: Cross-Sector Cybersecurity Performance Goals
• Microsoft Learn: Overview of Azure Resource Graph

Related NHI Mgmt Group resources: Vulnerability Management Guide · Vulnerability Scanning Guide · Vulnerability Prioritisation Guide · Service Account Inventory Template · Top 10 Vulnerability Management Mistakes