SBOM asset inventory reconciliation in practice

SBOM asset inventory reconciliation is the daily job of matching what a software bill of materials says is shipped to what an asset inventory says is running. The gap between those two answers is where real exposure hides, and any CVE queue that ignores it ranks the wrong findings first.

CloudKey’s VulnMonitor runs that reconciliation every day, so the CVE queue maps to the systems your team actually operates, not to a manifest from last quarter’s build.

What an SBOM gives you

A signed SBOM lists the components and versions in a build artifact. It is authoritative for that artifact at that build time.

It does not tell you which hosts are running that artifact, in which environment, behind which network controls, with which patches applied since. SBOMs alone do not produce an actionable CVE queue.

What an asset inventory gives you

A live inventory enumerates the hosts, network devices, endpoints and identities you operate, ideally with version, configuration, and reachability metadata.

It does not tell you with cryptographic confidence which build artifact landed on which host. Drift between the inventory and the truth is the default state.

How SBOM asset inventory reconciliation works

VulnMonitor performs a daily SBOM asset inventory reconciliation:

• For each asset in the inventory, fetch the most recent SBOM hash from the build pipeline that produced its artifact.
• Resolve the SBOM to its component graph.
• Match every CVE in NVD against the component graph, weighted by KEV and EPSS as covered in our prioritization post.
• Filter by reachability: an internet-facing asset weighs more than an internal one, a privileged-access asset weighs more than a sandboxed one.

The output is a ranked CVE queue scoped to assets your team actually operates, with the evidence path traceable end to end.

Where reconciliation fails, and what we do about it

A handful of failure modes show up in almost every deployment:

• An asset reports a software version that does not match any SBOM the build pipeline produced. We flag it as drift, not noise.
• An SBOM is missing for a component the inventory can prove is running. We list it as an evidence gap, with a remediation owner.
• An asset matches multiple candidate SBOMs. We rank by build timestamp and surface the ambiguity, rather than silently picking one.

None of these are solved by deeper scanning. They are solved by closing the loop between build and operations, which is what the reconciliation pipeline is built to enforce.

What this changes for your queue

Every CVE in VulnMonitor lands with a traceable answer to three questions: which asset is exposed, which build produced the vulnerable component, and what is the reachability path that turns this finding into a risk.

If a finding cannot answer all three, it is an evidence gap, not a triage item. Put both kinds on the same queue and you lose the ability to tell them apart, which is exactly when teams start patching the wrong thing.