Container images

Add an image repository, such as ghcr.io/acme/api, as an asset. Interopt reads every package installed in the images your tracked tags point at and matches them to known advisories, in the same Dependencies views as your repositories.

Container image scanning is included on Team and up, and uses no credits.

Adding an image

Choose Container image when adding an asset, enter the repository, and pick the registry connection to pull with. Public images can be pulled without a connection; Amazon ECR, Artifact Registry and Azure Container Registry always need one. See Connecting a registry.

Which tags are tracked

Each image repository tracks any combination of:

• Tags by name, such as latest or 2.4.
• Patterns, where * matches any run of characters and ? one character: v* tracks every tag starting with v.
• The newest tags: the newest N tags by build time, among the tags your patterns match, or among all tags when there are no patterns.

You can also limit a multi-platform image to some platforms, such as linux/amd64. Without a limit, every Linux platform in the image is read.

When images are scanned

Interopt checks the tracked tags hourly, daily or weekly, as you choose for each image, or right away with Check now. When a tag points at a digest Interopt has not read before, that digest is scanned.

A digest is read once. Its contents never change, so its advisories are checked again every day against the packages already found, without pulling the image again.

When a tag moves to a new digest, packages only the old digest installed are marked fixed, and the history of what was installed stays on the asset.

What is read

For each platform image:

• OS packages from the package database: Debian, Ubuntu, Alpine, Wolfi, Chainguard, Red Hat, Rocky, AlmaLinux, SUSE, openSUSE, Azure Linux, Photon OS, openEuler and Mageia.
• Language packages that are installed in the image: npm, PyPI, Go binaries, Cargo binaries built with cargo-auditable, Maven archives, RubyGems, Composer, NuGet and Pub, plus packages listed in SBOMs the image ships.
• Lockfiles for ecosystems whose installs leave no record: Hex, Hackage, CRAN, Conan and Swift.
• The layer that added each package, and the command that created that layer.

Nothing in the image is run. Layers are read as archives, and only the files the package readers need are kept while the image is read.

The image overview

• The digest and platforms scanned, and the tags pointing at them.
• The operating system and its release.
• Every layer, with the command that created it and the packages it added.
• The base image, when it could be identified.

OS packages are matched under the source package the distribution files its advisories by, so libssl3 shows as openssl. The fix advice for an OS package says what to rebuild:

• Added by the base image: rebuild on a newer release of that base image, named when it was identified.
• Added by one of your own layers: rebuild the image, so the install step picks up the fixed version.

What shows as not checked

A package Interopt can't look up is listed as not covered, with the reason, rather than shown as clean:

• An unrecognised distribution, or an image with no /etc/os-release.
• A release the advisory sources don't track, such as Alpine edge or Debian sid.
• Chiseled images, which list binary packages only, while advisories are filed under source packages.
• Package types with no advisory source, such as conda packages.

Files that list packages but could not be read are named on the image's Dependencies tab, with the reason. A digest the registry refused, or one that could not be read, shows its error on the image overview, and Scan again retries it once the cause is fixed.

Base images

To name the base image, Interopt sends the image's layer hashes to deps.dev, which recognises layers from public images it has indexed. Only hashes are sent, never names or contents. Without a match, the build history's last CMD or ENTRYPOINT before your own layers marks where the base image ends. You can turn the lookup off per image.