Skip to content

Extending to images and registries

Most support matrices only describe where a product runs. Products that inspect container images also have a second matrix: what they can understand. That needs a different kind of test environment. This page describes how the framework extends to cover it. It's a design, scoped from my notes, rather than a delivered topology.

Two families of support matrix dimensionsRuntime topologies cover where the product runs. Images and registries cover what the product understands.Support matrix dimensionsRuntime topologiesWhere the product runsVM hosts and Kubernetes clustersOS image and architectureK8s version, container runtimeNetwork plugin, install methodProven by: provision, install, testImages and registriesWhat the product understandsImage formats: Docker, OCIBuild tools that produce themBase OS and package managersLanguage libraries, file typesProven by: scan a curated corpus

Dimensions

Dimension Examples Why it can break
Image format Docker, OCI Manifest and layer metadata differ between formats
Build tool Dockerfile builds and non-Dockerfile builders The same app built two ways can produce different layer layouts
Base OS Minimal and enterprise distributions Each distribution records installed software differently
Package assessment apk, rpm, dpkg databases The product must read each package database correctly
Language libraries Each supported language ecosystem Dependencies live in language-specific manifests and file types
Registry Cloud provider registries, Docker Hub Authentication and discovery differ per registry

Two registry integration patterns

Registry testing splits by how a scanner learns that an image exists, and each approach needs a different test setup:

Continuous discovery On-demand pull
How images are found The scanner watches a registry and picks up new pushes by itself The scanner is pointed at an image and pulls it through the registry's API
What a test must prove New pushes are discovered and scanned within the expected window Manifests and layers are fetched and assessed on request
Test setup Push a known image, then wait and assert Point the product at a known image and assert directly

A curated test corpus

Instead of provisioning hosts, this side of the matrix is proven by scanning a curated set of images whose contents are known in advance:

  • one image per base OS and package manager;
  • images with dependencies from each supported language ecosystem;
  • the same application built with each supported build tool;
  • each image pushed to each supported registry type.

Because the expected packages and libraries are known, assertions are exact: the scan should find these packages and these libraries, and nothing should be missing.

How it fits the framework

Scanner runs would reuse the same layers as the topology runs:

  • Trigger intake: a new scanner version, base OS release or registry type becomes a trigger.
  • Configuration generation: triggers are turned into scanner run parameters.
  • Validation and reporting: the same factories, publishers and tracking ticket.

Only the provisioning step would differ. Instead of building hosts, it prepares images and registry access.