GRC · Risk & vulnerability
Asset inventory is the foundation of risk and vulnerability management
You cannot calculate exposure without knowing which assets exist, which vulnerabilities affect them, and which threats could exploit those gaps — and inventory only helps when discovery does not pollute the CMDB.
AEK Tech
Enterprise engineering company

Working on risk management in our GRC platform made one thing obvious: asset inventory, vulnerabilities, and threats only help when they connect. Keep them as separate lists and you are scoring opinions, not exposure.
You cannot calculate risk exposure without knowing which assets exist, what vulnerabilities affect those assets, which threats could exploit those vulnerabilities, and how that maps to business risk.
Without a trusted asset inventory, you are calculating risk on incomplete data.
Getting assets into the inventory without polluting it
Discovery is easy to overpromise. Scan-and-auto-create sounds efficient until multicast noise, cross-tenant mistakes, or partial scans land in the CMDB. Asset Discovery v1 on the platform treats this as a controlled pipeline: Collect → Review → Import → Enrich. An on-prem connector gathers reachability evidence from configured ranges (mainly ICMP and ARP in v1, plus JSON/HTTP ingest). Findings stage in a review inbox. Only human-approved discoveries become inventory records. After import, suggestions for relationships, classification, and control mappings stay evidence-bound and require accept or dismiss — not silent writes.
That is not complete enterprise network visibility. It is honest reachability on what the connector can see, with people still deciding what the CMDB trusts. Discover first. Review before import. Enrich with evidence.
The chain that has to exist
Most systems treat these as separate modules. What we are building is a chain you can follow and defend:
- Track vulnerabilities against the assets that actually exist
- Map risks to vulnerabilities with exposure levels and confidence
- Map risks to threats for impact assessment
- Full path: Asset to Vulnerability to Risk to Threat to Control

CVSS as an input, not a pretty widget
A CVSS v3.1 calculator is useful when the score feeds the rest of the model. Base, temporal, and environmental metrics. Vector strings you can copy. Severity from none to critical. Those scores should inform vulnerability assessment, which then informs risk priority, weighted by how critical the asset is.
- CVSS scores feed vulnerability assessment
- Vulnerability exposure levels inform risk scoring
- Threat likelihood plus vulnerability score drives remediation priority
- Asset criticality weights the final risk score

Putting it together
Same idea as compliance overall. When a CVE hits a critical asset, the system should calculate CVSS, map it to risks, and prioritise remediation. Automatically where it can, explainably always, on data you trust — including inventory that was reviewed before it entered the CMDB.
That is how asset inventory, vulnerability management, and risk assessment become one system instead of three spreadsheets that disagree.

