1.5 CBOM Secure Security Model
The security model is documented here as a standalone reference. It covers how CBOM Secure protects the credentials it holds, the cryptographic data it discovers, and the interfaces it exposes.
1.5.1 Secrets Management and Encryption
CBOM Secure stores credentials for the systems it scans — SSH accounts, cloud service principals, database logins, HSM PINs, API tokens. These are never stored in plaintext.
Stored credentials are encrypted at the application layer before they reach the database, using a symmetric key held in service configuration and not in the database. Compromise of a database backup alone does not yield usable credentials.
Encrypted values carry an explicit prefix, so it is always determinable whether a stored field is encrypted, and an unencrypted value cannot be silently mistaken for one.
Credentials are masked on every read path. API responses that include an integration or host record return a sentinel in place of the secret, and writing that sentinel back does not overwrite the stored credential — so an operator editing an integration cannot accidentally blank its password simply by saving the form.
Raw credential values are never written to logs.
1.5.2 Data in Transit
All external traffic is TLS-terminated at the reverse proxy. No service is directly exposed.
Discovery result submission is TLS-protected and additionally authenticated per host with an RS256 token.
Discovered material can be encrypted end to end from the target to the platform. The host and the platform each hold an ECDH key pair; a shared secret is derived and run through a key derivation function to produce the encryption key for the material payload, and the payload is signed by the host with its ECDSA key. ECDH is used in preference to RSA key transport because it fits a post-quantum migration path better.
Remote delivery channels are the standard authenticated ones: SSH and SFTP for Linux, WinRM and SMB for Windows.
1.5.3 Data at Rest
Discovered material, host inventory, tasks, policies and configuration are held in MongoDB. Deployments should enable the database platform encryption-at-rest and access controls; the platform does not substitute for them.
Credentials within those records carry the application-layer encryption described above, so they are protected independently of database-level encryption.
Change history is written to a separate database so that it can carry its own retention policy and its own access control.
-
CBOM Secure records cryptographic metadata: algorithms, sizes, subjects, validity, public keys and hashes. It does not extract or store private key material.
That last point bears repeating. CBOM Secure builds an inventory of cryptographic metadata; at no point does it extract, transmit or store private key material.
1.5.4 Authentication and Authorization
Authentication is delegated to Keycloak. CBOM Secure holds no user passwords — only a subject reference, the user record, and the role assignment.
Sessions are server-side. A client holds an opaque session identifier and presents it as a bearer token; the token is resolved in-process against the session manager, so no round trip to the identity provider occurs per request.
Sessions have a bounded lifetime and are renewed by the client before expiry. Renewal rotates the token. A background reaper evicts expired sessions, with a grace window while a refresh token is present, so a client that has been briefly offline can recover its session rather than being forced to re-authenticate.
Authorization is role-based and evaluated per request from the session role set. The shipped roles are administrator, manager, user and auditor, and permissions are assigned in groups rather than individually.
Role changes take effect immediately. Changing a user role updates their live session rather than waiting for the next login, and deleting a user revokes their live sessions. Both matter for offboarding.
1.5.5 Collector Trust Model
The ingestion endpoint is the platform component most likely to be exposed to a less-trusted network, so its trust model is set out here in full.
Every submitting host is registered and issued its own host identity and certificate.
A submission carries an RS256 token whose subject is the host identifier. The collector looks the host up, retrieves its certificate, and verifies the signature against it.
There is no shared ingestion secret. A compromised host can submit only as itself.
Tokens are issued with a bounded lifetime and rotated per deployment. Signing keys are versioned, and the previous signing certificate remains retrievable so that tokens already in flight still validate across a rotation.
The collector validates every document against the schema before writing, so a compromised host cannot inject malformed or unexpected structures into the pipeline.
The collector writes only to the staging collection. It cannot modify the consolidated inventory, the policy set or the configuration.
1.5.6 Multi-Tenant Isolation (Roadmap)
Multi-tenant isolation is designed and specified but not yet implemented. What follows describes the planned architecture and should be read as roadmap rather than as current capability.
Tenant identity is carried as a claim in the access token. A token may carry several tenants with a different role in each, plus an active tenant selection.
Isolation is by database, not by row filter. A platform database holds the tenant registry, global configuration, global audit and tenant limits; each tenant has its own database holding its own material, hosts, tasks, policies, findings and audit.
A tenant router resolves the tenant from the token and selects the database. No query spans tenants.
-
Ingestion is tenant-aware: the sensor token itself carries the tenant, so a misdirected submission cannot land in the wrong tenant database.
The analysis layer runs per tenant, with tenant-specific policy sets and per-tenant resource quotas, so one tenant analysis load cannot starve another.
Queue partitioning, rate limiting and audit logging are all per tenant.
1.5.7 Audit Trail
Every meaningful change to a discovered material is versioned in the audit database with its change type, the changed fields, the previous values, and the scan context that caused it.
Configuration is versioned. Each change creates a new version with the prior version retained and restorable, so a bad configuration change is both recoverable and attributable.
-
Ingestion is accounted per call: requested, inserted, updated and skipped counts — which gives a defensible record of what a scan actually delivered rather than what it was asked to deliver.
Application logs are shipped off the service host into the central log store, so log retention is independent of the service lifecycle.