Container image scans, read for lineage.

Container image scans surface in Red Hat audits because the underlying base image's entitlement obligations follow the running container. A workload running on a Red Hat Universal Base Image inherits the UBI redistribution terms; a workload running on a full RHEL base image inherits the RHEL subscription obligation; a workload running on a community CentOS Stream image inherits a different set of terms. The audit team that asks for image scan data is asking, indirectly, for evidence of which base image lineage the workload runs on.1

The practice's reading is that the image scan request is a proxy for a question the audit team should ask directly: which base images run in this estate, and what does the audit clause cover. The defended response answers the direct question with an image inventory and provenance map, rather than producing raw Clair or Trivy scan output that the audit team must interpret. The parent service note on Red Hat audit defense treats the general evidence posture; the present note treats the container application.

Clair is the open source scanner that backs the Red Hat Quay registry; Trivy is the open source scanner that backs many other container platforms. Both scan container images for vulnerabilities and produce structured reports that include the image's layer history and base image identification. Quay registry metadata adds image signing information, push timestamps, and the registry's own provenance data. The defended response that produces image evidence can draw on any of these sources; the choice depends on what the customer's platform actually runs.

The Red Hat container catalog provides authoritative provenance for Red Hat published images. The catalog's image hashes correspond to known Red Hat builds; an image whose hash matches a catalog entry has known provenance. An image whose hash does not match any catalog entry was either built by the customer (typically from a Red Hat base) or built from a non Red Hat base. The defended production maps each running image to its catalog entry where one exists and to a build chain where one does not. The companion note on RHEL UBI licensing rules treats the UBI redistribution terms in depth.

Red Hat Universal Base Image is freely redistributable on terms set out in the UBI EULA. Workloads running on UBI base images do not require a per workload RHEL subscription; they do require that the user respect the UBI terms. Workloads running on full RHEL base images, by contrast, require an entitlement for the underlying RHEL workload. The boundary between UBI and RHEL is the boundary that the audit team's claim typically rests on.

The defended production identifies which running images derive from UBI and which derive from full RHEL or a non Red Hat base. The Red Hat container catalog hash match is definitive for Red Hat published images; for customer built images, the build chain documentation (Dockerfile, build pipeline, base image FROM line) establishes the derivation. The companion note on Podman, Buildah, and Skopeo licensing treats the tooling side; the audit application is that the build chain is itself the evidence.2

OpenShift core counting depends on running workloads, not on registry contents. A registry full of images that are not running does not generate an entitlement obligation. The defended response distinguishes the registry inventory from the running workload inventory; image scans across the entire registry inflate the picture. The companion note on OpenShift core counting in virtualised environments treats the running workload count in depth; the audit application is that image scans are an input to that count, not a substitute.

OpenShift's own entitlement reporting through Subscription Watch and Insights provides an additional evidence source that frequently overrides image scan inference. The defended response cross checks Subscription Watch output against image scan derived counts and addresses any discrepancy in the accompanying memorandum. The companion note on Subscription Watch versus own data treats the discrepancy patterns.

Container images frequently contain proprietary customer code, configuration, or data. Raw image scan outputs may include file listings, package versions, and configuration fragments that reveal trade secret information. The defended response curates the production to the entitlement relevant data and withholds the rest under standard confidentiality terms. The audit team's request for raw scan output across all images is materially broader than the audit clause typically permits.

The customer's own image scanning tooling frequently generates scan reports as part of CI or CD pipelines. Those reports are internal artifacts and are not necessarily part of the audit production. The defended response treats the existence of scan reports as separate from the obligation to produce them; production follows the contract, not the customer's internal data lifecycle.

Customers running Red Hat Advanced Cluster Security have additional image scan data through StackRox derived tooling. The ACS posture interacts with audit evidence in two ways. First, ACS scan output is internally consistent with the OpenShift entitlement picture and provides a cross check on running workload identification. Second, ACS itself is a separately entitled product whose own audit posture may surface during a broader OpenShift audit. The cross link into Lane 11 on Red Hat Advanced Cluster Security pricing treats the entitlement side.

The practice begins container image scan evidence engagement by mapping the registries in scope, the running workloads, the base image lineage, and the entitlement model that applies (UBI, RHEL, OpenShift, ACS where relevant). The defended production then assembles a curated inventory with catalog hash matches, Dockerfile excerpts for customer builds, and an accompanying memorandum that explains the entitlement mapping. The raw scan output is held back until the audit team's specific question can be addressed with a narrower production. The parent practice note on OpenShift treats the container platform side that the image evidence feeds into.

Across container heavy audits in the practice's trailing twelve months, defenses that produced curated image inventories with provenance maps settled at materially lower percentages of the initial Red Hat finding than defenses that produced raw scan output across the registry. If the audit notice asks for image scan data, the first useful hour is a call with the desk. The companion notes on vCenter host inventory, subscription manager output, and audit clause anatomy treat parallel evidence types.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.