Asset Inventory

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

Every part of vulnerability management assumes you know what you have. You can't scan an unknown host, can't prioritise a vuln on an asset whose importance you don't know, and can't confirm remediation on something that isn't tracked. The asset inventory is the unglamorous foundation the whole programme stands on — and incomplete inventories are why breaches so often start on a "forgotten" server. This skill covers building and maintaining an inventory that actually enables the rest.

When to use it

Before or alongside standing up vulnerability scanning — it defines the scope everything else operates on. Also whenever coverage gaps appear ("we didn't scan that box because we didn't know it existed"). It's foundational, which is exactly why it's often neglected and worth doing deliberately.

Procedure

1. Discover assets from multiple sources — no single source is complete. Combine network discovery scans, cloud provider APIs (assets spin up and down constantly), endpoint/agent data, DHCP/DNS records, CMDB entries, and the OSINT view (what's exposed externally). Each source finds what others miss; together they approach completeness.
2. Cover all asset types, not just servers — workstations, cloud instances and services, containers, network devices, IoT/OT, and SaaS. Modern estates are heterogeneous, and the forgotten categories (a cloud account nobody owns, an IoT device) are where risk hides.
3. Enrich each asset with the context that drives prioritisation — owner, business criticality, data sensitivity, environment (prod/dev), and network exposure. A vuln's real risk depends on the asset it's on (cvss-in-context), so the inventory must carry that context.
4. Assign ownership. Every asset needs an owner who's accountable for remediating its vulnerabilities. Ownerless assets are exactly the ones that never get patched — the "who fixes this?" gap is an inventory gap.
5. Keep it continuous and current. Assets change constantly, especially in cloud; a static inventory is wrong within days. Automate discovery and reconciliation so new assets appear and decommissioned ones are retired.
6. Reconcile sources to find the gaps — assets in one source but not another (in DNS but not scanned, in the cloud but not the CMDB) are the blind spots. Chasing those discrepancies is how you find the forgotten, unmonitored systems.

Cheatsheet

no single source is complete — COMBINE
  network discovery | cloud APIs | endpoint agents | DHCP/DNS | CMDB | OSINT (external)

cover ALL types (not just servers)
  servers | workstations | cloud instances+services | containers | network devices
  | IoT/OT | SaaS

enrich each asset (this is what makes vuln prioritisation work)
  owner (accountable for fixes) | business criticality | data sensitivity
  | environment (prod/dev) | network exposure (internet-facing?)

keep current: automate discovery + reconciliation (cloud changes daily)
find blind spots: reconcile sources -> assets in one but not another = the forgotten ones

why it matters: can't scan / prioritise / verify-fix what you don't know exists.

Reading the inventory

• Assets missing from the inventory = unscanned, unmonitored, unpatched — the classic breach entry point ("the server nobody knew was still running"). Reconciling sources surfaces these; it's the highest-value use of the inventory.
• Assets with no owner = nobody accountable for their vulnerabilities, so they never get fixed. Ownership gaps are remediation gaps.
• Missing criticality/sensitivity/exposure context = you can't prioritise vulns on the asset properly (a critical on the crown-jewel DB vs a throwaway test box look the same). Enrich it.
• A static, months-old inventory = wrong, especially for cloud; it silently drops new assets and keeps dead ones. Continuous discovery is the fix.
• Discrepancies between sources (in DNS but not scanned, in cloud but not CMDB) = the blind spots; chase them.
• A continuous, enriched, owned, multi-source inventory = the foundation that makes the rest of vuln management actually work.

The fix / best practice

• Combine multiple discovery sources and reconcile them — completeness comes from the union, and the gaps between sources reveal the forgotten assets.
• Cover every asset type, including cloud, containers, IoT/OT, and SaaS — not just traditional servers.
• Enrich with owner, criticality, sensitivity, environment, and exposure so downstream prioritisation and accountability work.
• Automate and continuously reconcile so the inventory tracks a constantly-changing estate.
• Treat ownership as mandatory — an asset without an owner is a vulnerability without anyone to fix it.
• Recognise this as foundational: invest here first, because scanning, prioritisation, and verification all inherit its completeness.

Pitfalls

• Treating it as a one-time spreadsheet. Estates change daily, cloud especially; a static inventory is quickly wrong and drops new assets silently. Automate.
• Relying on a single source. Any one source (a CMDB, one scanner) has gaps; the forgotten asset is precisely the one it missed. Combine and reconcile.
• Only tracking servers. Cloud services, containers, IoT/OT, and SaaS carry real risk and are easy to omit. Cover all types.
• No ownership. Assets nobody owns are assets nobody patches — the ownership gap is where vulnerabilities live forever.
• Inventory without context. Without criticality and exposure, you can't prioritise; the inventory has to carry the data that risk-based triage needs.

References

• CIS Controls 1 & 2 (Inventory of Enterprise Assets and Software) — the foundational controls
• NIST SP 800-40 (vulnerability management) and cloud asset-management guidance
• The vulnerability-scanning and cvss-in-context skills (which depend on this)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.