How data enters AVM

Import is not the end of the process

AVM imports inventory through staged workflows. Asset data and software data are first validated into staging records before being committed into the main operational tables. This helps keep import behavior visible and reviewable.

Software import preserves raw values such as vendor, publisher, product, and version information. Those raw values are important because canonical resolution and vulnerability matching happen after import, not instead of import.

Assets first, then software

AVM expects software rows to be tied to assets. In practice, this means asset records should exist before software is imported against them.

The asset acts as the host anchor for later software review and alert generation, so software import depends on asset identity being available.

How assets and software are linked

In AVM import, software rows are not linked to assets by internal IDs. Instead, both asset and software JSON use the same external_key to establish the relationship.

This means that the asset and its software must share the same stable external identifier during import.

Minimal asset example

{
  "external_key": "example-uuid-0001",
  "name": "server-01"
}

Minimal software example

{
  "external_key": "example-uuid-0001",
  "product": "Docker Desktop",
  "vendor": "Docker Inc.",
  "version": "4.60.1"
}

During import, AVM resolves this shared external_key to an internal asset_id. The software row is then stored as a record linked to that asset.

The external_key should remain stable across imports. If it changes, AVM will treat the asset as a different system.

Example osquery queries

The following examples show how similar data can be collected using osquery. In practice, these results are transformed into AVM JSON format before import.

Asset-side example

osqueryi --json "
SELECT
  uuid AS external_key,
  hostname AS name
FROM system_info;
"

The system_info table provides stable host identity such as uuid and hostname, which can be mapped to AVM asset fields.

Software-side example (Windows)

osqueryi --json "
SELECT
  (SELECT uuid FROM system_info LIMIT 1) AS external_key,
  name AS product,
  publisher AS vendor,
  version
FROM programs;
"

The programs table provides installed software inventory. The external_key is typically injected during transformation to link software rows to the corresponding asset.

Richer asset example

AVM assets can preserve significantly more host context than the minimal external_key plus name shape. This becomes useful when your source already knows operating system, hardware, CPU, and host identity details and you want that context to remain available inside AVM.

{
  "arch": "64-bit",
  "asset_type": "endpoint",
  "computer_name": "example-host-01",
  "cpu_brand": "Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz",
  "cpu_logical_cores": "2",
  "cpu_physical_cores": "2",
  "cpu_sockets": "1",
  "external_key": "example-uuid-0001",
  "hardware_model": "VirtualBox",
  "hardware_vendor": "innotek GmbH",
  "hardware_version": "-1",
  "hostname": "example-host-01",
  "local_hostname": "example-host-01",
  "name": "example-host-01",
  "os_build": "26200",
  "os_major": "10",
  "os_minor": "0",
  "os_name": "Microsoft Windows 11 Pro",
  "os_version": "10.0.26200",
  "owner": "example-team",
  "physical_memory": "-1",
  "platform": "windows",
  "serial_number": "example-serial-1234",
  "source": "OSQUERY",
  "system_uuid": "example-uuid-0001"
}

This maps naturally to AVM asset-side fields in the assets table: host identity (external_key, name, hostname, computer_name, local_hostname, system_uuid, serial_number), platform and OS (platform, os_name, os_version, os_build, os_major, os_minor, os_patch, arch), hardware (hardware_vendor, hardware_model, hardware_version, board_vendor, board_model, board_version, board_serial), and CPU or memory context (cpu_brand, cpu_physical_cores, cpu_logical_cores, cpu_sockets, physical_memory).

How osquery data maps into AVM records

osquery is usually not exported into AVM one-to-one. Instead, a transformation step reads osquery tables and builds AVM-shaped asset and software JSON that matches the fields AVM can actually store.