Answer container questions in five parts: how you choose base images, when you scan, whether you rescan images already in the registry or running, whether images are signed, and how secrets are kept out of layers. Offer a recent scan report and the policy that blocks risky images.
What buyers want to know
Container images bundle your code with an operating system layer and libraries. Flaws can sit in any layer, including parts you never wrote. Buyers ask how you see and manage that.
The five parts
Base images. Say you use minimal, maintained base images from known sources and pin versions. Smaller images carry fewer packages, so fewer things to patch.
Build-time scanning. Images are scanned in the pipeline and builds that violate policy fail or require an exception.
Rescanning. Images age. An image that was clean when built can match a new advisory a month later, so rescan stored images on a schedule and tie results to what is deployed.
Signing. Images are signed and deployment checks verify the signature. Say which environments enforce it; do not say "all" unless it is true. See image signing with cosign.
Secrets. Credentials are not baked into layers or build arguments, and scans check for them.
Decision table: what to say by maturity
| Maturity | Honest phrasing |
|---|---|
| Scan at build only | "We scan every image at build and block critical findings with a fix. Scheduled rescans of registry images are planned." |
| Build plus rescans | "We scan at build and daily in the registry and open tickets for new findings." |
| Plus signing and admission checks | "Images are signed, and the cluster rejects unsigned images in production." |
Evidence
A redacted scan summary with a date, the pipeline step showing the gate, and the list of approved base images. Keep the image digests in the evidence so a buyer can see you scanned a specific artifact, not a generic one.
Mistakes
Reporting only OS package findings and ignoring application dependencies inside the image. Scanning the build image but deploying a different one. Claiming zero vulnerabilities, which scanners rarely support. Say what the policy blocks instead.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped by layer and package. Those groups are the content of your build-time scanning answer.
Cover registries and runtime
Buyers sometimes ask where images are stored and who can push to the registry. Say that push access is limited and logged, and that deployment pulls only from approved registries. For runtime, say whether running workloads are compared against the latest scan results, so that an old deployment of a vulnerable image is noticed even if the build is long finished.
Quick check
Do buyers expect distroless or minimal images?
Not as a rule. They expect you to have thought about attack surface and to patch.
Is a scan report enough evidence?
It supports the answer, but also show the gate that acts on it.
Safeguard includes container image scanning, SBOM generation and policy gates, with a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
