# Include init containers in a Kubernetes image-name inventory > The documented all-namespace query includes init and application container image fields. Keep that population explicit when filtering or changing the query. - Canonical URL: https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T00:09:55+00:00 - Modified: 2026-10-29T00:10:35+00:00 - Last reviewed by DSE: 2026-10-28 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know The documented all-namespace query includes init and application container image fields. Keep that population explicit when filtering or changing the query. ## Potentially affected Review scope: the Pod-specification image-name queries in the Kubernetes inventory tutorial; resolved runtime digests and scanner eligibility are separate questions. ## DSE recommendation Retain the exact namespace, label and container-field selection with an image inventory, and reconcile init-container entries before accepting its scope. ## Article Bottom line: Define what an image inventory includes before counting its output. Preserve the container fields and Pod population in the collection record so a shorter query does not silently become a narrower security or maintenance inventory. ## Source fact: documented behavior The [List All Container Images Running in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/) documentation is the primary reference. The all-namespace example extracts image names from both initContainers and containers under each Pod specification. The label-filtered and namespace-filtered examples shown on the page select spec.containers image fields. ## What the source does not establish This article concerns the documented image-name query, not proof of immutable runtime identity, successful vulnerability assessment or application use. It does not inventory a deleted workload or a registry by implication. Agree those wider requirements separately instead of calling every list a complete running-software inventory. ## Applicability questions - Which namespaces and label selection define the intended population? - Must the record include both initialization and application images? - Is the requested evidence an image name, a runtime identity or assessment coverage? - Who will explain omissions when an inventory query changes? ## DSE recommendation: preserve the query population DSE recommends storing the collection definition beside the resulting list. Name the cluster context, namespace scope, label selection and selected Pod fields. Keep a readable explanation of the JSONPath so another operator can distinguish an intentional exclusion from an accidental query edit. For an inventory that requires initialization images, start from the tutorial’s all-namespace selection of both container arrays. Review the --all-namespaces scope and the fields before adapting it. If the owner asks for a namespace or label filter, retain that requirement while checking the container-array selection independently. Do not accept a pasted example solely because its output looks plausible. Keep an attributable view before producing a summary. Record which Pod and namespace contributed each image name, then make the aggregated count a separate presentation. This gives the reviewer a way to investigate a missing entry without guessing which workload supplied it. Protect operational names according to the organization’s handling rules. Separate collection from the next decision. Give image withdrawal, runtime-digest reconciliation and vulnerability-assessment eligibility their own evidence requirements. A recipient should be able to tell which question this particular inventory answers and which supporting record is still needed. ## Verification and evidence Proposed verification, not performed: use a disposable Pod with different harmless image names in its initialization and application definitions. Write the expected two-array population before running the documented collection. Compare that result with a deliberately application-only selection, identifying the narrower query as a test input. Repeat with an agreed namespace and label selection. Reconcile expected membership before interpreting counts, and preserve the exact invocation, context and time. Ask a second operator to trace each expected name back to the relevant Pod field. Record any unavailable namespace or collection error as a coverage gap rather than reporting an unqualified complete inventory. ## Official references - [List All Container Images Running in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/) — Kubernetes. Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — List All Container Images Running in a Cluster - Authority: kubernetes.io - URL: https://kubernetes.io/docs/tasks/access-application-cluster/list-all-running-container-images/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include init containers in a Kubernetes image-name inventory,” DSE Security, https://update.dsesecurity.com/updates/include-init-containers-in-a-kubernetes-image-name-inventory/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.