1.3 Scan Execution Models
CBOM Secure supports four execution models. They differ in where the sensor code runs and how results reach the platform. The choice is driven by network reachability and by what the target will allow to be installed.
1.3.1 Platform-Executed (Agentless) Scans
Sensors run on the platform and reach out to the target over the network or a provider API. Nothing is installed on the target.
-
Used for: TLS and SSH endpoint scanning, cloud key management and key vault enumeration, HSM access over PKCS#11 or KMIP, directory services, database transparent-data-encryption configuration, and PKI or certificate lifecycle systems.
-
Requires: network reachability from the platform to the target, and a credential or role with read access to the target API.
-
Advantages: no target-side footprint, no change control on the target, immediate coverage.
-
Limits: sees only what the target exposes over the network. Cannot enumerate the filesystem, installed binaries, local keystores or source code.
1.3.2 Remote-Executed Scans
DiscoveryManager is packaged as a self-contained binary, delivered to the target, executed there, and emits its results back to the collector.
-
Used for: filesystem key and certificate discovery, local keystores, operating system certificate stores, installed binaries and crypto libraries, disk encryption, keyrings and wallets, and source code trees.
-
Delivery: SSH and SFTP for Linux targets, WinRM and SMB for Windows targets, driven from the deployment server.
-
Target prerequisites: no Python or dependency installation is required — the binary is self-contained. Linux targets need SSH reachable; Windows targets need WinRM enabled and the firewall opened for it.
-
Per-host trust: each registered host is issued a host identifier, a token for collector access whose subject is that identifier, and a signing key pair. Results are signed by the host and the payload is encrypted to the platform, so a compromised host cannot submit data as another host.
1.3.3 EDR-Orchestrated Scans
Where an endpoint detection and response agent is already deployed and trusted, it can be used as the delivery and execution channel instead of direct SSH or WinRM. The platform provides the sensor package; the EDR platform distributes it, runs it, and returns the output. This avoids opening management protocols across the estate and reuses an agent that is already change-controlled and already has the necessary local privilege.
CBOM Secure implements this pattern with CrowdStrike Falcon: hosts are synchronised from Falcon into the CBOM host inventory, the sensor package is uploaded to Falcon, and Real Time Response scripts check, run and undeploy the sensor under the control of a Falcon workflow. Section 6.2 documents the full procedure.
1.3.4 API-Triggered Scans
Any task can be created and executed through the REST API rather than the portal, which is what allows discovery to be driven from a build pipeline or an external scheduler. The pattern is: authenticate, create or reference a template, create a task binding that template to targets, execute the task, then poll status. The endpoints are listed in the platform’s interactive API reference, published at /docs on the CBOM-Server host.
-
Typical uses: scanning a build artefact or repository as a pipeline step, re-scanning on change rather than on a fixed schedule, and driving discovery from an existing enterprise orchestration tool.
1.3.5 Off-Grid (Air-Gapped) Execution
For targets with no network path to the platform at all, CBOM Secure builds a sealed, self-contained bundle that an operator carries to the isolated side, runs, and carries back. Off-grid discovery is a first-class execution model rather than a workaround: the bundle is signed, expiring and bound to the task that produced it, and its results are ingested through the same pipeline as any other scan.
The flow is:
The operator creates a task and marks it for off-grid delivery, choosing a target platform (Linux, Windows or macOS) and a bundle variant.
The platform builds a bundle containing the DiscoveryManager executable, the sensors, the task definition, a manifest listing every file with its SHA-256 digest, and a keyed signature over that manifest. The bundle carries an expiry date.
-
Two variants are available: a full variant including sensor source for internal trusted operators, and a compiled-only variant for external or contractor use.
The operator downloads the bundle, transfers it on removable media, and runs it on the isolated host. The emitter is configured to write to file — no network transmission is attempted, so the bundle is safe to run on a network that must remain isolated.
The result archive is cryptographically bound to the originating task, so it cannot be replayed against a different task or tampered with undetected.
The operator carries the result back and imports it through the portal. The import engine validates the binding, then feeds the documents into the same staging and deduplication path as any other scan.
Off-grid results are not a second-class dataset. Once imported they are deduplicated, scored, policy-evaluated and versioned exactly like network-delivered results, and they appear in the same dashboards.
1.3.6 Choosing an Execution Model
Target reachable over the network and only network-visible crypto is in scope — platform-executed.
Target reachable and filesystem, binary or source-level crypto is in scope — remote-executed.
Target reachable but management protocols are closed and an EDR agent already exists — EDR-orchestrated.
-
Target unreachable: off-grid.
Scan must be driven by a pipeline or an external scheduler — API-triggered, layered over any of the above.