Container image scanning (beta)
Container image scanning checks the container images you use for known vulnerabilities, leaked secrets and configuration problems. The scanner pulls each image and inspects its files. Nothing in the image is run. Images can be public or private, and the scan can run on one of your own sensors or on one of our cloud scanners. [!NOTE] Container image scanning is in beta: it works, and we're still refining it. It's marked Beta in the console. Your feedback helps. Container image scanning is included in every plan. Home plans scan from their own sensors, because Home has no cloud scanners. What a scan finds Finding What it means Vulnerable packages Operating system packages (Alpine, Debian, Ubuntu, Red Hat and others) and application libraries (npm, PyPI, Go, Java, Ruby, .NET, PHP, Rust…) with known vulnerabilities. Each finding names the package, the installed version and the version that fixes it. End-of-life operating system The image's base operating system no longer gets security updates. Secrets Keys, tokens and passwords left in the image's files or build history. OrbitalCyber records where the secret is and what kind it is. The secret itself is never stored or shown. Configuration Image configuration checks, for example a container that runs as root or an image without a health check. Each image's repository (for example docker.io/library/nginx) becomes an asset under Assets → Container images. Its findings appear on the Vulnerabilities page like any other finding. A finding is marked fixed when a later scan of the same repository no longer reports it. Start a scan Go to Scans → New scan and choose the scan type Container images. Choose where it runs: one of your sensors, or a cloud scanner. Enter the images, one per line, up to 50. For example: nginx:1.27 ghcr.io/acme/web (no tag means latest) registry.example.com:5000/team/app@sha256:… Optionally include tracked repositories (see below) instead of, or as well as, typing images. You set them up beforehand on the Containers page. For private images, choose one or more registry logins. Each image uses the first chosen login whose scope names its registry. The form shows which login each image will use. Choose the platform (linux/amd64 by default, or linux/arm64). This matters for images built for several platforms. To scan regularly, choose a When option other than Run now, once. See Scans and schedules. Registry logins Add a login under Credentials with the type Containers: registry login: Username and password, or a username and an access token. Use a read-only token where your registry supports one: pulling is all the scanner does. Bearer token, for registries that take a token on its own. Scope: the registry hosts the login may be used for, for example ghcr.io or registry.example.com:5000. Docker Hub can be written as docker.io. A login is only ever sent to a registry in its scope. Logins are encrypted, are sent only to the scanner that runs the scan, and are used only for that scan. Docker Hub limits how often anonymous users can pull images. A Docker Hub login helps if you scan many public Hub images. Tracked repositories Tracking a repository lets OrbitalCyber follow it over time. To set one up: In the console's sidebar, click Containers (just under Targets & ports). Click Track a repository. Enter the repository, for example nginx, ghcr.io/acme/web or registry.example.com:5000/team/app. Optionally enter the tag to follow (default latest) and choose a registry login for a private repository. Click Track. OrbitalCyber checks it straight away. Pick repositories from a registry Instead of typing repositories one by one, you can list the ones a registry shows your login and tick several: On the Containers page, click Browse a registry. Enter the registry (for example harbor.example.com, docker.io, ghcr.io or quay.io), or click one of yours, and choose its registry login. Optionally enter a project or namespace (a Harbor project, or a Docker Hub, Quay or GitHub user or…
OrbitalCyber documentation