Container Security: support reference¶
Internal. The customer-facing explanation is in Reading the Container Security screens and the screen reference.
Container findings behave unlike anything else in NxSAM, because the thing being assessed is rebuilt rather than repaired.
The asset is immutable, so "fixed" means "replaced"¶
An image is not patched — a new image is built and the old one stops being deployed. Two consequences drive most tickets:
- A finding is not remediated on the image it was found on. It is absent from the next tag.
- The same weakness reappears on every image built from an unfixed base, so one base-image problem is reported many times over.
A customer asking why a finding "keeps coming back" usually has an unfixed base image, and the answer is the base rather than the finding.
Two statuses, meaning different things¶
| Column | Scope |
|---|---|
| Status | This finding on this image |
| Master Status | The advisory itself, across every image it affects |
They diverge legitimately. A CVE can be triaged once at master level — judged not applicable to your runtime, say — while individual images still carry it. Reading one as the other produces "we already closed this" disputes.
Vulnerabilities and compliance are separate halves¶
The module reports two different things about the same image:
- Vulnerabilities — packages with known advisories.
- Compliance — hardening and configuration checks, including secrets found in layers.
They have separate counts, separate screens and separate severities. A total that "doesn't add up" is often the two halves being summed.
The compliance half of the dashboard does not populate
A known product defect: the storage service assigns the whole response envelope where the component reads payload keys off it, so the compliance panels cannot bind whatever is served. The vulnerability half is unaffected. Recorded in FINDINGS.
Secret findings are sparse by design¶
Secret Path and Secret Location In File are populated only on secret-category compliance rows — roughly two in five. Empty cells on hardening rows are correct, not missing data.
Treat the finding detail itself as sensitive: a secret finding names a credential and where it lives, so it should not be pasted into a ticket.
Registry, repository and tag¶
An image is identified by all three. A caller naming only a repository is describing many images, and counts will not match whatever they are comparing against. Establish the tag before investigating a discrepancy.
Collections group images the way the scanning platform groups them, not the way NxSAM groups other assets, so collection membership comes from the source tool and is not editable here.
The sync queue¶
Image collection is queued. The queue records sync type, image type, status, initiated and completed times.
A run that is In Progress has no completed time — that blank is the state, not a fault. A run whose initiated-to-completed gap grows on every cycle is falling behind, and the image list is increasingly stale.
Prisma appears twice¶
Prisma Cloud is two separate integrations with separate credentials: one for container security, one for cloud posture. Connecting one does not populate the other, and "we already connected Prisma" is a frequent cause of an empty module.
What to collect before escalating¶
- Registry, repository and tag — all three.
- Whether the question is about the vulnerability half or the compliance half.
- Status and Master Status of the finding, quoted separately.
- The most recent sync queue entry, with its initiated and completed times.
- For "it came back": the base image, and whether a new tag has been built since.