Glossary
Terms used throughout the CBOM Secure documentation and interface. Where a term has a specific meaning inside CBOM Secure that differs from its general industry use, the CBOM Secure meaning is given first and the difference is called out.
Core objects
| Term | Meaning |
|---|---|
| Cryptographic material (CM) | Any single cryptographic object CBOM Secure inventories: a key, a certificate, a protocol endpoint (TLS or SSH), a binary, a code signature, or a source-code finding. The umbrella term for everything in the inventory. |
| CM document (CM-Doc) | One validated, deduplicated inventory record. A CM-Doc represents one real-world cryptographic object, however many places it was found. |
| Deposit | A raw sensor result that has arrived at the platform but has not yet been deduplicated. Deposits are transient: they are consumed by the deduplication pass and promoted into the inventory. |
| Canonical identity | The value that decides whether two sightings are the same object. Two results with the same canonical identity become one CM-Doc with two deployments, not two CM-Docs. |
| Deployment | One place a material was found: a host paired with a path, store, vault or endpoint. A CM-Doc carries every deployment it has been seen at, each with its own first-seen and last-seen times. |
| Footprint | The set of deployments a CM-Doc currently has. The footprint is what makes a single key visible as "present on eleven servers" rather than as eleven separate keys. |
| Sensor | A discovery module for one environment or protocol — Azure Key Vault, PKCS#11, LDAP, MSSQL TDE, and so on. Sensors are the only components that read a target system. |
| Connector | An integration that supplies CBOM Secure with information about the estate rather than cryptographic material — a host inventory, a ticketing system, an endpoint agent platform. |
| Emitter | The component inside a discovery agent that transmits results back to the platform. |
| Collector | The platform service that receives sensor results, authenticates the submitting host, validates each document and writes it to the deposit stage. |
Discovery
| Term | Meaning |
|---|---|
| Template | A named, reusable set of sensors with their configuration, defined independently of any host list. |
| Task | A template bound to a list of target hosts. A task is the schedulable, repeatable unit of discovery work. |
| Networked deployment | Discovery in which the platform reaches the target directly over SSH or WinRM, delivers the agent, runs it and collects the result. |
| Cloud deployment | Discovery against a cloud provider's control plane using API credentials. No agent is placed on any machine. |
| Off-grid deployment | Discovery on a network with no route back to the platform. The agent and its task are carried to the target, run there, and the result file is carried back and imported. Also called air-gapped discovery. |
| Agent | The self-contained discovery executable delivered to a target host. It requires no interpreter, runtime or package to be installed on the target, and removes itself after the result is transmitted. |
| Scan | One execution of a task. A scan has a start time, a type (full or incremental), and a set of chunks that the platform accounts for individually. |
| Full scan | A scan that claims to have observed everything in its scope. On completion the platform resolves any material in that scope it did not see, marking it as no longer present. |
| Incremental scan | A scan that claims only to have observed what it reports. Nothing is resolved on the strength of an incremental scan. |
| Resolved | The state of a material that a full scan expected to find and did not. A resolved material is retained with its history intact, not deleted. |
| Reactivated | The state of a previously resolved material that has been discovered again. |
Analysis
| Term | Meaning |
|---|---|
| Criteria | One dimension along which a material is assessed — key strength, certificate expiry, key reuse, storage location, cipher-suite strength, and others. Each criteria produces its own rating. |
| Criticality | The rating a criteria assigns to a material, on a five-level scale. See the Risk and PQC Scoring Methodology page for the per-criteria formulas. |
| Risk score | A 0-100 composite derived from the criticality levels across a population — used for host and enterprise rollups rather than for a single material. |
| Policy | A named set of rules stating which algorithms and key sizes are acceptable. Every material evaluates to Pass or Fail against a policy. |
| Standard policy | A read-only policy baseline shipped with the product, aligned to an external standard such as NIST SP 800-series, PCI DSS or CNSA 2.0. Clone it to obtain an editable copy. |
| Crypto agility | A measure of how readily an estate could change algorithm. Scored from the distribution of algorithms in use and their concentration. |
| PQC posture | The classification of an estate or host by its exposure to quantum attack — which material is already quantum-safe, which is not, and which is in transition. |
| Tag | An operator-defined label applied to hosts, tasks and materials, used for grouping, ownership attribution and filtering. |
| Tag scope | A named, reusable tag expression. Applying a tag scope to a widget narrows what that widget counts, without changing the widget itself. |
Platform
| Term | Meaning |
|---|---|
| Realm | An identity boundary in the identity provider. CBOM Secure resolves the realm at authentication and supports more than one. |
| Session | Server-side authentication state. The client holds an opaque identifier and presents it as a bearer token; the platform resolves it in-process on each request. |
| Role | A named permission set. The shipped roles are administrator, manager, user and auditor; permissions within them are editable. |
| Scope | A single named permission, such as policy:delete. Roles are built from scopes, and the API enforces the scope on every request rather than relying on the interface to hide the control. |
| Widget | One panel on a dashboard. Widgets are defined as data rather than compiled into the interface, so the catalogue can be extended without a front-end release. |
| Layout | The arrangement of widgets on a dashboard, saved per user. |
| Drill-down | Moving from a chart to the table of the records behind one of its groups, carrying the chart's filter through so the table answers exactly the number that was clicked. |
| CycloneDX | The OWASP bill-of-materials standard CBOM Secure exports to. See the CycloneDX Export Specification page. |
| Audit trail | The append-only record of who did what, held separately from the operational database with its own retention and access control. |
| Change history | The append-only record of how a material changed over time, distinct from the audit trail: history tracks objects, audit tracks people. |