Build the inventory from four places: what is running in your clusters, what your CI pipelines build, what sits in your registries, and what your deployment files reference. Merge them by image digest. The gaps between the four lists show where a scanner would otherwise miss something.
Why do this first
Buyers often start a scanner trial with the three or four images the team remembers. The real number is usually higher, and some images are the ones nobody owns. An inventory gives you a coverage target, a fair test set, and a way to check that a trial scans what you actually run.
Source 1: the cluster
Kubernetes documentation shows a way to list the images running in a cluster. You query pods across all namespaces and format the output to include only the image names, covering both containers and init containers, then sort and count them. The documented command uses kubectl get pods with a jsonpath expression that reads the image field from both lists. Run it for each cluster and keep the output.
Note that this shows what is running now. It misses scheduled jobs that are not currently active.
Source 2: CI
List every pipeline step that runs docker build, a build tool, or pulls a build image. Include the images used as build environments, because those run your code and tokens. A search of pipeline files for image references is a good start.
Source 3: registries
List repositories in each registry you use, with tags and digests. Registries often hold old images that were never cleaned up. Mark each as deployed, recent, or stale. Stale ones may not need scanning, but you want to decide that deliberately.
Source 4: deployment files
Search manifests, Helm charts, compose files and task definitions for image references. These show what will run after the next deploy, including images in environments not yet live.
Merge and label
| Field | Why you need it |
|---|---|
| Image name and digest | Tags move, digests do not |
| Where seen | Cluster, CI, registry, files |
| Owner team | Who fixes findings |
| Base image | Lets you group findings by base |
| Last pushed | Separates active from stale |
Digest is the key. The same tag may point to different content in different places, which is itself a finding.
Use it in the trial
Pick a sample that covers each base OS family, each language, and at least one image from each source. After the trial, compare the scanner's list of scanned images with the inventory. Anything missing is a coverage gap to raise with the vendor. If you want a ready method, the scan once and promote the same digest post covers how to keep one result per digest.
A worked example: four lists, one surprise
A mid-sized team starts with the images it remembers: 12 services. The inventory exercise produces this illustrative result.
| Source | Images found | Not in the other sources |
|---|---|---|
| Cluster listing | 34 | 3 (old jobs and a vendor agent) |
| CI build logs | 29 | 6 (build tool images and test databases) |
| Registry | 210 | 150 (stale tags and abandoned services) |
| Deployment files | 31 | 2 (staging only) |
After merging by digest there are 61 distinct images in use or about to be, plus a long tail of stale registry content. The team had planned a trial on 12 services. The inventory shows that a quarter of what runs never appeared on anyone's list, including build tool images that run with pipeline secrets.
None of these numbers are universal. The point is the shape: each source contains images the others do not.
Step by step: build it in one afternoon
- Export the cluster image list from each cluster, including init containers.
- Search CI configuration for image references and base images in build files.
- List registry repositories with tags, digests and last push dates.
- Search deployment files for image references.
- Put all rows in one sheet and key them by digest.
- For each row, add the owner, the source list, and whether it is deployed.
- Mark stale rows, meaning images not deployed and not pushed recently, and decide as a team whether to scan or retire them.
Do not forget scheduled work
A listing of running pods shows only what is running at that moment. Kubernetes CronJobs create jobs on a schedule, and the pods exist only while a job runs. The CronJob documentation shows that the image is defined inside the job template. So search CronJob and Job definitions, not just pods, or you will miss the images that run at night. The same applies to any batch system your company uses.
What to do with the inventory
- Choose trial images that cover each base family and language.
- Set a coverage target, for example every deployed digest scanned within 24 hours.
- After the trial, check which inventory rows the scanner never saw.
- Keep the sheet as the start of your asset register.
Common mistakes
- Relying on tags. Two environments can use the same tag with different content.
- Counting stale registry images as coverage gaps without deciding whether they matter.
- Leaving out build tool images, which hold more privilege than many production images.
- Doing the exercise once. Re-run it quarterly, or automate it.
Try it yourself
Click through it at your own pace, or open it full screen.
See how an inventory view groups components, which is the same idea you will apply to images.
Where Safeguard fits
Safeguard offers asset discovery and SBOM and dependency scanning, which can help you keep this inventory current. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is the registry list enough as an inventory?
No. It shows what was pushed, not what runs. Always add the cluster and deployment files.
Do init containers count?
Yes. They run with your pod's permissions, and the Kubernetes listing method includes them.
How often should the inventory be refreshed?
Quarterly by hand at minimum, and continuously if you can automate it. New services and forgotten jobs appear faster than people expect.
Sources
Last reviewed: 19 October 2026.
