5.4 Planned Sensor and Connector Coverage (Roadmap)
The sensors and connectors below are planned rather than shipped. They are listed so that a deployment can plan around current coverage. Confirm the status of each against the release in use before relying on it.
5.4.1 Container and Image Sensor
Scans container images for cryptographic material — embedded certificates and keys, bundled crypto libraries, and trust stores baked into a layer.
Matters because a container image is a distribution mechanism for cryptography that no infrastructure scan will see. A weak library in a base image propagates to every workload built on it.
-
Prerequisites to document: registry access and credentials, image size limits, and whether layers are scanned individually or the flattened filesystem.
-
Status: planned.
5.4.2 Artefact Repository Sensor
Scans a binary artefact repository for cryptographic material in published artefacts.
Matters for the same reason as the container sensor: it catches cryptography at the point of distribution rather than at the point of deployment, which means one finding covers every downstream consumer.
-
Prerequisites to document: repository access and credentials, which repository types are supported, remote and virtual repository handling, and artefact size limits.
-
Status: planned.
5.4.3 Vulnerability Scanner Connectors
Collects certificate and TLS findings already gathered by an enterprise vulnerability scanner, rather than re-scanning the estate.
Matters because most enterprises already run one of these across everything, so a connector delivers broad coverage cheaply and without new firewall rules or new credentials on targets. It is the fastest route to first-day coverage in a large estate.
Inherits the scanner coverage and blind spots, and this must be stated — a connector-only inventory is as complete as the scanner is, no more.
-
Prerequisites to document: API access, credentials, report or scan selection, and how findings map onto the crypto material model.
-
Status: planned.
5.4.4 Certificate Lifecycle Connectors
Collects the certificate inventory from a certificate lifecycle manager or PKI. CBOM Secure lists several of these as roadmap: Venafi, Keyfactor Command, HashiCorp, Microsoft AD CS, EJBCA and CertSecure.
Matters because where one of these is deployed it is authoritative for issued certificates, and reconciling it against what CBOM Secure discovers in the field is directly valuable: certificates in the manager that are not deployed, and certificates deployed that the manager does not know about. The second set is the interesting one.
-
Prerequisites to document: API endpoint and credentials, the minimum read role, and how the connector inventory reconciles against discovered deployments.
-
Status: AD CS, EJBCA and CertSecure are covered by the current sensor set; Venafi, Keyfactor Command and HashiCorp are planned.
5.4.5 HSM and Key Manager Connectors
Collects key inventory from hardware security modules and enterprise key managers.
Matters because keys in an HSM are the keys that matter most, and because a key held in an HSM should score differently from the same algorithm and size held in software. The platform already models where a material is secured, so this connector class feeds a distinction the analysis layer can already act on.
Setup detail varies substantially between devices, so each device class needs its own guide covering access method, credential handling and scoping.
-
Prerequisites to document per device: access method (PKCS#11, KMIP or vendor API), credential or PIN handling, partition or slot scoping, and the minimum role.
5.4.6 EDR Connectors Beyond CrowdStrike
Uses an additional EDR platform as the host scan delivery channel, in the same pattern as the existing CrowdStrike integration. Tanium is the most commonly requested.
Matters because the EDR platform in place is a customer decision, and supporting only one means the pattern is unavailable to everyone else — and the pattern is the single easiest way to get host-level coverage in an estate that will not open management protocols.
-
Prerequisites to document: API access, package upload and distribution, remote execution mechanism, host synchronisation and result retrieval.
-
Status: CrowdStrike is implemented and documented in 6.2; other platforms are planned.