2.2 Prerequisites
2.2.1 Operating System Requirements
-
Platform host: a current 64-bit Linux distribution. The stack is developed and tested on Debian and Ubuntu, and the deployment tooling documents Rocky and RHEL as supported build and deploy hosts.
-
Containerised deployment: any host with a supported container runtime, including Windows and macOS for evaluation purposes.
-
Scan targets: no operating system constraint for agentless scanning. For remote-executed scanning, targets may be Linux (Debian, Ubuntu, RHEL, Rocky), Windows, or macOS — the delivered binary is self-contained and requires no runtime on the target.
2.2.2 System Requirements
The figures below are the minimum for an evaluation deployment. Production sizing depends on estate size and, more importantly, on discovery load: scan frequency and scope drive platform load, not inventory size.
-
CPU: 4 cores minimum for an all-in-one evaluation deployment.
-
Memory: 8 GB minimum. The base container stack requires roughly 4 GB before discovery load — MongoDB and Keycloak account for about 1 GB each, with the remainder split between the backends, frontend and logging pipeline.
-
Disk: 20 GB minimum. Container images account for roughly 3 GB; the remainder is database growth, logs and backups. Database growth scales with the number of distinct materials and the length of history retained, not with the number of scans.
-
Free ports on the host: the reverse proxy ports only. Nothing else needs to be exposed.
2.2.3 Software Prerequisites
-
Container deployment: a container engine and Compose v2 or later, plus OpenSSL for generating evaluation certificates.
-
Native deployment: Python 3.12 or later, Node.js 22 or later for building the frontend, and a reachable MongoDB and Keycloak.
-
Deployment server (for remote discovery): the build and packaging toolchain described in section 2.5.
-
Sensor library: the sensor component must be initialised before build, because the platform image copies sensor schemas at build time. A build against an uninitialised sensor checkout produces a platform with no sensors registered.
2.2.4 Network and Firewall
-
Inbound to the platform: the reverse proxy port from user networks, and the same port from any network hosting remote sensors.
-
Outbound from the platform: the scan egress list in 2.1.4, plus HTTPS to any configured integration endpoint.
-
Internal: the service-to-service list in 2.1.4. In a single-node deployment these are loopback or container-network only and require no firewall rules.
No inbound access to MongoDB, Keycloak or the message queue from outside the platform network is required or supported.
2.2.5 Certificate Requirements
The platform needs a server certificate for the reverse proxy, and the deployment must decide between installer-generated and customer-provided certificates before installation rather than afterwards.
Common name and subject alternative names must include every name users and sensors will use to reach the platform. A sensor that reaches the platform by IP while the certificate names only a hostname will fail TLS verification, and the failure appears as an ingestion outage rather than a certificate problem.
The full issuing chain must be supplied, not just the leaf.
Key type and size should meet the deploying organisation's own cryptographic policy. Given the subject matter of the product, a configuration that would pass the platform's own default policy set is the sensible target.
For evaluation, the setup helper generates a self-signed certificate. This is not suitable for production use.
Section 3.3 covers the full certificate inventory, including the collector signing keys and per-host certificates, and the bring-your-own-certificate procedure.
2.2.6 External FQDN and DNS
Choose the external fully qualified domain name before installation. It is written into the platform configuration, into the certificate, and into the identity provider redirect URIs, and changing it afterwards requires touching all three.
Create the DNS record before first start, so that identity provider redirects resolve on the first login attempt.
The frontend and backend URLs in configuration must both use the external name. A mismatch between them is the most common cause of a login that appears to succeed and then bounces back to the login screen.
2.2.7 Identity Provider Prerequisites
A Keycloak instance, either the one supplied with the deployment or an existing enterprise instance.
A realm for CBOM Secure, with a client configured for the platform and the client secret to hand.
Redirect URIs registered for the external FQDN chosen above.
If migrating from an existing instance, export the realm — including users — and place the export where the deployment can import it on first start. The import happens on first start only; a later start will not re-import, so an incorrect export must be corrected before the first boot rather than after.
If federating to a corporate identity provider, see part 4 for the SAML and OIDC procedures.
2.2.8 Preparing Installation Files
Obtain the release archive or clone the repository at the release tag.
Initialise the sensor library component.
Copy the configuration templates to their working filenames. Both the root configuration and the service configuration are required; the platform refuses to start without them.
Prepare the secrets to be filled in: database passwords, the application secret key, the identity provider client secret, the credential encryption key, and the log dashboard administrator password.