Is our CMDB good enough as the vulnerability inventory?

Rarely on its own. A CMDB is usually strong on ownership and business service mapping but weak on completeness, because assets are created faster than records. Use it as one source and reconcile it with discovery data from EDR, cloud APIs, scanners and directory services; the differences between them are exactly the gaps you need to find.

How should we handle short-lived cloud and container assets?

Inventory the things that persist — images, templates, cloud accounts, clusters and workload definitions — and assess vulnerabilities there. A running container is usually a copy of an image, so fixing the image and redeploying is the remediation; tracking every short-lived instance as a separate asset creates noise.

How many criticality tiers should we use?

Three or four is typical. Fewer than three cannot express the difference between crown-jewel systems and the rest; more than four tends to be applied inconsistently. What matters most is that the business agrees the definitions and that every asset has a tier.

Asset inventory for vulnerability management

Every vulnerability decision depends on facts about assets: does this host exist, who owns it, what does it do for the business, and who can reach it? Scanners report vulnerabilities on IP addresses and hostnames; remediation needs a team name and a service. The gap between those two is the asset inventory, and it is the most common reason vulnerability programs stall. You cannot prioritize what you cannot see, and you cannot route what nobody owns.

This guide covers how to build an inventory that is good enough for a Vulnerability Operations Center: which sources to combine, how to reconcile them, which attributes matter, and how to measure the gaps that scanners silently leave behind.

Why the inventory comes first

CIS Controls v8 puts inventory of enterprise assets (Control 1) and software assets (Control 2) before continuous vulnerability management (Control 7) for a reason. Without an inventory:

Coverage is unknowable. A scanner can report that it scanned 5,000 hosts, but not that there were 6,000.
Prioritization is blind. Risk-based tiers need criticality and exposure; see risk-based prioritization.
Routing fails. Findings without an owner end up in a shared queue where they age indefinitely.
Metrics lie. A drop in open findings might mean remediation, or it might mean a scanner lost access to a subnet.

The inventory does not need to be perfect before you start. It needs to be measured — you should know how complete it is and be improving that number.

Sources of asset data

No single source is complete. Each sees a different slice of the estate, with different strengths.

Source	Sees well	Misses	Best attribute
CMDB / ITSM	Business services, owners, lifecycle state	Anything created outside the process	Ownership, service mapping
EDR / endpoint management	Managed laptops and servers, installed software	Unmanaged devices, appliances, network gear	Software inventory, last seen
Cloud provider APIs	Every resource in connected accounts	Accounts nobody connected	Tags, account, region, exposure
Identity provider / directory	Domain-joined machines, service accounts	Non-domain assets	Machine ownership, OU
DHCP, DNS, IPAM	Anything that requests an address or a name	Static, undocumented assets	IP–hostname history
Network scanning (discovery)	Anything that answers on the network	Filtered or offline assets	Open ports, services
External attack surface management	Internet-facing assets, including forgotten ones	Internal assets	Exposure
Container registries, CI/CD, SBOMs	Images, packages, dependencies	Running state	Software components

A useful mental model: the CMDB tells you what the organization believes exists; discovery sources tell you what actually exists. The VOC's job is to reconcile the two and push the differences back to the owners of each source.

Reconciliation and deduplication

The same laptop may appear as an EDR agent ID, a directory computer object, a DHCP lease, three IP addresses over a month and a scanner asset record. Reconciliation merges these into one asset using identifiers in order of reliability:

Strong, immutable IDs: cloud instance or resource IDs, EDR agent IDs, hardware serial numbers, MDM device IDs.
Stable but mutable IDs: fully qualified hostnames, MAC addresses (unreliable for virtual machines and randomized on many mobile devices).
Weak IDs: IP addresses, which should only be used together with a time window.

Keep the source records and the link to the reconciled asset rather than overwriting, so you can explain why two records were merged. The query below finds scanner-discovered hosts that do not match any known asset — the most actionable coverage gap, because it points to things that exist but are unmanaged.

-- Hosts seen by network discovery in the last 7 days with no reconciled asset
SELECT d.ip_address,
       d.hostname,
       d.open_ports,
       MAX(d.seen_at) AS last_seen
FROM   discovery_observations d
LEFT JOIN asset_identifiers ai
       ON (ai.kind = 'fqdn' AND lower(ai.value) = lower(d.hostname))
       OR (ai.kind = 'ip'   AND ai.value = d.ip_address
                            AND d.seen_at BETWEEN ai.valid_from AND ai.valid_to)
WHERE  d.seen_at >= now() - interval '7 days'
  AND  ai.asset_id IS NULL
GROUP BY d.ip_address, d.hostname, d.open_ports
ORDER BY last_seen DESC;

The attributes a VOC needs

Resist the urge to collect everything. These attributes are the ones prioritization and routing actually use:

asset:
  id: "aws:ec2:eu-west-1:i-0abc123def4567890"   # strongest available identifier
  names: ["pay-api-03.prod.example.internal"]
  type: cloud_vm            # server | endpoint | network | cloud_vm | container_image | saas | ...
  environment: production   # production | staging | development | lab
  business_service: "Card payments API"
  owner_team: "payments-platform"   # routable team, not a person
  technical_contact: "oncall-payments@example.internal"
  criticality: 1            # 1 = crown jewel ... 4 = low
  exposure: internet        # internet | partner | internal | isolated
  data_classification: restricted
  lifecycle: in_service     # planned | in_service | decommissioning | retired
  sources: [aws_config, edr, cmdb]
  last_seen: "2026-09-06T21:14:00Z"
  scan_coverage:
    authenticated: true
    last_authenticated_scan: "2026-09-05T02:10:00Z"

Two design choices are worth copying. Owner is a team, not a person, because people change roles and tickets must still land somewhere. And scan coverage is an attribute of the asset, which lets you report coverage directly from the inventory.

Criticality tiers

Criticality should be agreed with the business, documented, and applied consistently. A four-tier example:

Tier	Definition (example)	Typical examples
1 — Crown jewel	Failure or compromise causes severe financial, legal or safety impact	Payment processing, identity providers, domain controllers, core databases
2 — High	Important business service; outage or breach is significant but contained	Customer-facing applications, ERP, email
3 — Standard	Supports business functions; limited impact on its own	Internal tools, most employee endpoints
4 — Low	Non-production, isolated or disposable	Labs, test environments, kiosk devices

Criticality should usually be inherited from the business service: a server hosting a tier-1 service is tier 1. Identity infrastructure deserves special attention, since compromising it compromises everything that trusts it; many organizations place it in tier 1 regardless of the services it supports.

Exposure is separate from criticality. An internet-facing tier-3 marketing site can deserve faster remediation than an isolated tier-2 system, because attackers can reach it without first gaining a foothold.

Ephemeral and cloud-native assets

Autoscaling groups, serverless functions and containers break the "one asset, one record" model. Instead of chasing every instance:

Assess the source of truth. Scan container images in the registry and in CI, and fix vulnerabilities by rebuilding the image. Track the image digest and the workloads that run it.
Inventory the control plane. Cloud accounts, subscriptions, projects, clusters and their configurations are durable assets with owners.
Tag at creation. Require owner, environment and service tags through infrastructure-as-code policies, and treat untagged resources as findings.
Use short "last seen" windows. An instance not seen for a day is probably gone; a physical server not seen for a day may be offline or unreachable — worth investigating.

Measuring completeness

Report inventory quality as a small set of numbers, trended over time:

Ownership coverage: share of in-scope assets with a valid, routable owner team.
Criticality coverage: share with an agreed criticality tier.
Reconciliation gap: assets seen by discovery sources but absent from the inventory (the query above).
Stale records: inventory assets not seen by any source within your threshold.
Assessment coverage: share of assets with an authenticated scan or agent result within policy — covered in depth in vulnerability management metrics.

A practical starting plan

Export assets from the three sources you trust most — usually EDR, cloud APIs and the CMDB — and reconcile them on strong identifiers.
Run a discovery scan of your address space and your external footprint with attack surface management tooling, and list what is not in the reconciled set.
Assign an owner team to every asset supporting a tier-1 service first, then work outward.
Add scan coverage as an asset attribute and publish the coverage numbers monthly.
Push fixes upstream: missing tags go to cloud owners, missing CMDB records to service owners, unmanaged hosts to the team that owns the network segment.

With a measured inventory in place, the next step is choosing how to assess those assets — the subject of vulnerability scanning strategy.