Your CMDB Is Wrong. Here Is What Actual Asset Coverage Looks Like
Cybersecurity
Every asset inventory we audit is missing 15-30% of real assets. The gap is where breaches live. Active discovery via cloud APIs, EDR, DNS, and certificate transparency, merged into one source, closes it.
By Arjun Raghavan, Security & Systems Lead, BIPI · January 12, 2024 · 7 min read
A healthcare CIO showed me their ServiceNow CMDB last spring. 12,400 assets. Beautiful dashboards. Then we ran active discovery for two weeks and found 14,800 actual assets in their environment. The 2,400 they did not know about included three forgotten cloud accounts, an entire dev environment a contractor had stood up in 2021, and 180 IoT cameras connected to the corporate network. One of those cameras had a known CVE with a public exploit. Nobody was monitoring it.
Why the CMDB is always wrong
CMDBs depend on people filing tickets. Tickets get filed when assets enter through procurement. They do not get filed when:
- Cloud teams spin up resources via Terraform or console outside the change process
- Mergers and acquisitions add networks faster than asset onboarding can keep up
- Contractors deploy infrastructure for short-term projects and leave it behind
- Shadow IT teams swipe a corporate card for SaaS that connects via SSO
- Edge devices, OT equipment, and IoT join via DHCP and never get registered
The CMDB also rarely gets updated when assets retire. We routinely find 10-20% of CMDB entries are ghosts: hostnames that have not been online in 18 months, virtual machines that were destroyed, accounts that were closed.
The five sources that actually find assets
Stop treating the CMDB as the source of truth. Treat it as one input. Active discovery from these five sources, deduplicated and merged, gets you to 95%+ coverage:
- Cloud provider APIs. Run continuous discovery against AWS Config, Azure Resource Graph, and GCP Asset Inventory. Tag every account you own and audit for accounts you do not.
- EDR agent inventory. Every endpoint with the agent reports itself. Cross-check against AD/Entra to find machines that exist in directory but have no agent, and vice versa.
- DNS records (internal and external). Anything resolving inside your network or pointing at your IP space is your asset.
- Certificate transparency logs. Public CT logs reveal every cert issued for your domains, including ones nobody documented.
- Network metadata (NetFlow, DHCP, ARP). Anything that talks on your network is an asset, even if it has no agent.
Merging the sources
The dedup logic is the hard part. The same machine appears in EDR as a hostname, in cloud as an instance ID, in DNS as an A record, in NetFlow as an IP. We use a graph approach: every fact is a node, links are confidence-weighted, and the final asset record is the connected component.
Tools that do this well include Axonius, Sevco, and runZero. Building it yourself in a graph database (Neo4j or Dgraph) takes 8-12 weeks and works fine if you have the engineering capacity. The build vs buy decision usually comes down to whether you have someone who will own the integrations long-term.
What to do once you have the truth
Visibility without action is just an audit finding. The asset inventory becomes useful when it drives:
- Vulnerability management coverage (every asset has a known scan status)
- EDR deployment gaps (every endpoint either has an agent or has a documented exception)
- Identity hygiene (every cloud account is mapped to an owner)
- Decommissioning workflow (assets idle for 90+ days flag for review)
The political side
When you find the 22% gap, expect resistance. Cloud teams will say 'those accounts are sandboxes, they do not count'. Application owners will say 'that server is on the retirement list, do not pull it into your dashboards'. The gap is a reflection of governance failures, and the conversation gets uncomfortable.
Asset inventory is not a security project. It is a governance project that security inherits because everyone else gave up.
Frame the project as supporting the CIO's cost optimization and the auditor's evidence requirements. Both stakeholders want the same data. Security gets the byproduct, which is knowing what you actually have to defend. That framing gets the project funded faster than 'we need this for security'.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.