Container images

A repository scan tells you about the code you wrote and the packages you declared. It cannot tell you about the base image underneath them. Connecting a registry closes that gap: Cefense reads an image you have already built and reports the vulnerable operating system packages inside it.

Why the image and not just the repository

Most of what runs in production was never in your repository. A base image brings a distribution's worth of packages with it, those packages get advisories published against them, and nothing in your source tree changes when they do. The image is the artifact you actually ship, so it is the thing worth asking about.

This is where the os-package category comes from. A dependency finding is a package your manifests declare. An os-package finding is a package the image carries.

Connect a registry

1. 1
   Open Images

   In the workspace sidebar, under Sources. Registries and images are managed there and only there: there is no cf command for them.

2. 2
   Choose the registry

   Docker Hub, GitHub Container Registry, Google Artifact Registry, Amazon ECR, or any other registry that speaks the standard OCI API. The last three want the host as well, because there is no single address to assume.

3. 3
   Give it credentials, or do not

   A username and a token are stored encrypted and used only to pull. A registry that serves the image publicly can be connected without any credential at all.

4. 4
   Pick the images

   Docker Hub and GitHub Container Registry can list what is there, so you choose from a list. Every other registry is typed in: the repository, and the tag, which is latest unless you say otherwise.

What a scan of an image does

Cefense resolves the tag to a digest when you add the image, so the scan is against a specific build rather than whatever latest happens to mean later. It then pulls the image over the registry's standard API, reads the package inventory inside it, and looks every package up against published advisories.

The first scan is queued when you add the image. After that, rescanning is a button on the image, which anyone in the organization can press. Rescan when the tag has been rebuilt, or when you want the packages checked against advisories published since.

What comes back

Findings, in the same shape as every other finding: a severity, a CVE, a description, and guidance. What the guidance says is almost always the same shape of answer, because it is almost always the same answer: rebuild on a base that ships a fixed version of that package.

What image findings do not have yet

• No generated patch. There is no file to change: the repair is a rebuild, not a diff. cf fix generate does not apply to them.
• No triage decision. They cannot be marked false positive or accepted risk yet, so there is nowhere to record that you have looked at one.
• No pull request, for the same reason there is no patch.
• No email. A scan report covers a repository. An image scan finishing sends nothing. See Email notifications.
• No CLI. Registries and images are workspace only. cf does not list, add, or scan them.

What they do have is the finding itself, its severity, the CVE behind it, and the package and version it is about, which is what you need to decide whether the next build is urgent.

Who can change what

Registry connections belong to the organization, like every other connection. Disconnecting one removes it for everybody. See Organizations and roles.