1.2 CBOM Secure Data Flows
This section traces a scan end to end. It is the section most often requested during a customer security review, because it answers where cryptographic data lives at each moment and what transforms it.
1.2.1 High-Level Scan Lifecycle
Every scan, regardless of execution model, passes through the same six stages:
-
Define: an operator builds a template (which sensors, with what configuration) and a task (which hosts or targets that template applies to).
Execute — DiscoveryManager runs the selected sensors against the targets.
-
Emit: results are signed and transmitted to Collector-Services, or written to a file for offline transfer.
-
Stage: the collector validates each document against the crypto material schema and writes it to the staging collection.
-
Consolidate: the deduplication engine computes canonical identity, merges duplicates, updates the deployment footprint, and promotes the material into the inventory.
-
Analyse: policy evaluation, criticality scoring and history capture run over the consolidated record; dashboards and reports read from it.
1.2.2 Discovery and Ingestion Data Flow
A sensor produces one document per discovered item. The document carries the material itself (algorithm, size, state, subject, validity, hashes), a source-properties block describing where it was found (host, port, path, origin, region, resource identifier), and a scan-properties block describing what found it (sensor extension, configuration, scan time, scan host). Provenance is therefore part of every document from the moment it is created, not attached afterwards.
Results are emitted one of three ways:
-
HTTP: the emitter posts to the collector over TLS, authenticating with the host token.
-
Message queue: the emitter publishes to the queue, which the collector consumes. Preferred at scale.
-
File: the emitter writes an encrypted result file. Used for air-gapped targets, and as a retry buffer when transmission fails, so a crashed or disconnected scan is never lost.
The collector authenticates the payload, validates every document against the schema, and rejects the batch if validation fails. Each accepted document is upserted into staging. The collector also writes one accounting row per ingestion call recording how many documents were requested, inserted, updated and skipped. That row is the only place a skipped document is recorded, because a document that fails to upsert leaves no staging row behind — which is why the accounting row exists at all.
1.2.3 Deduplication and Canonical Identity
The same certificate deployed on forty hosts must appear once in the inventory with forty deployments, not forty times. That is what the deduplication pass does.
Each document is assigned a canonical identity derived from its content hash, its type, and its family. Because the identity is derived from content, the cryptographic substance of a material can never change for a given identity — if the bytes differ, it is a different material with a different identity. This has an important consequence for the rest of the platform: the only things that change over a material lifetime are where it lives and what state it is in.
The consolidation pass:
Groups staged documents by canonical identity.
Writes immutable fields once, on first insert only.
Accumulates the mutable footprint on every pass — the host list, path list, deployment list, and their counts.
Pairs host and path into a deployment entry, so the inventory records not just that a material exists on a host but where on that host.
-
Merges related materials: a newly discovered certificate is linked to an already-known key when their public key hashes match.
Removes the staged documents once promoted, and signals the analysis layer that new data is ready.
1.2.4 Post-Scan Analysis and Policy Evaluation Flow
Once a material is in the inventory, analysis runs over it:
-
Policy evaluation: each material is tested against every applicable policy. A policy defines allowed algorithms, minimum sizes, maximum validity and post-quantum posture. The result is a pass or fail per policy per material, and that is what drives the compliance widgets and the summary report.
-
Criticality scoring: each material is assigned a criticality level from configured factors. Factors are type-specific, and the configuration panel offers only the factors the scoring engine actually supports for that type, so a dashboard cannot be configured into a state the analysis layer will reject.
-
Population-derived scoring: some risk is only visible across the whole population. Key reuse is the clearest case: a key is unremarkable on its own and critical the moment a second, unrelated material is found sharing its public key hash. This is why scoring runs as a pass over the inventory rather than per document at ingestion.
-
Tagging: materials are tagged, manually or by rule, and tags become a first-class filter across dashboards, reports and exports through a boolean tag expression language.
1.2.5 Change History Flow
The inventory holds current state only — each scan overwrites the previous state of a material. Without a second store the past would be lost: a material found on one host in May and three hosts in June would show only three hosts, with no record that it spread.
CBOM Secure therefore taps the moment a material is updated and appends a snapshot to a separate audit database. The flow is:
The consolidation pass computes the new state of a material.
It compares that state to the last recorded snapshot across the tracked fields — status, host, path and deployment counts and lists, risk score, tags, and where the material is secured (HSM, software or key management service).
If nothing tracked changed, nothing is written. A re-seen but unchanged material costs one comparison and no storage.
If something changed, a snapshot is appended carrying a version number, a change type (created, updated, reactivated or resolved), the list of changed fields, the previous values, and the scan context that produced the change.
Because identity is content-derived, snapshots track the deployment footprint and lifecycle rather than the cryptographic bytes, which keeps them small. The result is a per-material timeline: when it was first found, where it spread, when it disappeared, and when it came back.