Container Security: every screen, column and action¶
Complements Reading the Container Security screens. This page names every column, including the secret-detection fields that are easy to miss.
Collections¶
| Column | What it holds |
|---|---|
| Collection Name / Description | The grouping, usually mirroring how the platform team organises workloads |
| Active Image Count | Images currently in it |
| Status | Whether the collection is in use |
| Owner | Who is responsible for the workloads in it |
Owner is what makes a container finding assignable. An image has no natural owner — it is built by a pipeline — so the collection carries the accountability.
Images¶
| Column | What it holds |
|---|---|
| Registry / Repository | Where the image lives |
| Tag | The version. Part of the identity, not a label on it |
| Vulnerability | Open package findings |
| Compliance | Open configuration findings |
| Last Scan Date | When the image was last evaluated |
| Collections | Which groupings it belongs to — an image can be in several |
| Status | Whether the image is active |
Row actions — four¶
| Action | What it does |
|---|---|
| View Vulnerabilities | Package findings for this image |
| View Compliance | Configuration findings for this image |
| Export Vulnerabilities | Downloads the vulnerability list |
| Export Compliance | Downloads the compliance list |
Vulnerabilities¶
| Column | What it holds |
|---|---|
| Registry / Repository | The image |
| CVE | The advisory |
| Severity | As the advisory rates it. The column header reads Serverity on both container tables — a spelling error in the product, not a different field (FINDINGS #16) |
| Package Info | The package and version that carries it — the actual cause |
| Fix Info | Whether a fixed version exists, and which |
| Discovered Info | When it was first seen here |
| SLA Overdue Status | Whether it has passed its deadline |
| Collection | The workload grouping, and therefore the owner |
| Status | The working state of this finding |
Fix Info decides whether a finding is actionable at all
A vulnerability with no fixed version cannot be resolved by rebuilding — the maintainer has not released one. Those findings need a compensating control or a documented acceptance, and treating them as a remediation backlog produces a queue that never moves.
Sorting by Fix Info separates "rebuild will fix this" from "nothing you build will".
Compliance¶
Configuration and hardening checks, plus secret detection.
| Column | What it holds |
|---|---|
| Registry / Repository | The image |
| Compliance Details | The check that failed |
| Category | What kind of check — hardening, configuration, secrets |
| Severity | As rated |
| Secret Path | The file a detected secret was found in |
| Secret Location In File | Where within that file |
| Discovered Info | When first seen |
| SLA Overdue Status | Past deadline or not |
| Collection | Workload grouping and owner |
| Status | Working state |
Secret Path and Secret Location are themselves sensitive
When a compliance finding is a detected credential, these two columns point directly at it. An exported compliance list therefore contains a map to live secrets in your images.
Treat those exports as sensitive material, and rotate the credential rather than only removing it from the image — it is in every previously built layer regardless.
Page-level exports¶
- Export Overall Vulnerabilities — every finding across every image
- Export Unique Vulnerabilities — each CVE once, however many images carry it
- Export Overall Compliance — every compliance finding
The unique export is the one to use for remediation planning. The overall export counts the same log4j advisory forty times across forty images; the unique export lists it once, which is the number of decisions that actually have to be made.
Per-image detail views¶
Opening an image shows its findings with a slightly different column set:
Vulnerabilities — CVE Details, Severity, Package Info, Fix Status,
Discovered Info.
Compliance — Compliance Details, Category, Severity, Title, Secret Path,
Secret Location In File, Created At.
Which images carry a finding¶
From a vulnerability or compliance finding you can see every image affected:
| Column | What it holds |
|---|---|
| Tag | The image version |
| First Scan At / Last Scan At | The window over which it has been present |
| Vulnerability Count / Compliance Count | How many findings that tag carries |
This is the view that shows a base-image problem for what it is. A CVE appearing against fourteen tags is one package to update, not fourteen tickets — and the first and last scan dates show whether newer tags have already resolved it.