Container Images
Container Images
Inventory the cryptographic services and their TLS configuration inside running containers and container images, pulled from any OCI registry with or without a Docker daemon.
Overview
The Docker CBOM Scan rebuilds the file system of a container or image and runs the scanner's service-detection engine over it. It answers: which crypto-bearing services ship in this image, and how is their TLS configured?
Three ways to scan
| Mode | How it works | Requirements |
|---|---|---|
| Running containers | Lists the containers running on the Docker host and streams the file system of the ones you select. | The Docker CLI available where the Cockpit runs (self-hosted deployments). |
| Pull & scan an image | Pulls an image, starts a throw-away container without running its normal entrypoint, scans it and stops it. | Same Docker host; works with any registry that host can pull from (credentials, when given, are used for the registry login of that host). |
| Scan from registry (no Docker) | Downloads the image layers directly through the OCI Distribution v2 API, applies them in order (including deleted-file markers) and scans the result. Multi-architecture images resolve to linux/amd64. | Network access to the registry. No Docker daemon needed: suited to batch scans and CI runners. |
Harbor browsing
For a Harbor registry, the wizard can list what a robot account can see (projects > repositories > tags), so you select the images to scan instead of typing references. Selected images are scanned as a batch, one after the other.
Registry authentication
Public images need no credentials. For private repositories, give a username and password or token (for example a Harbor robot account or a registry access token). Passwords and tokens are not stored with the scan job; only the username is recorded. For a registry behind an internal certificate authority, registry scans through the API accept a per-scan option to relax TLS verification.
What is detected
| Item | Details |
|---|---|
| Operating system and packages | The image distribution and the number of installed packages, read from the Debian / Ubuntu (dpkg) and Alpine (apk) package databases. |
| Crypto-bearing services | About 80 service definitions: web servers and proxies (nginx, Apache, HAProxy, Traefik, Caddy...), SSH and VPN (OpenSSH, Dropbear, OpenVPN, strongSwan, WireGuard), mail (Postfix, Exim, Dovecot), directories, databases (PostgreSQL, MySQL / MariaDB, MongoDB, Redis, Cassandra, Elasticsearch...), message brokers (Kafka, RabbitMQ, ActiveMQ, Mosquitto), container and orchestration runtimes, and embedded / IoT services. Each detection says how it was found (binary, configuration file or package) and with which evidence. |
| Crypto configuration | For each detected service, the cryptographic directives of its configuration files: TLS protocol versions, cipher suites, server cipher preference, OCSP stapling, session settings, and the certificate, private-key and CA file locations they reference. Each directive is mapped to a normalised property so services can be compared. |
Results are shown per container or image (packages, detected services, extracted directives, evidence, parse warnings) and can be downloaded as JSON. Scans run as server-side jobs, so you can leave the page and come back to the result.
Limits
The service detection described above reads package databases and configuration files. The crypto inside compiled artefacts of the image (ELF, PE and Mach-O executables and libraries, .NET assemblies, Java classes and JAR / WAR / EAR archives) is inventoried by the binary scan, which every image scan also runs over the image file system; its results appear per container under Crypto in compiled artefacts. See that page for what it reads, its confidence levels and its limits. Certificate and key files are located through the configuration that references them; their contents are not parsed by the service detection.
| Limit | Details |
|---|---|
| Package inventory | Debian / Ubuntu and Alpine package databases. Services are still detected on other distributions, but the package count is not read. |
| Image size | Registry scans stop above a layer-download cap (500 MiB by default, adjustable per scan). |
| Signatures | Image signatures (cosign, Notary) are not verified by this scan. |
| Private networks | Registries on private addresses are blocked unless your platform administrator allows them for your deployment. |
To inventory certificates and keystores themselves (PEM, DER, PKCS#12, JKS), use the filesystem scan on the host or a mounted image. For artefacts stored in JFrog Artifactory, including container images and Java dependencies, use the JFrog Artifactory source.
How to run
Open the Docker Scan
In the Cockpit, open the PQC Readiness module and its Docker Scan tab. It requires the permission to create PQC scans.
Choose the mode
Pick Running containers, Pull & scan an image or Scan from registry (no Docker).
Select what to scan
Tick running containers, or enter an image reference such as harbor.example.com/team/api:1.0 or nginx:alpine with optional credentials, or browse a Harbor registry and select tags.
Review the result
Review detected services and directives per image, and download the JSON report.