Show four things: how you choose and pin base images, that images are scanned at build time and again after release, how fast you rebuild when a base layer gets a fix, and what runs as which user. Keep it to one page. Reviewers want a routine, not a vulnerability count.
Why images draw questions
A container image bundles your code, your libraries and an operating system layer. A scan of your application dependencies alone misses the operating system packages inside the image, so reviewers who understand this ask about the whole artifact.
The Security Rule asks you to guard against reasonably anticipated threats to electronic protected health information (45 CFR 164.306(a)(2)), and it asks for procedures for guarding against, detecting and reporting malicious software (164.308(a)(5)(ii)(B), addressable). Image hygiene is one way to show that work.
What to show
| Topic | Evidence | One line summary |
|---|---|---|
| Base image choice | Dockerfile excerpt, policy line | We use minimal, maintained base images and pin by digest |
| Scan at build | Pipeline step, sample result | Every build is scanned, high severity findings block release per policy |
| Scan after release | Schedule, last run | Released images are rescanned on a regular schedule |
| Rebuild routine | Record of a recent rebuild | We rebuild when a base layer fix is available |
| Runtime posture | Config excerpt | Containers run as non root, with read only file systems where possible |
| Provenance | Registry and signing settings | Images come from our registry only |
Include only the lines you can back up. If you do not sign images, leave that out rather than hint at it.
Common weak spots
- Latest tags, which make "what version ran in March" unanswerable.
- Images that ship build tools and shells they do not need.
- Scans that run once at build and never again, though new flaws are published daily.
- Findings that are counted but never reviewed for reachability.
Steps to tighten before a review
- Pin base images by digest and record the digest in the release.
- Remove packages the runtime does not need.
- Add a scheduled rescan of deployed images.
- Define a rebuild rule, for example "within a set number of days of a fix for a high severity finding."
- Capture one example from the last quarter showing the cycle working.
Try it yourself
Click through it at your own pace, or open it full screen. Look for which findings come from the operating system layer and which from application packages, since reviewers ask about both.
Safeguard's container image scanning and continuous monitoring are designed for the build and after release steps, and policies can enforce your rebuild rule.
Quick check
Do reviewers expect zero findings in an image?
No. They expect you to understand findings, fix what matters and explain what you accept.
Is a distroless or minimal image required?
No rule requires it. It reduces what can go wrong, which makes your answers easier.
Sources
- 45 CFR 164.306 Security standards: General rules, eCFR
- 45 CFR 164.308 Administrative safeguards, eCFR
Last reviewed: 19 October 2026.
